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]

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]

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]

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(){}};

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]

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)
}};

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?

 

[John Harrison]

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)
}};

[snip]

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?

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

 

[John Harrison]

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.

For what reason?

john

 

[Agent Mulder]

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

 

[Pete Becker]

PB> Don't feed the troll.

You posted an invalid solution both on
comp.lang.c++.moderated and on
comp.std.c++.

Huh? In what way is it "invalid" to put 1400 line functions in source
files, where they belong?

I am not trolling

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]

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++.moderated:

Heinz Ozwirk:

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.

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]

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++.moderated:

Heinz Ozwirk:

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!

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]

I don't suppose I could get away with calling it 'invalid',
but imo 1400 lines in a single function is, well, foolish.

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]

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<<"drip 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]

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]

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:

[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.