In article <bgr68i$avvai$1@ID-14036.news.uni-berlin.de>,
 on Fri, 8 Aug 2003 03:23:12 +0000 (UTC),
 SeeWebsiteForEmail@moderncppdesign.com ("Andrei Alexandrescu") wrote:

> "Andy Sawyer" <andys@despammed.com> wrote in message
> news:8yq7yl3y.fsf@evo6.com...
>>
> No, that's 1400 statements, not 1400 LINES. Not the same thing at all.
> If your preprocessor behaves correctly, it's actually a single LINE
> (albeit a very long one) of code. I'd expect a half-way decent
> optimizer (depending on what you told it to optimise for) to turn this
> into the moral equivalent of something like:
>
>   for( int i = 0 ; i < 1400 ; ++i )
>   {
>      static const char s[] = "drip drip drop drip "
>      std::cout << s;
>   }
>
> Depending on how chummy the compiler is with the library
> implementation, there are further potential optimisations available.
> <
>
> Unfortunately, that's not an often encountered optimization. Many
> optimizations that seem very intuitive are either (1) hard to
> implement, (2) provide little benefit with real code, or both. I
> believe (2) applies to this case.

The benefit (or otherwise) of that particular optimisation rather
depends on your target platform, and whether space is more important
that speed to you. But since nobody would be dumb enough to write a
function like that, it's moot.

> The moral is, if you don't want your code expanded inline, then don't
> declare it inline.
> <
>
> That pretty much summarizes the thread quite nicely :o).

Thanks, I thought so to :)

Regards,
 Andy S
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Andy Sawyer" <andys@despammed.com> wrote in message
news:he4qtx9j.fsf@evo6.com...
> > Unfortunately, that's not an often encountered optimization. Many
> > optimizations that seem very intuitive are either (1) hard to
> > implement, (2) provide little benefit with real code, or both. I
> > believe (2) applies to this case.
>
> The benefit (or otherwise) of that particular optimisation rather
> depends on your target platform, and whether space is more important
> that speed to you. But since nobody would be dumb enough to write a
> function like that, it's moot.

The benefit of /many/ optimizations depend on the target platform. Also, the
"loop rolling" transformation (the antonym of "loop unrolling") that you
mention can often generate faster code because of the speed gaps in the
memory hierarchy (processor registers, L0 cache, L1 cache, main memory,
disk).

Anyhow, my point was just that not all code that has a human-obvious
transformation looks just as trivially optimizable by a "half-decent"
compiler :o).


Andrei


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Andy Sawyer" <andys@despammed.com> wrote in message
news:8yq7yl3y.fsf@evo6.com...
>
No, that's 1400 statements, not 1400 LINES. Not the same thing at all.
If your preprocessor behaves correctly, it's actually a single LINE
(albeit a very long one) of code. I'd expect a half-way decent optimizer
(depending on what you told it to optimise for) to turn this into the
moral equivalent of something like:

  for( int i = 0 ; i < 1400 ; ++i )
  {
     static const char s[] = "drip drip drop drip "
     std::cout << s;
  }

Depending on how chummy the compiler is with the library implementation,
there are further potential optimisations available.
<

Unfortunately, that's not an often encountered optimization. Many
optimizations that seem very intuitive are either (1) hard to implement,
(2) provide little benefit with real code, or both. I believe (2) applies
to this case.

Also the generality of an optimization and its (desiredly good) interaction
with other optimizations are a concern. This particular optimization would
apply maybe if you have, what? A statement? A function call? Then it will
fail with repeated patterns of *two* statements and *two* function calls.
If you try to generalize it to support that, you hit (1) above.

The optimizer writer's silver bullet is to find and combine a small number
of fundamental optimizations to cover many useful cases. Really, the first
thing that optimizer writers need to optimize is their own time! Otherwise,
the list of "ah, I found this possible little optimization" goes forever.

>
The moral is, if you don't want your code expanded inline, then don't
declare it inline.
<

That pretty much summarizes the thread quite nicely :o).


Andrei


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Hi group,

Thank you for your replies. I will elaborate on the need
for the new keyword 'unline' (outline is obsolete, things
go fast). The arguments in favor of unline are of different
nature: ethical, aesthetical and practical.

1. Ethics
The programmer should be the one to ultimately decide on the
way her program is placed in memory. If modern compilers/linkers get
so smart that they make decisions for us that we cannot undo,
we need a mechanism to take back those decisions and do it
the way we want. In the case of inlining, it simply means that
we must be able to stop an optimizing compiler from inlining a piece
of code that is otherwise an obvious candidate for inlining.

2. Aesthetics
The keyword inline has a very direct meaning. Allthough it is a hint
to the compiler that may not be granted, using it is like taking the
book home with you instead of reading it from the internet. This
strong concept needs its counterpart, with an equaly direct meaning.
Allthough its easy to juggle with in- and -out as opposites, outline
as a keyword has disadvantages. It does not mean the right thing
and it is likely to be used as variable name or as function name. So
in search of a better name one stumbles over 'unline'. It has as many
letters in it as inline has. It reflects what it is meant to do, ie
un-inline.
It is ugly enough. It is unlikely to be used in a different context. It can
be use as a verb: "I think it is better to unline that piece of code". It
is obvious by its name that it 'unline' complements 'inline'.

3. Practical
Programs with heavy use of threads and exceptions often need to have
the guarantee that code is not inlined. Programmers seeking alternative
ways of using the language need it to control the size of their program.


As for the question of a modern compiler does inline a method with
1400 lines of code, Borland 5.5 does:

#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 more than 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;
return 0;
}

-X


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bgmqqa$b7d$1@news1.tilbu1.nb.home.nl>, Agent Mulder
<mbmulder_remove_this_@home.nl> writes
>Thank you for your replies. I will elaborate on the need
>for the new keyword 'unline' (outline is obsolete, things
>go fast). The arguments in favor of unline are of different
>nature: ethical, aesthetical and practical.

OK. I think we all understand the basic syntax. There may be some corner
cases of the semantics that need addressing so that we do not have a new
variety of 'volatile'. Write up a paper for WG21 and submit it. I will
happily look after it in the evolution group of WG21 but I cannot take
time to write it up myself (I have more than enough proposals of my own)

Use whatever keyword you like as a place holder but that is not an
inherent part of the proposal where we want syntax, semantics and
justification. The bigger the cost of change the stronger the
justification has to be because that is where we apply a cost benefit
analysis.


--
Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bgmqqa$b7d$1@news1.tilbu1.nb.home.nl>, "Agent Mulder" wrote:
> Hi group,
>
> Thank you for your replies. I will elaborate on the need
> for the new keyword 'unline' (outline is obsolete, things
> go fast). The arguments in favor of unline are of different
> nature: ethical, aesthetical and practical.

It seems that you have trouble with the fact that defining a member
function in the class definition is equivalent to using 'inline'.
If you don't want inline functions, don't write them there.  There
are plenty of other reasons not to define non-trivial functions this
way, in any case.

Let us know when you find any implementation that will inline
your example function if it isn't defined as inline, without
really perverse optimisation settings.

> 1. Ethics
> The programmer should be the one to ultimately decide on the
> way her program is placed in memory. If modern compilers/linkers get
> so smart that they make decisions for us that we cannot undo,
> we need a mechanism to take back those decisions and do it
> the way we want.

There are many optimisations that have an impact on code size.
Implementations generally provide a means to control which
optimisations they perform.  However, these are well outside the scope
of the standard.

> In the case of inlining, it simply means that we must be able to
> stop an optimizing compiler from inlining a piece of code that is
> otherwise an obvious candidate for inlining.

You can.

<snip>
> 3. Practical
> Programs with heavy use of threads and exceptions often need to have
> the guarantee that code is not inlined.

Why?

> Programmers seeking alternative ways of using the language need it
> to control the size of their program.

Alternative to what?

> As for the question of a modern compiler does inline a method with
> 1400 lines of code, Borland 5.5 does:
<snip>

So use a better implementation, or don't write your implementations
inline.  There's no need to complicate the language just because one
implementer has a stupid optimiser.  VC++ 7.0 is smart enough not to
inline the function, whether or not it has a for statement.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <bgmqqa$b7d$1@news1.tilbu1.nb.home.nl>,
 on Tue, 5 Aug 2003 02:24:41 +0000 (UTC),
 mbmulder_remove_this_@home.nl ("Agent Mulder") wrote:

> As for the question of a modern compiler does inline a method with
> 1400 lines of code, Borland 5.5 does:

According to the Borland website=B9 Borland 5.5 was released in August
2000, so it's almost 3 years old. Given that, I'm not entirely sure that
it still qualifies as a "modern" C++ compiler.

> #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

Very cute ;)

> class Cloud
> {
> public:Cloud()
> {
> M C C C C //1400 lines of initialization code

No, that's 1400 statements, not 1400 LINES. Not the same thing at all.
If your preprocessor behaves correctly, it's actually a single LINE
(albeit a very long one) of code. I'd expect a half-way decent optimizer
(depending on what you told it to optimise for) to turn this into the
moral equivalent of something like:

  for( int i =3D 0 ; i < 1400 ; ++i )
  {
     static const char s[] =3D "drip drip drop drip "
     std::cout << s;
  }

Depending on how chummy the compiler is with the library implementation,
there are further potential optimisations available.

> for(;!true;); //comment this out and size more than doubles

And what happens if you take the function declaration out of line?

> }};
> 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;
> return 0;
> }

The moral is, if you don't want your code expanded inline, then don't
declare it inline.

Regards,
 Andy S

Footnotes:=20
=B9  http://www.borland.com/products/downloads/download_cbuilder.html

--=20
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]