dietmar_kuehl@yahoo.com (Dietmar Kuehl) wrote in message news:<5b15f8fd.0308040527.6e88333e@posting.google.com>...
> tobias.langner@t-online.de (Tobias Langner) wrote:
> > Inline is just some sort of optimization (and has actually nothing to do
> > with how you write your .h/.cpp files).
>
> This is not entirely correct. Although 'inline' is indeed intended mainly
> as an optimization it also has another effect: Normally, a function can
> only be defined in one translation unit. If a function is declared as
> inline, it may be defined in multiple translation unit and actually has to
> be defined in all translation units using this function. If you insist in
> defining a function in a header (ie. a file included into multiple
> translation units) you have several choices to avoid violating the one
> definition rule:
>
> - You can declare the function to be 'inline'.
> - You can declare the function to be 'static' (this applies only to
>   function on namespace scope).
> - You can turn the function into a template.

  - You can put the function into an anonymous namespace.

Randy.

>
> However, I agree that something turning things out of line is pretty
> useless: bigger functions are not inlined anyway and duplicate codes are
> removed from the final executable with typical linkers (there is no
> guarantee by the standard, though; instead, this is QoI issue). This may
> yield huge intermediate libraries but the final executable should normally
> be OK.
> --
> <mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
> Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>
>
> ---
> [ 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                       ]

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

I don't know if I did get this right with inline -
isn't inline just a statement to tell the compiler that it might possibly
consider to replace the function call (with all the pushes, pops and
returns) with the direct code of the function (like mov eax, [bla]; inc
eax;).
In my opinion, no compiler would ever inline a function with 1400+ lines of
code. It's useless. Your exe, elf whatever would just bloat to enormous
size.
There is no need for outline, it's the standard way a compiler does his job.
Inline is just some sort of optimization (and has actually nothing to do
with how you write your .h/.cpp files).

Please correct me if I'm wrong.

---
[ 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 <bgjmbc$1m8$02$1@news.t-online.com>, Tobias Langner
<tobias.langner@t-online.de> writes
>There is no need for outline, it's the standard way a compiler does his job.
>Inline is just some sort of optimization (and has actually nothing to do
>with how you write your .h/.cpp files).

inline is a request to the compiler to 'inline the body of the function'
how cooperative the compiler is is left open. A conforming compiler of
very poor quality could simply always ignore the request. However the
intention was more like 'If you *can* inline this function, do so.'

Now the problem is that compilers are getting better. For almost a
decade some compilers have been inlining simple static functions. Some I
believe can do partial inlining (that would be a reason to use early
returns for simple cases something that could support SEME coding styles
but that is a different debate). We are now getting implementations
where the decision to inline can be made at link time. Those of us who
go way back to coding in assembler know that there are two critical
sizes for inlining 1) code small enough so that the inline version takes
no more space than the call 2) code so big that even a two calls will
take less space than inlining. In between those points inlining can
produce smaller faster code if the function is called sufficiently few
times. But only the linker could know that for non-static functions.

As I understand it, there are certain cases where a programmer
explicitly wants a function call and explicitly does not want the
compiler to substitute the body of the code for the call even though a
quality compiler would do so implicitly. If this is the case then we
need another 'anti-optimisation' keyword.

--
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 <YE3zlTCR0gL$Ewex@robinton.demon.co.uk>,
 on Mon, 4 Aug 2003 07:51:59 +0000 (UTC),
 francis@robinton.demon.co.uk (Francis Glassborow) wrote:

> As I understand it, there are certain cases where a programmer
> explicitly wants a function call and explicitly does not want the
> compiler to substitute the body of the code for the call even though a
> quality compiler would do so implicitly. If this is the case then we
> need another 'anti-optimisation' keyword.

In those cases where there's a legitmate use for "not inline", it's not
so much an "anti-optimisation", as a different kind of optimisation.

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 I understand it, there are certain cases where a programmer
> explicitly wants a function call and explicitly does not want the
> compiler to substitute the body of the code for the call even though a
> quality compiler would do so implicitly. If this is the case then we
> need another 'anti-optimisation' keyword.
>
Could you name one? because I can't think of one (except debugging, where
compiler optimization should be at a minimum anyway)

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

tobias.langner@t-online.de (Tobias Langner) wrote:
> Inline is just some sort of optimization (and has actually nothing to do
> with how you write your .h/.cpp files).

This is not entirely correct. Although 'inline' is indeed intended mainly
as an optimization it also has another effect: Normally, a function can
only be defined in one translation unit. If a function is declared as
inline, it may be defined in multiple translation unit and actually has to
be defined in all translation units using this function. If you insist in
defining a function in a header (ie. a file included into multiple
translation units) you have several choices to avoid violating the one
definition rule:

- You can declare the function to be 'inline'.
- You can declare the function to be 'static' (this applies only to
  function on namespace scope).
- You can turn the function into a template.

However, I agree that something turning things out of line is pretty
useless: bigger functions are not inlined anyway and duplicate codes are
removed from the final executable with typical linkers (there is no
guarantee by the standard, though; instead, this is QoI issue). This may
yield huge intermediate libraries but the final executable should normally
be OK.
--
<mailto:dietmar_kuehl@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>

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