inline class member functions

Discussion in 'C++' started by Srini, Mar 29, 2005.

  1. Srini

    Srini Guest

    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
    Srini, Mar 29, 2005
    #1
    1. Advertising

  2. Srini

    David White Guest

    "Srini" <> wrote in message
    news:...
    > 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
    David White, Mar 29, 2005
    #2
    1. Advertising

  3. Srini

    Srini Guest

    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?
    Srini, Mar 29, 2005
    #3
  4. Srini

    David White Guest

    "Srini" <> wrote in message
    news:...
    > 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
    David White, Mar 29, 2005
    #4
  5. Srini

    Srini Guest

    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
    Srini, Mar 30, 2005
    #5
  6. Srini

    lilburne Guest

    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.
    lilburne, Mar 30, 2005
    #6
  7. Srini

    msalters Guest

    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
    msalters, Mar 30, 2005
    #7
  8. Srini

    David White Guest

    "lilburne" <> wrote in message
    news:...
    > 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
    David White, Mar 31, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    3
    Views:
    447
  2. Daniel Vallstrom
    Replies:
    2
    Views:
    1,829
    Kevin Bracey
    Nov 21, 2003
  3. Rahul
    Replies:
    3
    Views:
    440
    James Kanze
    Feb 28, 2008
  4. Hicham Mouline
    Replies:
    0
    Views:
    419
    Hicham Mouline
    Apr 23, 2009
  5. Hicham Mouline
    Replies:
    1
    Views:
    404
    Michael DOUBEZ
    Apr 24, 2009
Loading...

Share This Page