«

Hi,

I'm a bit rusty with the wonderful language of c++. I worked with it,
maybe 6 or 7 years ago and now I need to knock the dust off. But I was
perusing some code when I noticed that this one programmer put the
entire class in the header file. I'm not sure what the point to that
is. Can someone please enlighten me as to why you would want to do
this?

And if you do want to, what are the pro's and cons of doing it. Are
there times you don't want to do this?

DaTurk wrote:
> I'm a bit rusty with the wonderful language of c++. I worked with it,
> maybe 6 or 7 years ago and now I need to knock the dust off. But I
> was perusing some code when I noticed that this one programmer put the
> entire class in the header file.

What do you mean by "entire"? With member function _definitions_?
Lacking the clarity, I'll just assume that it's what you meant.

Just to let you know: if you see a curly brace after the class name
(or after the base class[es] name[s]), it's a class *definition*.
It ends with a closing curly brace and usually a semicolon. When
you talk of member function definitions, then they collectively are
called "class implementation". A class *definition* can (allowed to)
only contain member function *declarations*.

> I'm not sure what the point to that
> is. Can someone please enlighten me as to why you would want to do
> this?
>
> And if you do want to, what are the pro's and cons of doing it. Are
> there times you don't want to do this?

In most cases if the functions are small, letting them be defined in
the class definition is a way to make them 'inline' implicitly thus
allowing the compiler to produce faster code. It is also a way to
keep everything close-by, and not have an extra translation unit to
compile (and link with).

The most commonly quoted drawback of putting the implementation in
the header is that every time you need to change it, other modules
(translation units) need to be recompiled. So, for real-world large
systems, it's more common to keep the implementation details in the
header to a minimum.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On 2007-01-24 19:56, DaTurk wrote:
> Hi,
>
> I'm a bit rusty with the wonderful language of c++. I worked with it,
> maybe 6 or 7 years ago and now I need to knock the dust off. But I was
> perusing some code when I noticed that this one programmer put the
> entire class in the header file. I'm not sure what the point to that
> is. Can someone please enlighten me as to why you would want to do
> this?
>
> And if you do want to, what are the pro's and cons of doing it. Are
> there times you don't want to do this?


Usually you don't want to put more than the declaration in the header-
file since this allows you to compile the definitions separately and
avoids having to recompile any file that includes the header file when
the implementation (but not the interface) changes.

However for some code you must put some or all in the header-file. When
dealing with templates the full definition must be available to the file
that includes your header, and the definition must thus also be in the
header-file (or a file included by the header-file).

Personally I don't see any advantage of putting the code in the header
unless you have to, or if the code is very small, so the work associated
with having to separate the declaration from definition is relatively
large (it's never much work).

A disadvantage would be that it can increase compile-time, for large
projects the difference can be quite much.

--
Erik Wikström

> The most commonly quoted drawback of putting the implementation in
> the header is that every time you need to change it, other modules
> (translation units) need to be recompiled. So, for real-world large
> systems, it's more common to keep the implementation details in the
> header to a minimum.

I'll agree with Victor's pros. One more pro: it's one less file to
deal with.

On the cons, there's one more - it might introduce additional
dependencies. For example, let's say I have a class like this:

class MyClass {
<bunch of stuff missing>
double GetComplicatedFunction() const {
/* do some complicated function that involves classes X, Y, Z.
*/
}
}

Now, if I put the implementation in the header file, I have to include
X.h, Y.h, and Z.h there. Then any class that uses MyClass has
dependencies on X.h, Y.h, and Z.h. If, on the other hand, I put the
implementation in the .cpp file, and only the declaration in the .h
file:

class MyClass {
<bunch of stuff missing>
double GetComplicatedFunction() const;
}

in this case, MyClass.cpp still needs to include X.h, Y.h, and Z.h, but
lots of other files don't need to include it recursively. So if you
change something in X.h, you wouldn't need to recompile nearly as much,
whereas in the first case, you'd have to recompile everything that used
MyClass.

This kind of thing really gets bad when you have larger projects, and
there's a huge benefit to minimizing dependencies.

Michael

Michael wrote:
> On the cons, there's one more - it might introduce additional
> dependencies. For example, let's say I have a class like this:
>
> class MyClass {
> <bunch of stuff missing>
> double GetComplicatedFunction() const {
> /* do some complicated function that involves classes X, Y, Z.
> */
> }
> }
>
> Now, if I put the implementation in the header file, I have to include
> X.h, Y.h, and Z.h there. Then any class that uses MyClass has
> dependencies on X.h, Y.h, and Z.h. If, on the other hand, I put the
> implementation in the .cpp file, and only the declaration in the .h
> file:
>
> class MyClass {
> <bunch of stuff missing>
> double GetComplicatedFunction() const;
> }
>
> in this case, MyClass.cpp still needs to include X.h, Y.h, and Z.h, but
> lots of other files don't need to include it recursively. So if you
> change something in X.h, you wouldn't need to recompile nearly as much,
> whereas in the first case, you'd have to recompile everything that used
> MyClass.
>
> This kind of thing really gets bad when you have larger projects, and
> there's a huge benefit to minimizing dependencies.
>

The technical term is "unnecessary coupling" and it's a major
maintenance and unit testing nightmare.

You can't put normal member function declarations in the header, unless
they're template definitions or inlined. Otherwise, you'll have
multiple definitions of the same function and get a linker error.

wrote:
> You can't put normal member function declarations in the header, unless
> they're template definitions or inlined. Otherwise, you'll have
> multiple definitions of the same function and get a linker error.
>
Not if they are within a class/struct declaration. There they are
implicitly inline.

--
Ian Collins.