On Fri, 22 Aug 2003 02:41:00 +0000, Erik wrote:

[ Moderators: I tried to mail this, but Erik provides no working email
address. ]

Erik, please provide some form of workable email addres in your posts.
Workable as in 'a human can demunge this' should be fine. Please do not
use the domain of someone else (Hormel Foods).

>> For example, you can read the following thread
>> <m3el01r24m.fsf@uniton.integrable-solutions.net>
> Unfortunately, I can't. That looks like an email address both to me and
> to Outlook Express.

You can use groups.google.com to look up this message, go to advanced
search. Xnews, an excellent newsreader for windows will correctly
recognize that as a message ID and will even offer to search google if the
posting is not on your server.

HTH,
M4


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

FG> my single point of disagreement is that I do not think we need a new
FG> keyword, just new syntax with corresponding semantics.

It's nice we agree on the functionallity of !inline. The syntax
does not bother me too much, although it would be cool to thumb
up 'unline' in the index. Is there a WG21-HOWTO somewhere, so
that I get help writing a technical expose on it?

This little program contains 1400 statements. There is
an "obvious candidate for inlining" that I rather had not inlined.
The for-hack forces the compiler to take the function definition
out of the class declaration. But I sense that it is implementation
dependent (warning 8027). Why cannot I tell the compiler directly
to *NOT* inline this piece of code?

#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 statements of initialization code
for(;!true;); //comment this out and size more than doubles (Borland 5.5)
}};
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 <bhqagq$d42$1@news1.tilbu1.nb.home.nl>,
 on Mon, 18 Aug 2003 14:54:14 +0000 (UTC),
 mbmulder_remove_this_@home.nl ("Agent Mulder") wrote:

> Why cannot I tell the compiler directly
> to *NOT* inline this piece of code?

As has been pointed out several times, by myself and others, you can.

Don't write this:

> class Cloud
> {
> public:Cloud()
> {
> M C C C C     //1400 statements of initialization code
> for(;!true;); //comment this out and size more than doubles (Borland 5.5)
> }};

Write, instead, this:

class Cloud
{
public:
  Cloud();
};

Cloud::Cloud()
{
  M C C C C     //1400 statements of initialization code
}

Is that _really_ so difficult?

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                       ]

> FG> my single point of disagreement is that I do not think we need a new
> FG> keyword, just new syntax with corresponding semantics.
>
> It's nice we agree on the functionallity of !inline. The syntax
> does not bother me too much, although it would be cool to thumb
> up 'unline' in the index. Is there a WG21-HOWTO somewhere, so
> that I get help writing a technical expose on it?
>
> This little program contains 1400 statements. There is
> an "obvious candidate for inlining"

Is there? Which one? I wouldn't call a function with 1400 statements
an "obvious candidate for inlining".

> that I rather had not inlined.
> The for-hack forces the compiler to take the function definition
> out of the class declaration. But I sense that it is implementation
> dependent (warning 8027).
It certainly is.

> Why cannot I tell the compiler directly
> to *NOT* inline this piece of code?
Because there is no need to. BTW, the compiler is free not to inline
your functions, even if they have the "inline" specifier (or are defined
within the class body). I don't understand why that keyword is there
at all, the compiler probably makes a better job determining what
funtions to inline than the programmer does. I gues it is to prevent
people that don't understand this from using #defines instead.

> #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 statements of initialization code
> for(;!true;); //comment this out and size more than doubles (Borland 5.5)
If I'm not totally wrong, Borland 5.5 is ancient. I seriously doubt that the
problem exists with a modern compiler.

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

/ Erik


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

Erik wrote:

> Because there is no need to. BTW, the compiler is free not to inline
> your functions, even if they have the "inline" specifier (or are define=
d
> within the class body). I don't understand why that keyword is there
> at all, the compiler probably makes a better job determining what
> funtions to inline than the programmer does. I gues it is to prevent
> people that don't understand this from using #defines instead.

Well, it seems that your reflexion would be true for register, but for=20
inline, the current compiler technology looks like it is not able to do=20
better than the programmer in all cases.

For example, you can read the following thread=20
<m3el01r24m.fsf@uniton.integrable-solutions.net>


--=20
Lo=EFc

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

no@spam.com ("Erik") writes:

[...]

| > Why cannot I tell the compiler directly
| > to *NOT* inline this piece of code?
| Because there is no need to.

Why there is no need to?  Do you know better than him the purpose of
his writing his program?

| BTW, the compiler is free not to inline
| your functions, even if they have the "inline" specifier (or are defined
| within the class body).

The compiler is a piece of technology programmed with someone else
knowledge and logic.
With current state of the art, it does not always know better than
the programmer; to be useful as a tool, it rather listen to the
programmers' suggestions where pratical and where it does not know
better than the programmer.

| I don't understand why that keyword is there
| at all, the compiler probably makes a better job determining what
| funtions to inline than the programmer does.

You might want to read "The Design and Evolution of C++", section
"Run-Time Efficiency" for the why.

| I gues it is to prevent
| people that don't understand this from using #defines instead.

MACROs don't respect scope rules and don't provide function semantics.

--
Gabriel Dos Reis, gdr@integrable-solutions.net

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

mbmulder_remove_this_@home.nl ("Agent Mulder") wrote in message news:<bhqagq$d42$1@news1.tilbu1.nb.home.nl>...
...
> dependent (warning 8027). Why cannot I tell the compiler directly
> to *NOT* inline this piece of code?

Well, you could start by NOT telling it to inline it. Function
definitions provided in-class are implicitly 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 statements of initialization code
> for(;!true;); //comment this out and size more than doubles (Borland 5.5)
> }};
> 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;
> }

class Cloud()
{
public: Cloud();
};

Cloud::Cloud()
{
// Actual definition, which is NOT implicitly inlined.
}

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

>> Because there is no need to. BTW, the compiler is free not to inline
>> your functions, even if they have the "inline" specifier (or are defined
>> within the class body). I don't understand why that keyword is there
>> at all, the compiler probably makes a better job determining what
>> funtions to inline than the programmer does. I gues it is to prevent
>> people that don't understand this from using #defines instead.

> Well, it seems that your reflexion would be true for register, but for
> inline, the current compiler technology looks like it is not able to do
> better than the programmer in all cases.

Who can do better than everyone in all cases? Not even me =)

Decision of whether to inline or not should be based on a number of
variables,
the two major ones are (AFAIK):
1. The size of the function, the size of the overhead of a function call and
the
size of the inline version of the function. This can't be a very hard
decision
for the compiler to make, can it?
2. How inlining/outlining affects the processor cache. This is a lot harder
for the
compiler to decide, and virtually impossible for the human. If you need this
kind
of control in a very critical inner loop, you should probably write it in
assembly
language. Even the smallest change in the (called or calling) function (e.g.
inlining
another function) could radically change the performance in this case,
voiding
all your earlier measurements, and you have to start all over again.

> For example, you can read the following thread
> <m3el01r24m.fsf@uniton.integrable-solutions.net>
Unfortunately, I can't. That looks like an email address both to me
and to Outlook Express.



---
[ 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 <bi2v48$1t1$1@news.lth.se>, Erik <no@spam.com> writes
>Decision of whether to inline or not should be based on a number of
>variables,
>the two major ones are (AFAIK):
>1. The size of the function, the size of the overhead of a function call and
>the
>size of the inline version of the function. This can't be a very hard
>decision
>for the compiler to make, can it?

a) If the size of the inlined function is less than the size of a
function call then inlining will always be profitable. Note that a good
linker can deal with this case by replacing the function call code with
the inline code. A good example of this is a pure forwarding function
that does not reorder or add arguments.
b) If an out of line version will be used somewhere in the code and the
inline code is more than a function call in size then inlining never
saves space and can only save time. That is an immensely more complex
issue that involves such things as the ratio of different memory (cache
level, main memory and backing store) A single page fault or cache miss
(particularly within a loop) can nullify all time benefits.

>2. How inlining/outlining affects the processor cache. This is a lot harder
>for the
>compiler to decide, and virtually impossible for the human. If you need this
>kind
>of control in a very critical inner loop, you should probably write it in
>assembly
>language. Even the smallest change in the (called or calling) function (e.g.
>inlining
>another function) could radically change the performance in this case,
>voiding
>all your earlier measurements, and you have to start all over again.

And this is the nub of the issue. Human beings will rarely get it right.
However there is a special case where the function will only be called
in one place. I.e. the function has been created to enhance readability
and maintenance and not for reuse. I think that a compiler should always
consider functions in an unnamed namespace as candidates for inlining.
If the address of the function is never explicitly taken and the
function is only called once the motivation for inlining should go up
but even then it is not always right. For example in a switch statement
where each case is handled by calling a function, keeping the functions
out of line might enable the calling function to be kept in cache with
sufficient room for fetching the called function.

Several of the issues with inlining are sensitive to the exact hardware
being used. For example an application developer using a highend machine
with large cache memory and 1 gbyte+ RAM should profile and benchmark
their product on a typical user configuration. They might be surprised
to discover that decisions that seriously improve performance on their
machine also seriously degrades performance on the low end of the target
machines.

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

Erik wrote:

>>Well, it seems that your reflexion would be true for register, but for
>>inline, the current compiler technology looks like it is not able to do
>>better than the programmer in all cases.
>=20
>=20
> Who can do better than everyone in all cases? Not even me =3D)
>=20
> Decision of whether to inline or not should be based on a number of
> variables,
> the two major ones are (AFAIK):
> 1. The size of the function, the size of the overhead of a function cal=
l and
> the
> size of the inline version of the function. This can't be a very hard
> decision
> for the compiler to make, can it?

In the following example :

// In one traduction unit :

double myCos(double)
{
  // Very long calculation to compute the cosinus of an angle
}

// In another traduction unit :
double f()
{
   return myCos(0.1);
}

I believe that even with a complex myCos function, the speed could=20
greatly be improved by inlining, because f could be equivalent to:
double f()
{
   return 0,999998476913287698802901247925713;
}

I do not think the compiler would be able to know this (especially=20
without whole code analysis). But the developper can know and if he asks=20
the compiler to inline the function, but the compiler ignores his=20
request, I believe the compiler is bad.

[...]

>>For example, you can read the following thread
>><m3el01r24m.fsf@uniton.integrable-solutions.net>
>=20
> Unfortunately, I can't. That looks like an email address both to me
> and to Outlook Express.

It does look like a message Id to google group search. You can directly=20
access to it through the following link :

http://www.google.fr/groups?hl=3Dfr&lr=3D&ie=3DUTF-8&oe=3DUTF-8&threadm=3D=
m3el01r24m.fsf%40uniton.integrable-solutions.net&rnum=3D1&prev=3D/groups%=
3Fie%3DUTF-8%26oe%3DUTF-8%26as_umsgid%3D%253Cm3el01r24m.fsf%2540uniton.in=
tegrable-solutions.net%253E%26lr%3D%26hl%3Dfr

(beware of this looooooong url... !)


--=20
Lo=EFc

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

no@spam.com ("Erik") wrote in message news:<bi2v48$1t1$1@news.lth.se>...
...
> Who can do better than everyone in all cases? Not even me =)
>
> Decision of whether to inline or not should be based on a number of
> variables,
> the two major ones are (AFAIK):
> 1. The size of the function, the size of the overhead of a function call and
> the
> size of the inline version of the function. This can't be a very hard
> decision
> for the compiler to make, can it?
> 2. How inlining/outlining affects the processor cache. This is a lot harder
> for the
> compiler to decide, and virtually impossible for the human. If you need this
> kind
> of control in a very critical inner loop, you should probably write it in
> assembly
> language. Even the smallest change in the (called or calling) function (e.g.
> inlining
> another function) could radically change the performance in this case,
> voiding
> all your earlier measurements, and you have to start all over again.

There's a couple more:

3. The relative importance to the user of speed and memory usage. This
is completely unknown to the compiler, except insofar as the user
specifies it with the 'register' and 'inline' keywords, and compiler
options.

4. How frequently a given line of code will be used. A piece of code
that will be executed only once a year should probably not be
in-lined, when the extra memory used up by the inlining can be put to
better use somewhere else. A function call that occupies 90% of the
program's total execution time probably should be inlined. I've seen
compilers that provided the option of collecting profiling information
from an actual run of a program, and using it to guide the
optimizations used in a re-compile. However, many compilers lack that
capability, and even for the ones that have it, I suspect it's
frequently unused because it's a more complicated process than a
conventional compilation. The profiling run should ideally be a
thorough and fairly representative workout of all of the program's
features. Thorough and representative are conflicting requirements for
many programs, especially for programs that interact with devices or
users in real time.

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

andys@despammed.com (Andy Sawyer) writes:

> In article <yEYXa.1252$Qs2.213@nwrdny03.gnilink.net>,
>  on Wed, 6 Aug 2003 01:53:03 +0000 (UTC),
>  hyrosen@mail.com (Hyman Rosen) wrote:
>
>> There's nothing wrong with code duplication. Separation of declaration
>> and definition is an essential aspect of modularity. Once again, Ada
>> shows the way to do this properly. Java shows how to do it badly.
>
>  Java shows how not to do it at all...
[snip]

interfaces, abstract classes, and abstract methods can all be used to
    separate declaration and definition in Java. C++ essentially
    provides all of those with pure virtual functions. The compilation
    firewall idiom is probably the closest common use to using them
    for separation of definition and declaration.

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

> Actually, no but I would encourage compiler implementors to issue
> warnings for such. Even more so if the code is something like:
>
> while (true);
> {
> /* do something */}
> }
>

What exactly is wrong with that code? It is not rare to find perfectly good
code that makes use of it. Even without a way of breaking from the loop this
code serves a purpose, sometimes the program isn't supposed to exit (mostly
in embedded systems).


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

adeht wrote:
>>Actually, no but I would encourage compiler implementors to issue
>>warnings for such. Even more so if the code is something like:
>>
>>while (true);
>>{
>>/* do something */}
>>}
>>
>
>
> What exactly is wrong with that code? It is not rare to find perfectly good
> code that makes use of it. Even without a way of breaking from the loop this
> code serves a purpose, sometimes the program isn't supposed to exit (mostly
> in embedded systems).

I suspect that Francis wanted to illustrate just how
easy it is to miss the ";" at the end of the
   while (true);
line, and so expect /*do something */ to be executed
endlessly, instead of expecting a vacuous busy loop.

Nobody writes this code deliberately, and if it's on
a path that your tests don't execute then it won't be
detected unless your compiler warns or you use other
tools to check for things like this.

A variant is

if (condition);
{
   this_is_always_executed();
   so_is_this();
}

-- James.

---
[ 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 <3f34cadd$1@news.bezeqint.net>,
 on Tue, 12 Aug 2003 18:40:28 +0000 (UTC),
 ab4ds@hotmail.com ("adeht") wrote:

>> Actually, no but I would encourage compiler implementors to issue
>> warnings for such. Even more so if the code is something like:
>>
>> while (true);
>> {
>> /* do something */}
>> }
>>
>
> What exactly is wrong with that code?

Read it VERY, VERY carefully. Particularly the line that starts
"while"...and ends with ";".

> It is not rare to find perfectly good code that makes use of it.

On the contrary, I suspect it's EXTREMELY rare to find "perfectly good"
code that makes use of it. This isn't at all the same as:

while( true )
{
 /* do something */
}

Which can be found in perfectly good code.

> without a way of breaking from the loop this code serves a purpose,

Only if you consider a permenant busy-wait a purpouse.

> sometimes the program isn't supposed to exit (mostly in embedded
> systems).

Sure, but in my experience most embedded systems tend to avoid terminal
busy-waits. like the plague. In a lot of embedded systems, clock cycles
are avoided at all costs (since clock cycles cost power, and battery
life can be an issue).

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                       ]

In article <G1F_a.14881$Ye.2811@fed1read02>,
 on Thu, 14 Aug 2003 05:41:32 +0000 (UTC),
 jdennett@acm.org (James Dennett) wrote:

> adeht wrote:
>>>Actually, no but I would encourage compiler implementors to issue
>>>warnings for such. Even more so if the code is something like:
>>>
>>>while (true);
>>>{
>>>/* do something */}
>>>}
>>>
>> What exactly is wrong with that code? It is not rare to find
>> perfectly good
>> code that makes use of it. Even without a way of breaking from the loop this
>> code serves a purpose, sometimes the program isn't supposed to exit (mostly
>> in embedded systems).
>
> I suspect that Francis wanted to illustrate just how
> easy it is to miss the ";" at the end of the
>    while (true);
> line

And I suspect that adeht has demonstrated that Francis has succeeded :)

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                       ]

loic.actarus.joly@wanadoo.fr (Lo=EFc Joly) writes:

> Erik wrote:
>
>>>Well, it seems that your reflexion would be true for register, but for
>>>inline, the current compiler technology looks like it is not able to d=
o
>>>better than the programmer in all cases.
>> Who can do better than everyone in all cases? Not even me =3D)
>> Decision of whether to inline or not should be based on a number of
>> variables,
>> the two major ones are (AFAIK):
>> 1. The size of the function, the size of the overhead of a function ca=
ll and
>> the
>> size of the inline version of the function. This can't be a very hard
>> decision
>> for the compiler to make, can it?

It is very difficult for a compiler to know how the size of the
    function will affect performance. It is also difficult for a
    compiler to know how important the overhead of a function call
    is.=20

>
> In the following example :
>
> // In one traduction unit :
>
> double myCos(double)
> {
>   // Very long calculation to compute the cosinus of an angle
> }
>
> // In another traduction unit :
> double f()
> {
>    return myCos(0.1);
> }
>
> I believe that even with a complex myCos function, the speed could
> greatly be improved by inlining, because f could be equivalent to:
> double f()
> {
>    return 0,999998476913287698802901247925713;
> }
>
> I do not think the compiler would be able to know this (especially
> without whole code analysis). But the developper can know and if he
> asks the compiler to inline the function, but the compiler ignores his
> request, I believe the compiler is bad.
>
> [...]
>
>>>For example, you can read the following thread
>>><m3el01r24m.fsf@uniton.integrable-solutions.net>
>> Unfortunately, I can't. That looks like an email address both to me
>> and to Outlook Express.

Good newsreaders can follow a message-id to the message. But if you
    haven't got such a newsreader, you can get the message via google
    groups, by typing in a url of the form:
    http://groups.google.com/groups?threadm=3D<Message-ID>
    (See below.)

>
> It does look like a message Id to google group search. You can
> directly access to it through the following link :
>
> http://www.google.fr/groups?hl=3Dfr&lr=3D&ie=3DUTF-8&oe=3DUTF-8&threadm=
=3Dm3el01r24m.fsf%40uniton.integrable-solutions.net&rnum=3D1&prev=3D/grou=
ps%3Fie%3DUTF-8%26oe%3DUTF-8%26as_umsgid%3D%253Cm3el01r24m.fsf%2540uniton=
.integrable-solutions.net%253E%26lr%3D%26hl%3Dfr
>
> (beware of this looooooong url... !)

Here is a much shorter url:

http://groups.google.com/groups?threadm=3Dm3el01r24m.fsf@uniton.integrabl=
e-solutions.net
or:
http://tinyurl.com/lshh

(You can make most google groups urls shorter. One format is:
    http://groups.google.com/groups?threadm=3D<Message-ID> . The
    Message-ID is found by clicking 'Show This Article Only', then
    'Original Format', and looking at the Message-ID field in the
    headers. )




---
[ 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 <d6fkx861.fsf@evo6.com>, Andy Sawyer <andys@despammed.com>
writes
>Would you have us ban
>
>   while( true );
>
>(and all the other permutations that give the same effect) as well?
>
>Since the construct has a perfectly well-defined meaning, I don't think
>there's any reason to ban it (that it is an apparently "useless"
>construct is no reason to make it ill-formed). Or would you also ban (e.g.):
>
>while( false );
>for( ; false ; );
>
Actually, no but I would encourage compiler implementors to issue
warnings for such. Even more so if the code is something like:

while (true);
{
/* do something */}
}

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

hyrosen@mail.com (Hyman Rosen) wrote in message
news:<yEYXa.1252$Qs2.213@nwrdny03.gnilink.net>...
> Rayiner Hashem wrote:
>  > The compiler should only need to parse the header file once, > and
> store an intermediate representation somewhere for later use.

> There is no particular reason that an intermediate representation
> should be more efficient than parsing the text.

I suppose that it is possible to conceive of intermediate
representations which are worse, but overall:

  - The intermediate representation doesn't contain comments, or other
    things irrelevant to the compiler, so it should be smaller.  Less to
    read means less time taken reading.

  - The intermediate representation can use binary formats, so you don't
    have to convert numbers from ASCII to binary.

The way the preprocessor works in C/C++ makes this all a bit more
difficult, of course.

> The GNU Ada compiler does just that, and it's extremely quick. Of
> course, Ada benefits from a syntax that's straightforward instead of
> Byzantine.

> > 2) The simplistic C-compatible linkage model makes it more complex
> > than necessary for a compiler to do interprocedural analysis. It
> > also doesn't interact well at all with the template mechanism.

> Although C++ can work with old-style linkers, it's linkage model is
> not "C-compatible". You are confusing language and implementation.

The linkage model may not be "C-compatible", but the fact that it does
have to work with old-style linkers is the cause of some limitations.

> > 2) The seperation of declaration and definition makes it easy for
> > the two to get out of sync, and just causes a lot of busy-work for
> > the developer. Seperate declarations and definitions are, in essance
> > code duplication.

> There's nothing wrong with code duplication. Separation of declaration
> and definition is an essential aspect of modularity. Once again, Ada
> shows the way to do this properly. Java shows how to do it badly.

As usual, duplication is bad if it is just duplication, good if it is
redundancy, and is verified.  Having to repeat the body of an inline
function in every translation unit which uses it is bad, for example.
On the other hand, maintaining the interface definition separate from
the implementation is essential for robust programming -- using textual
inclusion to do this may not be the best solution around (in fact, it
most definitly isn't), but it is still an order of magnitude better than
no separation at all (    la Java).

--
James Kanze           GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/     http://www.gabi-soft.fr
                    Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

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

dsp@bdal.de (Daniel Spangenberg) wrote in message
news:<3F2E16AF.6F1884BC@bdal.de>...

> James Dennett schrieb:
> [snip]

> > Can you explain what benefit your suggestion has to outweight its
> > cost and the likely slowdown in compilation times that would
> > accompany it?

> The introductory example of Agent Mulder was not given to propose or
> support bad coding styles.

> Lets consider a somewhat different example:

> //weather.h
> class Cloud
> {
> public:
>   void rain();
> };

> //weather.cpp
> void Cloud::rain()
> {
> ... // Whatever
> }

> Currently, there exists no portable way to **guarantee**, that
> Cloud::rain() will **not** be inlined by modern compilers.  There even
> exist compilers which perform cross-translation unit optimizations in
> a ways which corresponds to the effect of the inline keyword.

Given the way C and C++ are specified, there is no way to even express
this requirement in terms of the standard.  All the standard specifies
is the semantics (or rather, a set of possible semantics) of a correct
program.  The standard places requirements on what the program does, not
how it does it.  It is, in fact, for precisely this reason that the
standard's requirements for inline are so far from what we actually
expect from the keyword.  There is simply no way to express our
expectations in terms of what the standard requires.

One can argue about this decision, but if you want to do so, I'd suggest
first proposing an alternative which won't get in the way of modern
optionization techniques.

> As Francis Glassborrow has pointed out: While earlier programming
> styles and language keywords mainly tried to allow compilers to
> perform as much optimaziations as possible (which is a Good Thing),
> some modern programming idioms, which are on the way to be
> standardized (think of multi-threaded programming), do actually need
> programming elements, which would give the programmer the
> **guarantee** that a particular function is **not** inlined
> (e.g. boost:call_once or a possible standardized analogon to this).

Could you explain why?  The standard requires that an inlined function
have *exactly* the same semantics as a normal one.  The standard says
nothing about threads, of course, but presumably, if threads are
introduced, this requirement won't be lifted.  And I would argue that
even today, if a compiler claims to support threads, then inline will
not change the semantics, even if threads are involved.  (With regards
to boost::call_once, I'm not familiar with the class, but I do know that
there should not normally be any problem with using Posix's pthread_once
in or with an inline function.)

--
James Kanze           GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/     http://www.gabi-soft.fr
                    Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

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

"Daniel Spangenberg" <dsp@bdal.de> wrote in message
news:3F2E16AF.6F1884BC@bdal.de...

> - Its addition is a simple extension and should not cause to give current
> existing valid programs another meaning


    I do not agree. Making a word, that was a valid identifier name a
keyword, might break some programs. Suppose a program used 'outline' or
'unline' or whatever as a name for a function or variable. This is why I
like Francis' approach of ~inline or !inline better.

regards
--
jb

(replace y with x if you want to reply by e-mail)


---
[ 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 <3F2E16AF.6F1884BC@bdal.de>, Daniel Spangenberg <dsp@bdal.de>
writes


>- This additional keyword would be very helpfull in different contexts

And my single point of disagreement is that I do not think we need a new
keyword, just new syntax with corresponding semantics.

The double token !inline (probably mostly used in the alternative
spelling of not inline) should do the job. Note that it cannot break
existing code because C++ syntax does not support inline preceded by
not.



--
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 <731020ca.0308030215.2cd706ce@posting.google.com>, Pavel
Vozenilek <pavel_vozenilek@yahoo.co.uk> writes
>rancis@robinton.demon.co.uk (Francis Glassborow) wrote in message news:<K2WX5fDU1CL$EweO@robinton.demon.co.uk>...
>> I am tempted by either !inline  or ~inline but not if it will encourage
>> people to write code like the above.
>>
>Everything may get misused.
>
>~inline would be very useful for infrequently called utility function
>like logging. It is possible to get similar effect by (time consuming
>and rather unreliable) profiler guided compilation.
>
>Btw, ~inline gives better visual clue than !inline IMHO.

except that the latter can be spelt 'not inline' while the former is
'compl inline' :-) (~ works well for dtors because they are the
complements of ctors - like open and close brackets)


--
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 <yEYXa.1252$Qs2.213@nwrdny03.gnilink.net>,
 on Wed, 6 Aug 2003 01:53:03 +0000 (UTC),
 hyrosen@mail.com (Hyman Rosen) wrote:

> There's nothing wrong with code duplication. Separation of declaration
> and definition is an essential aspect of modularity. Once again, Ada
> shows the way to do this properly. Java shows how to do it badly.

 Java shows how not to do it at all...

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                       ]

As this may be a flop I ask your attention
for only a very short time. When I code
(all) my methods inline, directly in the
class declaration like this

class Cloud
{
public:void rain()
{
//1400 lines of raining code (skipped)
for(;;); //hack to force the compiler to take this method out
}};

I need an ugly hack to prevent the compiler/
linker to inline the method. To me it seems
very logic to have an 'outline specifier' that
works exactly like inline in the opposite:

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

Another approach to prevent code from getting
inlined is the use of extern "C" as discussed on
newsgroup comp.lang.c++.moderated in the
thread Re: turn off inlining using extern "C".

I wonder if outline will ever appear in the index
of my favorite C++ book ;-)


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

Agent Mulder wrote:
>
> As this may be a flop I ask your attention
> for only a very short time. When I code
> (all) my methods inline, directly in the
> class declaration like this
>
> class Cloud
> {
> public:void rain()
> {
> //1400 lines of raining code (skipped)
> for(;;); //hack to force the compiler to take this method out
> }};
>
> I need an ugly hack to prevent the compiler/
> linker to inline the method.

So don't do that. Use source files.

--

"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

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

Agent Mulder wrote:

> When I code (all) my methods inline, directly in the class declaration
> like this
[...]
> I need an ugly hack to prevent the compiler/linker to inline the method.

So just don't write them directly in the class declaration.

The class declaration typically goes to the header file, which is then
included in many sources. It would be wasteful to recompile the function
for every module and then require the linker to pick just one version
anyway.

This already happens for templates but in this case there is no other
choice.

--
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

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

""Agent Mulder"" <mbmulder_remove_this_@home.nl> wrote in message
news:bgeag9$bf7$1@news4.tilbu1.nb.home.nl...
> As this may be a flop I ask your attention
> for only a very short time. When I code
> (all) my methods inline, directly in the
> class declaration like this
>
> class Cloud
> {
> public:void rain()
> {
> //1400 lines of raining code (skipped)
> for(;;); //hack to force the compiler to take this method out
> }};
>
> I need an ugly hack to prevent the compiler/
> linker to inline the method. To me it seems
> very logic to have an 'outline specifier' that
> works exactly like inline in the opposite:

Here's a simple resolution to your problem: don't write your code in the class
declaration. I never write code inline like that because it causes unnecessary
dependencies. So, instead of what you wrote above, do this:

// in Cloud.h
class Cloud {
public:
    void rain();
};

// in Cloud.cpp

#include "Cloud.h"

void Cloud::rain() {
    // your code
}

HTH,

sm


---
[ 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 <bgeag9$bf7$1@news4.tilbu1.nb.home.nl>, Agent Mulder
<mbmulder_remove_this_@home.nl> writes
>As this may be a flop I ask your attention
>for only a very short time. When I code
>(all) my methods inline, directly in the
>class declaration like this

That is generally considered as very poor coding.

>
>class Cloud
>{
>public:void rain()
>{
>//1400 lines of raining code (skipped)
>for(;;); //hack to force the compiler to take this method out

It doesn't, no more than putting the code in the class interface forces
the compiler to put it inline. Indeed a good compiler will just throw
that line in the bin because it obviously does nothing.

Learn to work with your compiler instead of trying to fight it.

>}};
>
>I need an ugly hack to prevent the compiler/
>linker to inline the method. To me it seems
>very logic to have an 'outline specifier' that
>works exactly like inline in the opposite:

You need no such thing, you just need to learn how to correctly express
your requirement s to the compiler. Putting everything in the class
definition is very definitely not the way to make friends with your
compiler.

>
>class Cloud
>{
>public:outline void rain()

What conceivable advantage is there to this as opposed to doing it the
way it was designed to work in C++?

>{
>//1400 lines of raining code (skipped)
>}};
>
>Another approach to prevent code from getting
>inlined is the use of extern "C" as discussed on
>newsgroup comp.lang.c++.moderated in the
>thread Re: turn off inlining using extern "C".

And as was pointed out in that thread, it does not.
>
>I wonder if outline will ever appear in the index
>of my favorite C++ book ;-)

Spelt that way? I would lay a dollar to a million that you never will
see outline as a keyword. It is a classic example of a bad candidate for
a keyword as it does not mean the right thing but has perfectly good
meanings that make it a candidate for both variable names and as a
function name. I.e. making it a keyword would break perfectly good code.

I am tempted by either !inline  or ~inline but not if it will encourage
people to write code like the above.


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

AM>class Cloud
AM>{
AM>public:void rain()
AM>{
AM>//1400 lines of raining code (skipped)
AM>for(;;); //hack to force the compiler to take this method out
AM>}};

FG>That is generally considered as very poor coding.

The design is bad on purpose. I made it up to illustrate
a point.

FG>you never will see outline as a keyword

What about unline?
class Cloud{public:unline void rain()}};

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

Agent Mulder wrote:

> AM>class Cloud
> AM>{
> AM>public:void rain()
> AM>{
> AM>//1400 lines of raining code (skipped)
> AM>for(;;); //hack to force the compiler to take this method out
> AM>}};
>
> FG>That is generally considered as very poor coding.
>
> The design is bad on purpose. I made it up to illustrate
> a point.

I for one do not see your point; it is bad practice to include
code in header files when it would more reasonably live in a
separate source file.  Why would we want to complicate C++ at
all to support such a thing?

Can you explain what benefit your suggestion has to outweight
its cost and the likely slowdown in compilation times that would
accompany it?

-- James.

---
[ 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 <bgils0$jth$1@news1.tilbu1.nb.home.nl>, Agent Mulder
<mbmulder_remove_this_@home.nl> writes
>AM>class Cloud
>AM>{
>AM>public:void rain()
>AM>{
>AM>//1400 lines of raining code (skipped)
>AM>for(;;); //hack to force the compiler to take this method out
>AM>}};
>
>FG>That is generally considered as very poor coding.
>
>The design is bad on purpose. I made it up to illustrate
>a point.
What point? That outline by any name will lead to bad habits?

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

mbmulder_remove_this_@home.nl ("Agent Mulder") wrote in message news:<bgeag9$bf7$1@news4.tilbu1.nb.home.nl>...
> class Cloud
> {
> public:void rain()
> {
> //1400 lines of raining code (skipped)
> for(;;); //hack to force the compiler to take this method out
> }};

BTW, using for(;;); is a very bad idea as it is an infinite loop that
does nothing forever.

---
[ 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 <K2WX5fDU1CL$EweO@robinton.demon.co.uk>,
 on Sat, 2 Aug 2003 22:33:28 +0000 (UTC),
 francis@robinton.demon.co.uk (Francis Glassborow) wrote:

> In article <bgeag9$bf7$1@news4.tilbu1.nb.home.nl>, Agent Mulder
> <mbmulder_remove_this_@home.nl> writes
>
>>for(;;); //hack to force the compiler to take this method out

More like "hack to ensure this function never completes"....

> It doesn't, no more than putting the code in the class interface
> forces the compiler to put it inline. Indeed a good compiler will just
> throw that line in the bin because it obviously does nothing.

A compiler that "throws that line in the bin" is clearly
non-conforming. for(;;); isn't quite "do nothing" - it's an unterminated
loop (see 6.5.3p2). (I guess you could argue that it's "do nothing, and
keep on doing it forever"...)

> Spelt that way? I would lay a dollar to a million that you never will
> see outline as a keyword.

 I dunno, with that kind of money on the table... :D

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                       ]

In article <llubpfr5.fsf@evo6.com>, Andy Sawyer <andys@despammed.com>
writes
>A compiler that "throws that line in the bin" is clearly
>non-conforming. for(;;); isn't quite "do nothing" - it's an unterminated
>loop (see 6.5.3p2). (I guess you could argue that it's "do nothing, and
>keep on doing it forever"...)

Well in the context it is close to issuing a 'halt' so perhaps it should
be ill-formed (yes I know it isn't but perhaps we should make it so)

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

mbmulder_remove_this_@home.nl ("Agent Mulder") writes:

>As this may be a flop I ask your attention
>for only a very short time. When I code
>(all) my methods inline, directly in the
>class declaration like this

>class Cloud
>{
>public:void rain()
>{
>//1400 lines of raining code (skipped)
>for(;;); //hack to force the compiler to take this method out
>}};

>I need an ugly hack to prevent the compiler/
>linker to inline the method.

Looks like you are coming from Java. :)

There is an interesting tool that takes code like what you have
written and generates the header and source files for you. (Yes, it
was written by a former Java programmer.) Have a look at
www.lazycplusplus.com. It has a few other interesting features such as
defining functional objects in a simple and intuitive way.

Hope this helps
     / Sven


--

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

francis@robinton.demon.co.uk (Francis Glassborow) wrote in message news:<K2WX5fDU1CL$EweO@robinton.demon.co.uk>...
> I am tempted by either !inline  or ~inline but not if it will encourage
> people to write code like the above.
>
Everything may get misused.

~inline would be very useful for infrequently called utility function
like logging. It is possible to get similar effect by (time consuming
and rather unreliable) profiler guided compilation.

Btw, ~inline gives better visual clue than !inline IMHO.

/Pavel

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

Marcin 'Qrczak' Kowalczyk wrote:
> Agent Mulder wrote:
>
>
>>When I code (all) my methods inline, directly in the class declaration
>>like this
>
> [...]
>
>>I need an ugly hack to prevent the compiler/linker to inline the method.
>
>
> So just don't write them directly in the class declaration.
>
> The class declaration typically goes to the header file, which is then
> included in many sources. It would be wasteful to recompile the function
> for every module and then require the linker to pick just one version
> anyway.
>
> This already happens for templates but in this case there is no other
> choice.
>

One note: the standard doesn't require that this happen for
templates either, and indeed implementations that use a
"pre-linker" to generate code from templates only once for
each instantiation are fairly common (though I confess I do
not know how this approach interacts with export, or with
two-phase name lookup in general).  Maintaining some kind
of database of instantiated templates can save a significant
amount of compilation time.

-- James.

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

Good Morning, James Dennett!

James Dennett schrieb:
[snip]

>
> Can you explain what benefit your suggestion has to outweight
> its cost and the likely slowdown in compilation times that would
> accompany it?
>
> -- James.

The introductory example of Agent Mulder was not given to propose
or support bad coding styles.

Lets consider a somewhat different example:

//weather.h
class Cloud
{
public:
  void rain();
};

//weather.cpp
void Cloud::rain()
{
... // Whatever
}

Currently, there exists no portable way to **guarantee**, that
Cloud::rain() will **not** be inlined by modern compilers.
There even exist compilers which perform cross-translation unit
optimizations in a ways which corresponds to the effect of
the inline keyword.

As Francis Glassborrow has pointed out: While earlier programming
styles and language keywords mainly tried to allow compilers to
perform as much optimaziations as possible (which is a Good Thing),
some modern programming idioms, which are on the way to be
standardized (think of multi-threaded programming), do actually need
programming elements, which would give the programmer the **guarantee**
that a particular function is **not** inlined (e.g. boost:call_once or a
possible standardized analogon to this).

In this sense, I think, that a kind of "outline" or "noinline" keyword
would support portable programming styles of such idioms. I strongly
think, that

- This additional keyword would be very helpfull in different contexts
- Its addition is a simple extension and should not cause to give current
existing valid programs another meaning
- Its realization should be relatively easy for most compiler writers (Some
compilers even provide a non-standard solution)

Greetings from Bremen,

Daniel Spangenberg





---
[ 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 <m0V8J$AahgL$Ew7U@robinton.demon.co.uk>,
 on Tue, 5 Aug 2003 02:21:50 +0000 (UTC),
 francis@robinton.demon.co.uk (Francis Glassborow) wrote:

> In article <llubpfr5.fsf@evo6.com>, Andy Sawyer <andys@despammed.com>
> writes
>>A compiler that "throws that line in the bin" is clearly
>>non-conforming. for(;;); isn't quite "do nothing" - it's an unterminate=
d
>>loop (see 6.5.3p2). (I guess you could argue that it's "do nothing, and
>>keep on doing it forever"...)
>
> Well in the context it is close to issuing a 'halt'

Close to, but not the same as. Depending on the architecture, a 'halt'
often resumes exection after an external signal (such as an interrupt)
is received. for(;;); , on the other hand, doesn't do that.

> so perhaps it should be ill-formed (yes I know it isn't but perhaps we
> should make it so)

I suspect doing so would break a surprising amount of existing code
(surprising, mostly because it's non-zero ;). I've seen it done so
hardware engineers can ensure a processor waggles=B9 the address and data
buses so they can get a 'scope probe on it... I've also seen it done to
wait for signals (not that I consider that a particularly good use for
it).

Would you have us ban

   while( true );

(and all the other permutations that give the same effect) as well?

Since the construct has a perfectly well-defined meaning, I don't think
there's any reason to ban it (that it is an apparently "useless"
construct is no reason to make it ill-formed). Or would you also ban (e.g=
.):

while( false );
for( ; false ; );


Regards,
 Andy S

Footnotes:=20
=B9  I'm assured that "waggles" is the correct technical term :)
--=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                       ]

> The class declaration typically goes to the header file, which is then
> included in many sources. It would be wasteful to recompile the function
> for every module and then require the linker to pick just one version
> anyway.
>
> This already happens for templates but in this case there is no other
> choice.

C++'s module system needs to get with the 90's.

1) The text-include system makes compilation take longer than it
should. The compiler should only need to parse the header file once,
and store an intermediate representation somewhere for later use.
Today, it took my compiler (GCC 3.2.2 on a 2GHz P4) nearly a full
minute to compile a single 100 LOC file that used Boost.Python.
Templates are going to get more complex (especially if we get
metafunctions in C++ 0x!) so the problem isn't going away anytime
soon.

2) The simplistic C-compatible linkage model makes it more complex
than necessary for a compiler to do interprocedural analysis. It also
doesn't interact well at all with the template mechanism.

2) The seperation of declaration and definition makes it easy for the
two to get out of sync, and just causes a lot of busy-work for the
developer. Seperate declarations and definitions are, in essance code
duplication. Its much better to have a tool like Doxygen extract a
succinct interface description from a class than it is to make the
developer maintain interface descriptions.

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

Rayiner Hashem wrote:
 > The compiler should only need to parse the header file once,
> and store an intermediate representation somewhere for later use.

There is no particular reason that an intermediate representation
should be more efficient than parsing the text. The GNU Ada compiler
does just that, and it's extremely quick. Of course, Ada benefits
from a syntax that's straightforward instead of Byzantine.

> 2) The simplistic C-compatible linkage model makes it more complex
> than necessary for a compiler to do interprocedural analysis. It also
> doesn't interact well at all with the template mechanism.

Although C++ can work with old-style linkers, it's linkage model is
not "C-compatible". You are confusing language and implementation.

> 2) The seperation of declaration and definition makes it easy for the
> two to get out of sync, and just causes a lot of busy-work for the
> developer. Seperate declarations and definitions are, in essance code
> duplication.

There's nothing wrong with code duplication. Separation of declaration
and definition is an essential aspect of modularity. Once again, Ada
shows the way to do this properly. Java shows how to do it badly.

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