unline instead of outline

[Agent Mulder]

When C++ gives the programmer
explicit control over the expansion
of code, it needs a new specifier.
If 'outline' as a specifier is too much
out-of-line, one might consider unline
as the counter part of inline.

class Cloud
{
public:unline rain()
{
//1400 lines of raining code (skipped)
}};

-X

[Agent Mulder]

Re: unline instead of outline

Typo in the code. Here is how it
should be:

class Cloud
{
public:unline void rain()
{
//1400 lines of raining code (skipped)
}};

-X

[Agent Mulder]

Re: unline instead of outline

AM> one might consider unline
AM> as the counterpart of inline.

There are other suggestions, notably
!inline or ~inline. Lets have a taste
from all of them:

class Cloud{unline void rain(){}};
class Cloud{outline void rain(){}};
class Cloud{!inline void rain(){}};
class Cloud{~inline void rain(){}};

-X

[Peter van Merkerk]

Re: unline instead of outline

"Agent Mulder" <mbmulder_remov e_this_@home.nl > wrote :[color=blue]
> AM> one might consider unline
> AM> as the counterpart of inline.
>
> There are other suggestions, notably
> !inline or ~inline. Lets have a taste
> from all of them:
>
> class Cloud{unline void rain(){}};
> class Cloud{outline void rain(){}};
> class Cloud{!inline void rain(){}};
> class Cloud{~inline void rain(){}};[/color]

I think the best place to post these suggestions is comp.std.c++; that
newsgroup is dedicated to the design and standardization of the C++
language.
--
Peter van Merkerk
peter.van.merke rk(at)dse.nl

[Peter van Merkerk]

Re: unline instead of outline

"Agent Mulder" <mbmulder_remov e_this_@home.nl > wrote:[color=blue]
> When C++ gives the programmer
> explicit control over the expansion
> of code, it needs a new specifier.
> If 'outline' as a specifier is too much
> out-of-line, one might consider unline
> as the counter part of inline.
>
> class Cloud
> {
> public:unline rain()
> {
> file://1400 lines of raining code (skipped)
> }};[/color]

Note that even if you define the Cloud class like this, it is still possible
(and in the case of a 1400 line member function even likely) that the
compiler does not inline the code. The "inline" keyword, or a inline
definition is merely a hint to the compiler. The compiler is free to ignore
that hint for whatever reason, and not inline that code anyway.

Also note that these Java style class definitions are not really a good idea
in C++. When any of those 1400 lines changes, all other .cpp files including
the header in which the Cloud class is defined will be recompiled as well.
If the definitions of the member functions are moved to .cpp file, only that
..cpp file needs to be recompiled. Reducing dependencies can speed up
building large projects considerably.

However I do see the logic in your proposal; if you can hint the compiler to
inline code why can you not do the opposite?
--
Peter van Merkerk
peter.van.merke rk(at)dse.nl

[John Harrison]

Re: unline instead of outline


"Peter van Merkerk" <merkerk@deadsp am.com> wrote in message
news:bgj800$pcs vc$1@ID-133164.news.uni-berlin.de...[color=blue]
> "Agent Mulder" <mbmulder_remov e_this_@home.nl > wrote:[color=green]
> > When C++ gives the programmer
> > explicit control over the expansion
> > of code, it needs a new specifier.
> > If 'outline' as a specifier is too much
> > out-of-line, one might consider unline
> > as the counter part of inline.
> >
> > class Cloud
> > {
> > public:unline rain()
> > {
> > file://1400 lines of raining code (skipped)
> > }};[/color]
>[/color]
[snip][color=blue]
>
> However I do see the logic in your proposal; if you can hint the compiler[/color]
to[color=blue]
> inline code why can you not do the opposite?
> --
> Peter van Merkerk
> peter.van.merke rk(at)dse.nl
>[/color]

Inline is more than a hint to the compiler, its other function is to provide
an exception to the one definition rule. This exception is the main point of
inline, not providing a hint to a compiler.

Features which are purely implementation hints to a compiler and provide no
actual change to the semantics of a program are more or less meaningless and
unlikely to be much used, e.g. the register keyword.

john

[Agent Mulder]

Re: unline instead of outline

MW> 'inline' does *not* give one explicit control
MW> over 'expansion' of code. 'inline' is only
MW> a suggestion, which a compiler may or may not
MW> observe. It's also allowed to inline functions
MW> which are not marked with the 'inline' keyword.

You got the point, Mike. I'm trying to explicitly
disallow the compiler to inline code that is an obvious
candidate for inlining. I found no portable way of
doing that. So now I spread the word on unline.

-X

[John Harrison]

Re: unline instead of outline


"Agent Mulder" <mbmulder_remov e_this_@home.nl > wrote in message
news:bgjd7s$rdc $1@news1.tilbu1 .nb.home.nl...[color=blue]
> MW> 'inline' does *not* give one explicit control
> MW> over 'expansion' of code. 'inline' is only
> MW> a suggestion, which a compiler may or may not
> MW> observe. It's also allowed to inline functions
> MW> which are not marked with the 'inline' keyword.
>
> You got the point, Mike. I'm trying to explicitly
> disallow the compiler to inline code that is an obvious
> candidate for inlining. I found no portable way of
> doing that. So now I spread the word on unline.
>[/color]

For what reason?

john

[Pete Becker]

Re: unline instead of outline

Agent Mulder wrote:[color=blue]
>
> PB> Don't feed the troll.
>
> You posted an invalid solution both on
> comp.lang.c++.m oderated and on
> comp.std.c++.
>[/color]

Huh? In what way is it "invalid" to put 1400 line functions in source
files, where they belong?
[color=blue]
> I am not trolling[/color]

Posting the same thing in multiple newsgroups and ingoring replies is
trolling.

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

[Agent Mulder]

Re: unline instead of outline

PB> That's been suggested at least four times in two other newsgroups. He
PB> hasn't replied to it anywhere else, except in his message to me in this
PB> newsgroup saying it's "invalid."

I copied this reply from from the thread
Re: turn off inlining using extern "C", on
comp.lang.c++.m oderated:

Heinz Ozwirk:[color=blue]
>If you want to prevent functions from being inlined, put them in separate
>.cpp (or whatever) files and only include their prototypes in the code
>that calls them. The compiler cannot inline them, if it doesn't know what
>to inline.[/color]

Francis GlassBorow:
Of course it can and good linkers have been managing that for some time.
In future it will become more common as forms of semi-compiled code
become more common. VC++7 has some quite clever features in this area.

Agent Mulder again:
The conclusion in that thread is that there is no
portable way to ensure that code gets expanded
outline (not inline). It is viewed as a de-optimization
enforced by the programmer. Your hack of taking
the function body out of the class declaration does
not work. Fix it! :-)

-X

[Pete Becker]

Re: unline instead of outline

Agent Mulder wrote:[color=blue]
>
> PB> That's been suggested at least four times in two other newsgroups. He
> PB> hasn't replied to it anywhere else, except in his message to me in this
> PB> newsgroup saying it's "invalid."
>
> I copied this reply from from the thread
> Re: turn off inlining using extern "C", on
> comp.lang.c++.m oderated:
>
> Heinz Ozwirk:[color=green]
> >If you want to prevent functions from being inlined, put them in separate
> >.cpp (or whatever) files and only include their prototypes in the code
> >that calls them. The compiler cannot inline them, if it doesn't know what
> >to inline.[/color]
>
> Francis GlassBorow:
> Of course it can and good linkers have been managing that for some time.
> In future it will become more common as forms of semi-compiled code
> become more common. VC++7 has some quite clever features in this area.
>
> Agent Mulder again:
> The conclusion in that thread is that there is no
> portable way to ensure that code gets expanded
> outline (not inline). It is viewed as a de-optimization
> enforced by the programmer. Your hack of taking
> the function body out of the class declaration does
> not work. Fix it! :-)
>[/color]

Okay. Perhaps you should change your example so that you don't tell the
compiler to inline your function. Then you might have a better example
for your proposed 'uninline.' But if you do that then you'll have to
explain why you think a compiler might inline your 1400 line function
and why, if the compiler does that, it's something that requires a
language change.

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

[Pete Becker]

Re: unline instead of outline

Mike Wahler wrote:[color=blue]
>
> Pete Becker <petebecker@acm .org> wrote in message
> news:3F2D3E74.9 6EFB538@acm.org ...[color=green]
> > Agent Mulder wrote:[color=darkred]
> > >
> > > PB> Don't feed the troll.
> > >
> > > You posted an invalid solution both on
> > > comp.lang.c++.m oderated and on
> > > comp.std.c++.
> > >[/color]
> >
> > Huh? In what way is it "invalid" to put 1400 line functions in source
> > files, where they belong?[/color]
>
> I don't suppose I could get away with calling it 'invalid',
> but imo 1400 lines in a single function is, well, foolish.
>[/color]

Well, sure, but that's not the issue.

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

[Agent Mulder]

Re: unline instead of outline

Peter>Note that even if you define the Cloud class like this,
Peter>it is still possible (and in the case of a 1400 line member
Peter>function even likely) that the compiler does not inline the code.

Hoi Peter, thank you and the others for your replies.
I deviced a program with 1400 lines of initialization
code and under Borland 5.5 it does indeed gratify
the 'request' to inline:

#include <iostream>
#define I std::cout<<"dri p drip drop drip ";
#define X I I I I I I I I I I
#define C X X X X X X X X X X
#define M C C C C C C C C C C
class Cloud
{
public:Cloud()
{
M C C C C //1400 lines of initialization code
for(;!true;); //comment this out and size doubles
}};
int main(int argc,char**argv )
{
Cloud a,b,c,d,e,f,g,h ,i,j,k,l,m;//,n,o,p,q,r,s,t, u,v,w,x,y,z;//linker gives
up
return 0;
}

-X

[Agent Mulder]

Re: unline instead of outline

AM> You posted an invalid solution...!!!

Sorry Pete. There was no need be that short. It's
just that I unsize for a troll :-)

-X

[Peter van Merkerk]

Re: unline instead of outline

"Agent Mulder" <mbmulder_remov e_this_@home.nl > wrote in message
news:bgmsj7$nlq $1@news1.tilbu1 .nb.home.nl...[color=blue]
> Peter>Note that even if you define the Cloud class like this,
> Peter>it is still possible (and in the case of a 1400 line member
> Peter>function even likely) that the compiler does not inline the code.
>
> Hoi Peter, thank you and the others for your replies.
> I deviced a program with 1400 lines of initialization
> code and under Borland 5.5 it does indeed gratify
> the 'request' to inline:[/color]
[snip]

Dag meneer "Mulder",

To my surprise Borland 5.5 indeed honors the inline request even though the
function consists of 1400 lines(!). I compiled your code with Microsoft
Visual C++ 6.0 as well. I inspected the assembler output and even at its
most aggressive optimization setting (which can also inline functions not
explicitly declared inline) this compiler simply refuses to inline the
function. This makes sense as inlining functions is mostly done to avoid the
function call overhead (which can be significant with simple getter/setter
functions). On a 1400 line function, the function call overhead would be
completely insignificant. In this case inlining does not only make the
program larger, but probably also slower. Cache misses are more likely to
occur if due to inlining code is spread over a larger memory area. So I
think the Microsoft compiler made the best choice here, though as far as the
standard is concerned both compilers are right in this respect.

--
Peter van Merkerk
peter.van.merke rk(at)dse.nl