work related dig regarding separation of definitions and implementations

[noone]

Hi.

I've got a fella working for me who is trying to convince me to change our
coding standards to using separate .h and .cc files for definitions and
implementations. I know this is a perfectly valid way of doing things but
in my mind it is kind of quirky. Here's why.

The first reason I'd resist deals with the simplicity of makefiles. When
including most code from headers where classes are protected by #ifdef
blocks the makefile doesn't have to have a separate build rule for each
class.

Next, TTBOMK you need to do your classes in header files if you are going
to make them into generic templates...well, putting them into headers
isn't strictly a requirement but the other restrictions for (templatizable
code) would encourage only using headers.

I understand that there a a couple of reasons why you might want separate
definitions and implementation, such as when a class has a static data
member, or if you intend to create a shared object library of class code,
but it seems to me that putting the code into the header files is a bit
more elegant and the other way would be more of a holdover from the old
days before templates.

I'm wondering what comments the upper echelon lurkers might have. Do they
agree with my reasoning, or can they give me reasons why I should
reevaluate my assertions.

 

[Victor Bazarov]

I've got a fella working for me who is trying to convince me to
change our coding standards to using separate .h and .cc files for
definitions and implementations. I know this is a perfectly valid
way of doing things but in my mind it is kind of quirky. Here's why.

The first reason I'd resist deals with the simplicity of makefiles.
When including most code from headers where classes are protected by
#ifdef blocks the makefile doesn't have to have a separate build rule
for each class.

Next, TTBOMK you need to do your classes in header files if you are
going to make them into generic templates...well, putting them into
headers isn't strictly a requirement but the other restrictions for
(templatizable code) would encourage only using headers.

I understand that there a a couple of reasons why you might want
separate definitions and implementation, such as when a class has a
static data member, or if you intend to create a shared object
library of class code, but it seems to me that putting the code into
the header files is a bit more elegant and the other way would be
more of a holdover from the old days before templates.

I'm wondering what comments the upper echelon lurkers might have. Do
they agree with my reasoning, or can they give me reasons why I should
reevaluate my assertions.

I know of no "upper echelon lurkers", so forgive my barging in, but
I have only one issue to mention: speed of compilation. As soon as
you cross a hundred file barrier (and have a team of more that three
people), you'll probably want to separate your implementation in
a different translation unit for each class so that it could be
independently compiled and not cause recompilation of all other
translation units that include it.

C++ was designed with large scale systems in mind. That's not the
only paradigm it supports, but it's the most important, if you ask me.
If your system is small, no big deal. Keep your headers full of code
and don't bother. We used to do that in Pascal, didn't we? Then
along came units, and suddenly we could split the development into
several relatively independent pieces... You can do it nowadays in
C++ with many modern compilers that support precompiled headers, of
course. But then again, once code changes you need to recompile
most of them again... Kind of PITA.

V

 

[Alf P. Steinbach]

* noone:

I've got a fella working for me who is trying to convince me to change our
coding standards to using separate .h and .cc files for definitions and
implementations. I know this is a perfectly valid way of doing things but
in my mind it is kind of quirky. Here's why.

Rather, having all code in header files is the unusual way.

The first reason I'd resist deals with the simplicity of makefiles. When
including most code from headers where classes are protected by #ifdef
blocks the makefile doesn't have to have a separate build rule for each
class.

Builds nowadays are mostly automated. Anyway, even with hand-crafted
make files you can lay down some general rules.

Next, TTBOMK you need to do your classes in header files if you are going
to make them into generic templates...well, putting them into headers
isn't strictly a requirement but the other restrictions for (templatizable
code) would encourage only using headers.

Even template code can benefit from a separation into header and
implementation. For most template classes that means including the
implementation file in the header file. The main advantage is that the
header file can give a very concise overview and defines the logical
interface, whereas with just one big file it's not that clear what's
interface and what's implementation detail. A possible but very
improbable advantage is that with compiler support for 'export' (only
Comeau right now, as far as I know) this can also reduce build times.

I understand that there a a couple of reasons why you might want separate
definitions and implementation, such as when a class has a static data
member

Can be done in header file via template trick.

, or if you intend to create a shared object library of class code,

AFAICS that is irrelevant except for the headers the client code needs.

but it seems to me that putting the code into the header files is a bit
more elegant and the other way would be more of a holdover from the old
days before templates.

I'm wondering what comments the upper echelon lurkers might have. Do they
agree with my reasoning, or can they give me reasons why I should
reevaluate my assertions.

One reason to separate the two is that with all the code in headers, any
build of the system involves all of the code, which is slow (precompiled
headers have their own problems). And with all code in header files,
you force a remake of dependent modules when only the implementation is
changed, compounding that problem. A third reason to separate is to be
free to use any implementation techniques that suit the problem, instead
of doing very "clever" things and going amok with namespacing.

 

[noone]

C++ was designed with large scale systems in mind. That's not the only
paradigm it supports, but it's the most important, if you ask me. If your
system is small, no big deal. Keep your headers full of code and don't
bother. We used to do that in Pascal, didn't we? Then along came units,
and suddenly we could split the development into several relatively
independent pieces... You can do it nowadays in C++ with many modern
compilers that support precompiled headers, of course. But then again,
once code changes you need to recompile most of them again... Kind of
PITA.

Thanks for your comments. I do understand your point. Our systems
definitely fall into the category of many small embedded programs with a
well defined message passing API to communicate between the processes.

Thanks for the followup.

 

[noone]

On Tue, 23 Jan 2007 05:29:55 +0100, Alf P. Steinbach wrote:

Hi.

I should probably clarify what I mean by "all the code"

I'm talking about utility classes. The individual program logic is of
course still in .cc files. I try to encourage class coding where the
methods are suitable for implicit inline compilation.

And as I mentioned to Victor, the projects are numerous small embedded
software component programs of less than 1000 lines including comments.

The utility classes are things like C++ wrappers around socket networking,
a joystick driver (which does use a separate .cc file only because it uses
signals and requires a static data member to point to the class instance
that is needed to register in the polling timer), message passing
wrappers. interfaces to kernel drivers, etc.

Your points are well taken. I think based on scale it is a tradeoff right
now. The whole unmanned system operating environment compiles in less
than two minutes on a single CPU Xeon machine.