Inline Functions

[A]

Hi,

I'm having problems completing a project in C++. I have been using inline
functions in some of my header files. I have only done so for simple
functions that only have 1 statement (eg. accessor and mutator methods to
access private data members). I would like to know if there are any issues
with using inline functions that may have attributed to my errors before I
start separting them out into "outline functions".

Regards
kl

[Kevin Goodsell]

A wrote:

Hi,

I'm having problems completing a project in C++. I have been using inline
functions in some of my header files. I have only done so for simple
functions that only have 1 statement (eg. accessor and mutator methods to
access private data members). I would like to know if there are any issues
with using inline functions that may have attributed to my errors before I
start separting them out into "outline functions".

I'm not aware of any particular general problems with inline functions.
Do you mean functions that use the 'inline' keyword, or functions that
are defined within the class definition?

class Foo
{
public:
void inline_func() { cout << "this is an inline function" << endl; }
};

inline void inline_func() { cout << "this is also an inline function" <<
endl; }

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

[Gregg]

"A" <[e-mail]> wrote in message
news:3f********@news.iprimus.com.au...

Hi,

I'm having problems completing a project in C++. I have been using inline
functions in some of my header files. I have only done so for simple
functions that only have 1 statement (eg. accessor and mutator methods to
access private data members). I would like to know if there are any issues
with using inline functions that may have attributed to my errors before I
start separting them out into "outline functions".

Regards
kl

It would help if you indicated what errors you were getting.

There should not be any restrictions on using inline functions instead of
regular functions, although there is no guarantee that the function will
actually be inlined.

--
Gregg

[A]

"Kevin Goodsell"

A wrote:

Hi,

I'm having problems completing a project in C++. I have been using inline functions in some of my header files. I have only done so for simple
functions that only have 1 statement (eg. accessor and mutator methods to access private data members). I would like to know if there are any issues with using inline functions that may have attributed to my errors before I start separting them out into "outline functions".

I'm not aware of any particular general problems with inline functions.
Do you mean functions that use the 'inline' keyword, or functions that
are defined within the class definition?

class Foo
{
public:
void inline_func() { cout << "this is an inline function" << endl; }
};

inline void inline_func() { cout << "this is also an inline function" <<
endl; }

-Kevin

I mean functions that are defined within a class definition. In this
context, I don't believe you need to prefix the modifier "inline" to these
function definitions. By the way, what is the meaning of prefixing inline
for a function defined outside a class definition?

KL

[Gregg]

"A" <[e-mail]> wrote in message
news:3f**********@news.iprimus.com.au...

I mean functions that are defined within a class definition. In this
context, I don't believe you need to prefix the modifier "inline" to these
function definitions. By the way, what is the meaning of prefixing inline
for a function defined outside a class definition?

KL

The "inline" keyword tells the compiler not to make the function name
visible to other translation units. If you leave out this keyword, you might
get linker errors indicating "duplicate symbol definitions" or something
similar if the header is included in two different translation units. The
"inline" is implied when the function is defined within the class
definition.

--
Gregg

[Agent Mulder]

<A>

I'm having problems completing a project in C++. I have been using inline
functions in some of my header files. I have only done so for simple
functions that only have 1 statement (eg. accessor and mutator methods to
access private data members). I would like to know if there are any issues
with using inline functions that may have attributed to my errors before I
start separting them out into "outline functions".

</A>

Whether you inline or not will not make any difference to
the meaning of the function, so any errors you have cannot
be attributed to inline.

class Bear
{
void Pluche(){}
};

is the same as

class Bear
{
void Pluche();
};
inline void Bear::Pluche(){}

and also the same as

class Bear
{
inline void Pluche();
}
void Bear::Pluche(){}

I am not certain about the third assesment, though.

-X

[Attila Feher]

A wrote:

Hi,

I'm having problems completing a project in C++. I have been using
inline functions in some of my header files. I have only done so for
simple functions that only have 1 statement (eg. accessor and mutator
methods to access private data members). I would like to know if
there are any issues with using inline functions that may have
attributed to my errors before I start separting them out into
"outline functions".

As the keeper of the X-files pointed out: it is very very unlikely that from
a language point of view they would make any difference. However ther is
another point to this. If you keep chaning them and you fail to recompile
all implementation files including those inline functions you may end up
violating the ODR (One Definition Rule). It is also worth to note that
inline functions may have an out-of-line body generated by the compiler.
Depending on your linker and link order those may also mix things up unless
you really recompile everything including the header with the inline
functions.

Having said all that those are very good reasons to only start inlining when
your profiling shows the functions to be a bottleneck. Otherwise you will
create dependencies with no value.

It is also a common technique to put inline functions into a separate file
(not the header, not the implementation) and include that file into the
header (inlined) or the implementation (not inlined) depending on a
preprocessor macro you define in your <OT>makefile or the compiler command
line</OT>. You can make those macros also one per class and a major one to
make everything out-of-line. In that case if you want to check if inlines
give you trouble or you want a clean profiling again you just recompile
everything without them.

While inlines in theory will not change the meaning of your code one cannot
rule out some sort of compiler error. Also agressive optimization can
completely optimize away inline functions if all of their input is compile
time constant and all of their output is their return value (no side
effects). But then again this should not change the meaning. But if the
compiles fails and optimizes too much...

A sidenote: accessor/mutator methods usually are a sign of inferior OOD
(Object Oriented Desing) where the classes do not really represent a
coherent concept.

--
Attila aka WW

[Marcelo Pinto]

"Gregg" <gr***********@hotmail.com> wrote in message news:<xl*******************@newsread2.news.atl.ear thlink.net>...

"A" <[e-mail]> wrote in message
news:3f**********@news.iprimus.com.au...

I mean functions that are defined within a class definition. In this
context, I don't believe you need to prefix the modifier "inline" to these
function definitions. By the way, what is the meaning of prefixing inline
for a function defined outside a class definition?

KL

The "inline" keyword tells the compiler not to make the function name
visible to other translation units. If you leave out this keyword, you might
get linker errors indicating "duplicate symbol definitions" or something
similar if the header is included in two different translation units. The
"inline" is implied when the function is defined within the class
definition.

Isn't this behavior of the static qualifier?

Regards,

Marcelo Pinto

[Alf P. Steinbach]

On 22 Sep 2003 10:16:34 -0700, mp****@tecnolink.com.br (Marcelo Pinto) wrote:

"Gregg" <gr***********@hotmail.com> wrote in message news:<xl*******************@newsread2.news.atl.ear thlink.net>...

The "inline" keyword tells the compiler not to make the function name
visible to other translation units. If you leave out this keyword, you might
get linker errors indicating "duplicate symbol definitions" or something
similar if the header is included in two different translation units. The
"inline" is implied when the function is defined within the class
definition.

Isn't this behavior of the static qualifier?

With 'static' you get a local definition in each compilation unit.

With 'inline' you get at most one definition, with a good compiler,
unless the function is also 'static'.

I'm not sure whether that last is a std. requirement on 'inline' or
not, and won't look it up for you, but it's practice.

[Gregg]

"Marcelo Pinto" <mp****@tecnolink.com.br> wrote in message
news:e3**************************@posting.google.c om...

"Gregg" <gr***********@hotmail.com> wrote in message

news:<xl*******************@newsread2.news.atl.ear thlink.net>...

The "inline" keyword tells the compiler not to make the function name
visible to other translation units. If you leave out this keyword, you might get linker errors indicating "duplicate symbol definitions" or something
similar if the header is included in two different translation units. The "inline" is implied when the function is defined within the class
definition.

Isn't this behavior of the static qualifier?

Regards,

Marcelo Pinto

Of course the visibility thing isn't the only thing "inline" does. Its
raison d'etre is to tell the compiler to inline the function if it can

--
Gregg

[Andrey Tarasevich]

Gregg wrote:

...
The "inline" keyword tells the compiler not to make the function name
visible to other translation units.
No, that's not the case. (It would be great if you could explain what
exactly you mean under 'visible', but in any case 'inline' keyword
doesn't do anything that would fit this description.)

Note that inline functions have external linkage (unless explicitly
declared as 'static'), which means that the implementation must be able
to identify the same inline function defined in different translation
units in order to satisfy the requirements of external linkage (for
example, address of the function must be the same in all translation units).
If you leave out this keyword, you might
get linker errors indicating "duplicate symbol definitions" or something
similar if the header is included in two different translation units. The
"inline" is implied when the function is defined within the class
definition.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

[Gregg]

"Andrey Tarasevich" <an**************@hotmail.com> wrote in message
news:vm************@news.supernews.com...

Gregg wrote:

...
The "inline" keyword tells the compiler not to make the function name
visible to other translation units.

No, that's not the case. (It would be great if you could explain what
exactly you mean under 'visible', but in any case 'inline' keyword
doesn't do anything that would fit this description.)

Maybe "visible" isn't the correct technical term, but I meant visible in the
sense that standard sections 3.2.3 and 7.1.2.4 imply. I.e., unlike a
non-inline function, an inline function is allowed to be defined in more
than one translation unit without being declared static. In fact it is
required to be defined in any translation unit that uses it.

--
Gregg

[Sektor van Skijlen]

Alf P. Steinbach <al***@start.no> wrote:
# On 22 Sep 2003 10:16:34 -0700, mp****@tecnolink.com.br (Marcelo Pinto) wrote:

# >"Gregg" <gr***********@hotmail.com> wrote in message news:<xl*******************@newsread2.news.atl.ear thlink.net>...
# >>
# >> The "inline" keyword tells the compiler not to make the function name
# >> visible to other translation units. If you leave out this keyword, you might
# >> get linker errors indicating "duplicate symbol definitions" or something
# >> similar if the header is included in two different translation units. The
# >> "inline" is implied when the function is defined within the class
# >> definition.
# >
# >
# >Isn't this behavior of the static qualifier?

# With 'static' you get a local definition in each compilation unit.

# With 'inline' you get at most one definition, with a good compiler,
# unless the function is also 'static'.

# I'm not sure whether that last is a std. requirement on 'inline' or
# not, and won't look it up for you, but it's practice.

The 'inline' function is (firstly) required to be defined once per
compilation unit (in practice, it is required that inline functions be
DEFINED in header files). There are two characteristic things concerning
inline functions (which are not static simultaneously):

1. If a compiler decides to make inlining for this function, the linkage
does not concern it. However, since the compiler relies on function
definition from the compilation unit, it must be provided. If it is not,
this function falls under normal linkage, however... this is undefined
behavior.

2. If a compiler will not make inline version, this function falls under
normal linkage, as if there is no 'inline' modifier. However it means that
this function falls under so-called "weak linkage" (inline functions and
virtual method table are the only objects fallen under "weak linkage").

The difference between "strong linkage" and "weak linkage" is that in that
first case the linker will report an error due to definition conflict if
there are two object definitions found in separate module files (compilation
units; *.o/*.obj). For "weak linkage", the linker will not report this
error, however it is UNDEFINED, which definition (from which of module files)
will be effectively selected for the executable! Sometimes it even depends on
the order of file names passed to link command. That's why all inline function
definitions must be:
a) provided separately for each compilation unit
b) defined THE SAME in each compilation unit

Many good compilers (such as gcc) provide always an outline version for each
inline function. Remember also that the decision about expanding a function
inline depends also on compiler options.

Regards,
--
1 6 1 7 4 4 2 548 g4bc7a4 66z 3xt7w v1y z9p1 120 32
(( Michal "Sektor" Malecki w4 66 64 73 7564 24 5 v 34 4
)) ektor van Skijlen 1 5 5 1 844 a v r z 4
Software engineer, Motorola GSG Poland 1 2 2a 1 4
WARNING: Opinions presented by me on usenet groups are my personal opinions
ONLY and are not connected to the employer.

[Sektor van Skijlen]

Agent Mulder <mb*******************@home.nl> wrote:

# <A>
# > I'm having problems completing a project in C++. I have been using inline
# > functions in some of my header files. I have only done so for simple
# > functions that only have 1 statement (eg. accessor and mutator methods to
# > access private data members). I would like to know if there are any issues
# > with using inline functions that may have attributed to my errors before I
# > start separting them out into "outline functions".
# </A>

# Whether you inline or not will not make any difference to
# the meaning of the function, so any errors you have cannot
# be attributed to inline.

# class Bear
# {
# void Pluche(){}
# };

# is the same as

# class Bear
# {
# void Pluche();
# };
# inline void Bear::Pluche(){}

# and also the same as

# class Bear
# {
# inline void Pluche();
# }
# void Bear::Pluche(){}

Wrong. This one above is a regular function (and therefore must not be
defined in *.h file). That first example is however the same as below:

class Bear
{
void Pluche() {}
};

--
1 6 1 7 4 4 2 548 g4bc7a4 66z 3xt7w v1y z9p1 120 32
(( Michal "Sektor" Malecki w4 66 64 73 7564 24 5 v 34 4
)) ektor van Skijlen 1 5 5 1 844 a v r z 4
Software engineer, Motorola GSG Poland 1 2 2a 1 4
WARNING: Opinions presented by me on usenet groups are my personal opinions
ONLY and are not connected to the employer.