inline class member functions

[Srini]

Hello,

Rules for inline functions say that they have to be defined in the same
compilation unit as their declarations. For class member functions this
means that the inline member functions must be defined either within
the class or within the same header file.

But its generally a good programming practice to have the declarations
and definitions in seperate files. This would make the future
maintenance of the code easier.

If I follow this guideline for inline class member functions, even
though the class implementation would compile, I'd have linker problems
when I link this class object file with others.

Hence, as a workaround for this situation, I thought that if I take the
address of the inline member functions, the compiler would be forced to
put the inline member functions in the object files. This would take
care of the linking problems.

My doubt, however, is this - by doing so, will the compiler stop
inlining the calls to that function?

Thanks is advance...

Regards,
Srini

[David White]

"Srini" <sr*********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Hello,

Rules for inline functions say that they have to be defined in the same
compilation unit as their declarations. For class member functions this
means that the inline member functions must be defined either within
the class or within the same header file.
Not necessarily. I've sometimes put a definition of a private inline
function into the only source file in which it's used. Of course that's
still in the same compilation unit as the declaration.
But its generally a good programming practice to have the declarations
and definitions in seperate files. This would make the future
maintenance of the code easier.
I keep them in separate files if I want to switch between inline (for
release) and non-inline (for debug). For that I use 'INLINE' instead
'inline' and #define INLINE appropriately for each case, and then I include
the file containing the definitions into either the source file or the
header file based on an #ifdef.
If I follow this guideline for inline class member functions, even
though the class implementation would compile, I'd have linker problems
when I link this class object file with others.
Not if you #include the definitions file in the header file.
Hence, as a workaround for this situation, I thought that if I take the
address of the inline member functions, the compiler would be forced to
put the inline member functions in the object files. This would take
care of the linking problems.
My doubt, however, is this - by doing so, will the compiler stop
inlining the calls to that function?

Yes. If you get linker errors without that, then the compiler can't see the
inline definitions.

Here's an example of what I've sometimes done.

// Header file:
#ifndef ARCVER_H_
#define ARCVER_H_

class ArcVersion
{
public:
ArcVersion(BYTE version);
// other members
private:
BYTE m_ver;
};

#ifdef ENABLE_INL
#undef INLINE
#define INLINE inline
#include "arcver.inl"
#endif

#endif

// INL file
INLINE ArcVersion::ArcVersion(BYTE version)
{
m_ver = version;
}

// CPP file
#include "arcver.h"

#ifndef ENABLE_INL
#undef INLINE
#define INLINE
#include "arcver.inl"
#endif

Just enable ENABLE_INL or not to switch between inline and non-inline.

DW

[Srini]

Hi David,

Thanks for your reply.

I see what you're doing in your example. My reasoning for taking the
address of the
inline member functions, as a workaround was this. Something similar to
const variables.
const vars are never allocated on the stack. Instead they are held in
the compiler symbol
table. Unless we try to take its address. Even then, the compiler would
guarantee that
the variable remains constant if we never make use of the pointer.

const int a = 100;
int *ptr = const_cast<int *>(&a);

If we never use "ptr", the compiler would still guarantee that
something like this
is flagged as an error.

a = 200; // sorry mate - can't do that!

In the same lines, inlines are also held in the compiler symbol table.
If I take the
address of that function, the compiler would put it in object file.
But, as in case of
const vars, would the compiler inline the calls to that function?

I know that const and inline are two entirely different concepts - this
was just my thought.
Can you please comment on this?

[David White]

"Srini" <sr*********@gmail.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Hi David,

Thanks for your reply.

I see what you're doing in your example. My reasoning for taking the
address of the
inline member functions, as a workaround was this. Something similar to
const variables.
const vars are never allocated on the stack. Instead they are held in
the compiler symbol
table.
I believe that the compiler can implement const values however it likes.
Obviously, it makes sense for the compiler to generate code with these
values embedded in code as hard-wired constants if that is the most
efficient implementation on a given processor.
Unless we try to take its address.
Taking the address would not necessarily make any difference except where
the address is used.
Even then, the compiler would
guarantee that
the variable remains constant if we never make use of the pointer.

const int a = 100;
int *ptr = const_cast<int *>(&a);

If we never use "ptr", the compiler would still guarantee that
something like this
is flagged as an error.
Well, if you do try to modify 'a' through your pointer it is undefined
behaviour.

a = 200; // sorry mate - can't do that!
Of course. The constness of 'a' is unrelated to its address being taken
somewhere. Your pointer 'ptr' merely forces the compiler to provide an
addressable instance of 'a' somewhere. It doesn't mean that all uses of 'a'
will be forced to fetch that addressable value from memory.
In the same lines, inlines are also held in the compiler symbol table.
If I take the
address of that function, the compiler would put it in object file.
But, as in case of
const vars, would the compiler inline the calls to that function?

I know that const and inline are two entirely different concepts - this
was just my thought.
Can you please comment on this?

As I said, if you get linker errors on inline functions it means that the
compiler saw the declarations but not the definitions. I've no doubt that
the functions would not be inlined if you make the errors go away by taking
the address. I also suggest that taking the address would not necessarily
make the linker errors go away, even if they went away in your case. I'm not
sure that just because you've taken the address is it guaranteed that the
function provided for the address-of operation will be recognized by the
linker as the function to call for the inline calls for which the compiler
could not find the definitions.

BTW, I don't agree that it is better programming practice to separate
declarations and definitions than to keep them together. I would think that
most programmers keep inline declarations and definitions in the same header
file, and I don't see a problem with that. Do you?

DW

[Srini]

Hi David,

Thanks for all your comments.

BTW, I don't agree that it is better programming practice to separate declarations and definitions than to keep them together. I would think that most programmers keep inline declarations and definitions in the same header file, and I don't see a problem with that. Do you?

Yes - Now I tend to agree with you. I dont see much problems with it.
:-)

Thanks again.

Regards,
Srini

[lilburne]

David White wrote:

BTW, I don't agree that it is better programming practice to separate
declarations and definitions than to keep them together. I would think that
most programmers keep inline declarations and definitions in the same header
file, and I don't see a problem with that. Do you?

Actually we keep the inline definitions seperate from the declarations
for the same reason that you mentioned (release vs debug builds).
However, in general though we found that inline methods are a
botheration that does not merit their usage. Except for our very
low-level geometry classes (points, vectors, workplanes) we've yet to
see a profile report that has indicated that inlining would result in a
measurable speed improvement.

[msalters]

Srini wrote:

Hello,

Rules for inline functions say that they have to be defined in the same compilation unit as their declarations. For class member functions this means that the inline member functions must be defined either within
the class or within the same header file.

But its generally a good programming practice to have the declarations and definitions in seperate files. This would make the future
maintenance of the code easier.

Yes. It's called a trade-off. "inline" makes maintenance harder but
performance higher. So, use in on the functions that really matter.

HTH,
Michiel Salters

[David White]

"lilburne" <li******@godzilla.net> wrote in message
news:3a*************@individual.net...

David White wrote:

BTW, I don't agree that it is better programming practice to separate
declarations and definitions than to keep them together. I would think that most programmers keep inline declarations and definitions in the same header file, and I don't see a problem with that. Do you?

Actually we keep the inline definitions seperate from the declarations
for the same reason that you mentioned (release vs debug builds).
However, in general though we found that inline methods are a
botheration that does not merit their usage. Except for our very
low-level geometry classes (points, vectors, workplanes) we've yet to
see a profile report that has indicated that inlining would result in a
measurable speed improvement.

The usefuleness of inlined functions depends very much on the application.
In my spare time for the last year or so I've been working on a program for
solving Pocoman puzzles (http://www.sleepless.com/pocoman). The execution
times of the optimized-for-speed release build for one case are:
~10 seconds (inline "any suitable", in VC++ 6.0)
~25 seconds (inline "Disable")

DW