Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > inline class member functions

Reply
Thread Tools

inline class member functions

 
 
Srini
Guest
Posts: n/a
 
      03-29-2005
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

 
Reply With Quote
 
 
 
 
David White
Guest
Posts: n/a
 
      03-29-2005
"Srini" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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



 
Reply With Quote
 
 
 
 
Srini
Guest
Posts: n/a
 
      03-29-2005
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?

 
Reply With Quote
 
David White
Guest
Posts: n/a
 
      03-29-2005
"Srini" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) 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



 
Reply With Quote
 
Srini
Guest
Posts: n/a
 
      03-30-2005
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

 
Reply With Quote
 
lilburne
Guest
Posts: n/a
 
      03-30-2005


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.

 
Reply With Quote
 
msalters
Guest
Posts: n/a
 
      03-30-2005

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

 
Reply With Quote
 
David White
Guest
Posts: n/a
 
      03-30-2005
"lilburne" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
overloading non-template member functions with template member functions Hicham Mouline C++ 1 04-24-2009 07:47 AM
overloading non-template member functions with template member functions Hicham Mouline C++ 0 04-23-2009 11:42 AM
Multiple functions (one version being inline and other beingnon-inline) Rahul C++ 3 02-28-2008 03:28 PM
Tool which expands implicitly inline inline functions tthunder@gmx.de C++ 3 06-16-2005 12:54 AM
External inline functions calling internal inline functions Daniel Vallstrom C Programming 2 11-21-2003 01:57 PM



Advertisments