"Tony Johansson" <johansson.andersson@telia.com> wrote in message
news:O4O3e.21142$d5.156815@newsb.telia.net...[color=blue]
> I'm reading a book about C++ and there is something about inline that the
> book says that is unclear for me.[/color]
And for a good reason...
[color=blue]
> The book says the following "Because inline functions are expanded at
> compile time, definitions of these
> functions, unlike other definitions, cannot be separately compiled and
> must be placed in header files.[/color]
So far so good: the above is correct.
[color=blue]
> This creates a problem if the compiler does not actually inline a
> funktion(you may end up having multiple definitions of the same function).[/color]
Nearly correct: because the function(/its body) is defined in a header,
the compiler may generate compiled code for it multiple times.
E.g. once in the object file (.o) of each source file (.cpp)
that includes the header where the function is defined.
The same may occur with template functions (also typically
defined in a header), as well as some implicitly-generated
functions (e.g. constructors, destructors, copy-assignment members).
However, a modern C++ linker will typically discard the
redundant object-code copies of the same function, and
in any case no error shall be reported.
[color=blue]
> Therefore, you have to check that the inline functions will actually be
> inlined, and if they
> cannot be inlined, you must remove the inline specification."[/color]
You could check if inlining has occured, in multiple platform-specific
ways (by somehow inspecting the generated code or link map, or by
using a specific output possibly provided by your compiler.
However, wheter inlining has occured or not is compiler-dependent,
and even compile-option dependent (e.g. inlining may be disabled
in debug builds). In any case, 'inline' is only a *hint* to the
compiler. Like the now pointless 'register' keyword, 'inline' is
destined to become less and less relevant as optimizing compilers
and linkers are getting smarter.
[color=blue]
> Here is the question about the text above that has been extracted from the
> book. I understand the first sentence but not the second sentence. It says
> "This creates a problem if the compiler does not actually inline a
> funktion(you may end up having multiple definitions of the same
> function)". I'don't understand how it is possible to end up with two
> definitions?[/color]
Only one definitions, but eventually redundant copies of the compiled code.
[color=blue]
> Sentence three says "Therefore, you have to check that the inline
> functions will actually be inlined, and if they
> cannot be inlined, you must remove the inline specification.". How can I
> check that a function is really inlined?[/color]
You don't bother doing so.
One would typically only inline "trivial" functions such as simple
accessor member functions, and not bother about the final result
(until eventually having to profile and optimize the code).
I hope this helps clarify things,
Ivan
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
