Re: Inline functions
On Jul 5, 2:13 pm, "Alf P. Steinbach /Usenet" <alf.p.steinbach
+use...@gmail.com> wrote:
* James Kanze, on 05.07.2010 14:56:
On Jul 5, 11:05 am, "Alf P. Steinbach /Usenet"<alf.p.steinbach
+use...@gmail.com> wrote:
* Suresh V, on 05.07.2010 11:46:
[...]
Being inline also serves as a vague hint to the compiler about
inlining the machine code (to the extent that that's
practically possible for this compiler and routine, if it's
done).
The hint is far from vague. The standard contains a very clear
expression of the intent of inline, and a compiler which ignores
that intent without reason is defective, at least from a QoI
point of view. (It's often useful to ignore it when debugging,
and most compilers have an option to prevent inlining, for
debugging purposes.)
Consider a mostly header-only library such as Boost.
Rather atypical, I think. (And Boost isn't all header-only.)
Consider how a compiler would have to treat it in order to
inline everything that's technically 'inline', which for Boost
is most everything.
I was under the impression that the parts of Boost which are
header only were header only because they were templates, not
because they were inline. Some parts of Boost (e.g.
Boost::bind) probably are mostly inline; those that depend on
a lot of small functions which basically do nothing (except
allow the compiler to choose something based on function
overload resolution). Any good compiler had better inline
those. For the rest, I don't know---the parts I've used
(thread, regex) don't make that much use of inline functions,
except for small forwarding functions.
In short, your "without reason" encompasses much more than
a cursory reading of your argument would imply, and makes the
argument pretty much moot: 'inline' is by logical necessity
a very very weak hint.
The intent is that it be a very, very strong hint. Generally
speaking, to be respected *except* when the compiler is so
advanced that it can systematically do better than the
programmer, or because the programmer has asked for something
unreasonable (e.g. inlining a recursive function).
Of course, this really doesn't change the issue much with
regards to the original poster's question. The compiler may
have any number of more or less valid reasons for not inlining
the function (and of course, most compilers will also inline
functions not declared inline, if appropriate).
The hint is nothing that you should rely on, though, and it's
not the primary thing. The only sure, guaranteed behavior
resulting from 'inline' is the multiple-definition behavior
-- and it has nothing to do with lifetime.
The hint is the primary reason for using inline.
Sorry, no, that's just bull as a general statement. Again,
consider a mostly header-only library such as Boost. For sure,
some folks use 'inline' the way you indicate, so for them
that's primary, but generalizing that is invalid.
It's the design reason. And a quick glance at one or two Boost
headers (format, thread) suggest that it's the main reason in
Boost as well---at least, the inline functions I see there are
ones that the compiler really should generate inline (since they
will disappear completely once it does). (But one can't make
many global statements about Boost, since it is the work of so
many different people.)
It's true that you can't rely on it. But really, you
wouldn't make anything inline before the profiler said it
was necessary.
Oh yes, I would.
Again, consider a mostly header-only library such as Boost.
The reason that most things are inline in Boost is /not/
profiling, it's simply that for a mostly header-only library
the code would break the One Definition Rule if things were
not 'inline' -- it would be invalid code.
Except that the "mostly header-only" libraries in Boost are also
mostly templates. And template functions can be multiply
defined without breaking the one definition rule. (Take a look
at boost::format, for example.)
And given the profiler output before and after making
something inline, you can pretty well determine whether it
helped or not (and it's a lot easier to make something
inline than to hand code a lot of other optimizations).
Yeah, but the optimization aspect is the lesser aspect (by
a wide margin) of 'inline'.
That's simply false. Except in a few very special cases, it's
the only reason to use inline.
The optimization is not guaranteed behavior, and it's not the
reason why most Boost things are inline.
Examples, please. It's the obvious justification in the couple
of examples I've looked at. And in cases where optimization
doesn't justify inline, the Boost code I've looked at doesn't
use inline.
The guaranteed behavior is about the One Definition Rule.
The only formally guaranteed behavior, yes. But that's really
a behavior that we tolerate (not desire) in order to facilitate
the specific opimization by the compiler.
--
James Kanze