inline class functions in separate file

[John Goche]

Hello,

I have been going through several header source files which define
classes with inline functions. In the case where the inline functions
are not defined in place, the inline functions from all classes within
the header file are included via a separate file, at the end of the
file, with a directive of the form:

#include <foo.inl>

Could anyone explain what the reason could be for separating the
inline functions into a separate file in this way?

Thanks,

JG

 

[mlimber]

Hello,

I have been going through several header source files which define
classes with inline functions. In the case where the inline functions
are not defined in place, the inline functions from all classes within
the header file are included via a separate file, at the end of the
file, with a directive of the form:

#include <foo.inl>

Could anyone explain what the reason could be for separating the
inline functions into a separate file in this way?

It's probably due to the lack of the export keyword. See this FAQ:

http://www.parashift.com/c++-faq-lite/templates.html#faq-35.13

Cheers! --M

 

[Bart]

It's probably due to the lack of the export keyword. See this FAQ:

http://www.parashift.com/c++-faq-lite/templates.html#faq-35.13

The 'export' keyword has nothing to do with inline functions. Inline
functions obviously have to be fully defined (not just declared) at
compile time instead of linking time, because the intent is to insert
the code of the function directly where the call is made (*). That's
why we make the definition visible to the compiler through an #include
directive.

(*) The compiler has a veto on whether this really happens or not, but
the requirement still holds nonetheless.

Regards,
Bart.

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

I have been going through several header source files which define
classes with inline functions. In the case where the inline functions
are not defined in place, the inline functions from all classes within
the header file are included via a separate file, at the end of the
file, with a directive of the form:

#include <foo.inl>

Could anyone explain what the reason could be for separating the
inline functions into a separate file in this way?

A possible reason is that the authors want to keep open the posibility to
drop the inlines and separately compile the implementation of the files,
and they want to be able to make the change with a minimal edition.

They can have guidelines, or automated documentation tools, that considers
that all the contents of header files is public API, and the .inl are not.

They can want to separate the #include required for the class declaration
from those used by the implemantation, and consider that the separation in
two files is the clearer way to do it.

The reason can simply be "In this company we do it that way from some years
ago, nobody remember the rationale and nobody want to take the work to redo
the style guides".

To know the real reason in each case, you must ask the authors.

 

[mlimber]

The 'export' keyword has nothing to do with inline functions. Inline
functions obviously have to be fully defined (not just declared) at
compile time instead of linking time, because the intent is to insert
the code of the function directly where the call is made (*). That's
why we make the definition visible to the compiler through an #include
directive.

(*) The compiler has a veto on whether this really happens or not, but
the requirement still holds nonetheless.

Boy, I'm just not having a good day at reading posts correctly. You are
right about the inline business, but absent any actual code, my
comments about export may also apply. Additionally, it strikes me that
the OP may be asking why functions would not be defined within the
class. That may just be a stylistic issue in the case of non-template
functions (e.g., the author wants to emphasize the public interface
rather than its implementation), but in the case of template functions,
it may also be because of specialization.

Cheers! --M