By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,188 Members | 1,004 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,188 IT Pros & Developers. It's quick & easy.

unline instead of outline

P: n/a
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
Jul 19 '05 #1
Share this Question
Share on Google+
14 Replies


P: n/a
Typo in the code. Here is how it
should be:

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

-X
Jul 19 '05 #2

P: n/a
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
Jul 19 '05 #3

P: n/a
"Agent Mulder" <mb*******************@home.nl> wrote :
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
peter.van.merkerk(at)dse.nl
Jul 19 '05 #4

P: n/a
"Agent Mulder" <mb*******************@home.nl> wrote:
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?
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl


Jul 19 '05 #5

P: n/a

"Peter van Merkerk" <me*****@deadspam.com> wrote in message
news:bg************@ID-133164.news.uni-berlin.de...
"Agent Mulder" <mb*******************@home.nl> wrote:
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?
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl


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
Jul 19 '05 #6

P: n/a
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


Jul 19 '05 #7

P: n/a

"Agent Mulder" <mb*******************@home.nl> wrote in message
news:bg**********@news1.tilbu1.nb.home.nl...
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
Jul 19 '05 #8

P: n/a
Agent Mulder wrote:

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
Jul 19 '05 #9

P: n/a
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

Jul 19 '05 #10

P: n/a
Agent Mulder wrote:

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! :-)


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
Jul 19 '05 #11

P: n/a
Mike Wahler wrote:

Pete Becker <pe********@acm.org> wrote in message
news:3F***************@acm.org...
Agent Mulder wrote:

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 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
Jul 19 '05 #12

P: n/a
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
Jul 19 '05 #13

P: n/a
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
Jul 19 '05 #14

P: n/a
"Agent Mulder" <mb*******************@home.nl> wrote in message
news:bg**********@news1.tilbu1.nb.home.nl...
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.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl

Jul 19 '05 #15

This discussion thread is closed

Replies have been disabled for this discussion.