using inline

[Tony Johansson]

Hello experts!

I reading a book called programming with design pattern revealed
by Tomasz Muldner and here I read something that sound strange.

Here is the whole section:
It says" 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. This creates a problem if the compiler does not
actually inline
a function (you may end up having multiple definitions of the same function)
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."


My question is what does it mean with this This creates a problem if the
compiler does not actually inline
a function (you may end up having multiple definitions of the same function)
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.

Many thanks

//Tony

 

[Srini]

Hello experts!

I reading a book called programming with design pattern revealed
by Tomasz Muldner and here I read something that sound strange.

Here is the whole section:
It says" 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.

inline is not a hard and fast rule that the compiler has to obey. Its
just a hint to the compiler. If the compiler decides to inline the call
to an inline function, its *definition* must be visible to the compiler
at the place of the call. This is why inline functions are usually
defined in the header files itself.

This creates a problem if the compiler does not
actually inline
a function (you may end up having multiple definitions of the same function)
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."

My question is what does it mean with this This creates a problem if the
compiler does not actually inline
a function (you may end up having multiple definitions of the same function)
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.

I don't understand why the author has quoted it like this. Usually
there are gaurd directives for every header files that make sure that
the same header is not included more than once during the compilation
process.

#ifndef HEADER_FILENAME
#define HEADER_FILENAME

// ... Header file stuff here

#endif

So, it does not matter what the compiler decides with a call to an
inline function - there should be no problems of multiple definitions
of the function if the gaurd directives are in place. And there's no
way to check whether a call to an inline function will be actually
inlined or not. Its completely at the discretion of the compiler.

Many thanks

//Tony

HTH
Srini

 

[peter.koch.larsen]

Tony Johansson skrev:

Hello experts!

I reading a book called programming with design pattern revealed
by Tomasz Muldner and here I read something that sound strange.

Here is the whole section:
It says" 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. This creates a problem if the compiler does not
actually inline
a function (you may end up having multiple definitions of the same function)
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."


My question is what does it mean with this This creates a problem if the
compiler does not actually inline
a function (you may end up having multiple definitions of the same function)
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.

Many thanks

//Tony

This means that your book is probably better used for non-reading
purposes. What is said is just plain wrong.

/Peter

 

[Serge Paccalin]

Le jeudi 11 août 2005 à 15:00, Srini a écrit dans comp.lang.c++ :

I don't understand why the author has quoted it like this. Usually
there are gaurd directives for every header files that make sure that
the same header is not included more than once during the compilation
process.

#ifndef HEADER_FILENAME
#define HEADER_FILENAME

// ... Header file stuff here

#endif

So, it does not matter what the compiler decides with a call to an
inline function - there should be no problems of multiple definitions
of the function if the gaurd directives are in place.

Hmm, I don't understand it that way. The compilation guards protect
against multiple inclusion of a header file in one compilation unit, but
the author seems to worry about the use of the header file in several
compilation units leading to several instances of the (not-)inlined
function in the linked binary.

Well, that would be a problem if the function name caused a "Symbol
multiply defined" error at link-time. I don't remember such a situation.

As for the function-code duplication, if that worries the programmer,
why would have happened if the inline keyword had been honored, anyway?

And there's no
way to check whether a call to an inline function will be actually
inlined or not. Its completely at the discretion of the compiler.

You may even get a mixture of both in your program, on a per-call basis.

--
___________ 11/08/2005 15:35:21
_/ _ \_`_`_`_) Serge PACCALIN -- sp ad mailclub.net
\ \_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763

 

[Pete Becker]

My question is what does it mean with this This creates a problem if the
compiler does not actually inline
a function (you may end up having multiple definitions of the same function)
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.

This is simply wrong. The compiler and linker team up to take care of
this. It sounds like you've found another book that you should get rid
of. <g>

 

[E. Robert Tisdale]

My question is,
"What does it mean with this This creates a problem
if the compiler does not actually inline a function
(you may end up having multiple definitions of the same function)
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.

It's just wrong.
Take this book back where you found it and get your money back.