Re: Inline functions
On Jul 5, 10:51 pm, Ian Collins <ian-n...@hotmail.com> wrote:
On 07/ 6/10 12:56 AM, James Kanze wrote:
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.)
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.
Surly the multiple-definition behaviour is the primary reason
for using inline?
Actually, it's the primary reason for avoiding it. In a typical
development environment, the multiple-definition behavior
replaces a link-time error with truly undefined (and somewhat
random) behavior. Not something particularly desirable. The
fact that the code has to be in the header increases coupling.
Significantly if the function is non-trivial. The only
justification for having inline at all is performance.
The hint is just that, a hint. Odds are the same functions
will be unlined whether the inline keyword is present or not.
And that some will be inlined even if the inline keyword is not
present. That's why the use has to be profiler driven.
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. 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).
The only way for force inline is is to use any pragmas
provided by the compiler to override its inline selection
heuristics.
And how is that relevant? You are trying to optimize code.
Depending on the compiler, different techniques may or may not
be appropriate. Inline is a useful technique: it has the
advantage that it is very, very easy to use, and that it is
guaranteed to compile with the same semantics everywhere---you
don't need #ifndef's or whatever to use it. (Although you
might, if e.g. it results in the code running slower on some
other compiler.) If it works (i.e. the results become "fast
enough"), you win. If it doesn't, you haven't lost too much
time exploring a dead-end alley.
The only entity that can really make use of profiler output in
determining inline selection is the compiler itself though
profile feedback optimisations.
That's the ideal situation, and such compilers typically will
ignore the hint. Once such compilers become common place,
I imagine that inline will go the way of register. But we're
not there yet.
If you do go down the manual inline route, you will have to
profile on every processor variant you wish to deploy your
application.
Possibly. That's often the case when your code isn't fast
enough. (Of course, it may be just one platform on which it
isn't fast enough. In that case, that's the only one you have
to profile.)
--
James Kanze