Putting implmentation in .h files?

[Plissken.s]

Hi,

Can you please tell me what is the guideline in Putting implmentation
in .h files?
I see examples where they put the implementation of getter/setting in
the .h files where funcitons is > 10 lines of code are put in .cpp
file.

Is that the guideline?

Thank you.

 

[Alex Beluga]

Hello!

I see two cases as to where you put the implementation in .h file:
1. When you have a template class and you don't want to mess with pImpl
stuff.
2. When you have really small and calling very often functions that you
will put into a declaration of class. Please, consider that every
function that is in decl. of class is automaticallly an inline.

class foo
{
public:
int bar(); //declared somewhere else
void haha() //this is automatically inline
{
//some small code
}
};

 

[Backer]

Normally the decleraions are made in the header files and implentaions
are in cpp file. But templates should be declared and implement in the
header file itself.

 

[Stephan Rupp]

Normally the decleraions are made in the header files and implentaions
are in cpp file. But templates should be declared and implement in the
header file itself.

.... or you hide away the implementation of a template's declarations in
a separate .inl file and include it with a last statement in the
template's header. So, you can emulate separation of interface and
implementation details for templates - an approach I usually prefer and
recommend.

Greets

 

[Alex Beluga]

Normally the decleraions are made in the header files and implentaions
are in cpp file. But templates should be declared and implement in the
header file itself.

.... or you could use the pImpl idiom like Boost-developers.

 

[Martin Vejnar]

<OT>

[snip]

class foo
{
public:
int bar(); //declared somewhere else
void haha() //this is automatically inline
{
//some small code
}
};

I was amused a few days ago, when I found out, that metasyntactic
variables have been mentioned even in RFC (RFC 3092, it's dated 1st
April 2001; coincidence? ) )

They list "standard" metasyntactic variables in the order they "should"
be used in code examples: foo, bar, baz, qux, quux, corge, grault,
garply, waldo, fred, plugh, xyzzy, thud.

So, correctly, your example should go like this:

class foo
{
public:
int bar(); //declared somewhere else
void baz() //this is automatically inline
{
//some small code
}
};

;o)

</OT>

 

[Alex Beluga]

Thanks a lot! I think we should post this request in the neighbourly
residing comp.std.c++ or at least try to push it into Boost.

 

[Roland Pibinger]

... or you hide away the implementation of a template's declarations in
a separate .inl file and include it with a last statement in the
template's header. So, you can emulate separation of interface and
implementation details for templates - an approach I usually prefer and
recommend.

Your approach may be usful but it neither hides the implementation of
templates nor emulates the separation of interface and implementation
for templates.

Best wishes,
Roland Pibinger

 

[Kai-Uwe Bux]

Hi,

Can you please tell me what is the guideline in Putting implmentation
in .h files?
I see examples where they put the implementation of getter/setting in
the .h files where funcitons is > 10 lines of code are put in .cpp
file.

Is that the guideline?

There is no universal guideline. It all depends on the project and the
community/culture. The technical reason for separating interface and
implementation is to ease separate compilation, which reduces build times
in large projects. For small projects, I do not see a technically
compelling reason at all to separate definition and declaration. From a
programmers point of view, the only reasons that remain are about meeting
the reasonable expectations regarding code layout of your fellow
programmers and your future self. Those expectations tend to vary from
project to project.


Best

Kai-Uwe Bux

 

[Alex]

Hello

What's pImpl stuff?

Thanks.

 

[Ian Collins]

Normally the decleraions are made in the header files and implentaions
are in cpp file. But templates should be declared and implement in the
header file itself.

Please quote what you are replying to.

Many compilers support template implementation in separate source files
that don't have to be included.

 

[Roland Pibinger]

Many compilers support template implementation in separate source files
that don't have to be included.

Which?

 

[Ian Collins]

Which?

Sun and last time I used them, Microsoft and at least one embedded
compiler I've used.

There are rules for the name and location of the source file, but they
don't have to be included.

 

[osmium]

What's pImpl stuff?

It's called a "desing pattern". Try this search in google:

<"design pattern" pimpl>

 

[Alex Beluga]

Many compilers support template implementation in separate source files

that don't have to be included.

Well, I'd rather not think of them because export of template is such a
horribly slow thing that it's better for compiling speed (what it's all
about) to keep source in headers.

Sincerely yours, Aleksander Beluga.

 

[Ian Collins]

Well, I'd rather not think of them because export of template is such a
horribly slow thing that it's better for compiling speed (what it's all
about) to keep source in headers.

Not if the compiler knows where to find the source.

 

[Axter]

Sun and last time I used them, Microsoft and at least one embedded
compiler I've used.

There are rules for the name and location of the source file, but they
don't have to be included.

That's incorrect. There are only two comercial compilers that support
the C++ export keyword, and that's Comeau and Intel C++.
I would not call two compilers many.

I think you're mistaking the idea of being able to compile template
code and only using it in a single *.cpp file (translation unit), with
the idea of being able to use the template code in one *.cpp file
(translation unit), from another *.cpp file (translation unit).

Without a compiler supporting the export keyword, the only way you can
exteranlly use template code in a *.cpp file, is by declaring forward
template declaration within the file that contains the template code.
But then that limits you to only using the types that have been forward
declared.

 

[Ian Collins]

That's incorrect. There are only two comercial compilers that support
the C++ export keyword, and that's Comeau and Intel C++.
I would not call two compilers many.

No, it's nothing to do with export.

Some compilers when they attempt to instantiate template code where the
definition isn't in the header have a set of search rules used to find a
matching cc/cpp file containing the code. Normally this defaults to a
file with the same name in the same directory. More like an implicit
include.

So id X.h contains

template <typename Y>
class X
{
X(int);
}

and X.cc contains

template <typename Y>
X:X( int ) {}

the compiler will find the constructor code in X.cc.

I think you're mistaking the idea of being able to compile template
code and only using it in a single *.cpp file (translation unit), with
the idea of being able to use the template code in one *.cpp file
(translation unit), from another *.cpp file (translation unit).

At least one compiler I use keeps a cache of instantiated templates and
checks this before instantiating, giving the same result.

Without a compiler supporting the export keyword, the only way you can
exteranlly use template code in a *.cpp file, is by declaring forward
template declaration within the file that contains the template code.
But then that limits you to only using the types that have been forward
declared.

Or in the example above, include the header.