.cpp or .h?

[Ivan Liu]

Hi,
if I have the choice between puting a class in .h file or in .cpp file,
which one is more efficient?

I prefer putting in .h file because the compilation and linking are
easier since I don't need to include so many .cpp files in the command.
But my guess is that there is a drawback though I don't know what
exactly.

Could anyone answer my question?

Thanks a lot
Ivan

 

[Frederick Gotham]

Ivan Liu posted:

if I have the choice between puting a class in .h file or in .cpp file,
which one is more efficient?

Efficiency has nothing to do with it.

I prefer putting in .h file because the compilation and linking are
easier since I don't need to include so many .cpp files in the command.
But my guess is that there is a drawback though I don't know what
exactly.

Could anyone answer my question?

Show me a small sample program and I'll offer my advice. I tend to put class
definitions in header files... although I have put them in source code files
from time to time, usually in an anonymous namespace.

 

[Alf P. Steinbach]

* Ivan Liu:

if I have the choice between puting a class in .h file or in .cpp file,
which one is more efficient?

First, note that the C++ standard does not refer to files: you can name
your source code files, if indeed the source code resides in files!,
whatever you want, as far as the language standard is concerned.

Also, the C++ standard doesn't address efficiency (except in the sense
of O(n) and the like for standard library functions), so the question
can't be answered in terms of the C++ standard, which with some special
exceptions should be the case for every posting to this group.

Presumably what you're asking is whether it's "more efficient", in some
undisclosed sense, to use #include to drag in member function
definitions, as opposed to compiling them separately.

Efficiency as programmer time: yes, often. But some things are /easier/
to do with separate compilation. For example, defining a class scope
'static' constant of type 'double' is easier with separate compilation.

Efficiency as compilation time excluding linking: no, not particularly,
because there will in general be more source code to compile (because
the same source code is typically compiled more than once).

Efficiency as linking time: depends very much on the tools.

I prefer putting in .h file because the compilation and linking are
easier since I don't need to include so many .cpp files in the command.

Check out tools for automating the build process. One tool you should
check out immediately is your command line interpreter, and its support
of wildcard file specifications. Questions regarding that are, however,
off-topic in this group (in general).

 

[Jerry Coffin]

Hi,
if I have the choice between puting a class in .h file or in .cpp file,
which one is more efficient?

I prefer putting in .h file because the compilation and linking are
easier since I don't need to include so many .cpp files in the command.
But my guess is that there is a drawback though I don't know what
exactly.

One drawback is that most make utilities aren't terribly brilliant about
things -- they only look at file times to determine what needs to be re-
compiled when you re-build a project.

If you put an entire class in a header, _every_ other file that uses
that class will be re-compiled every time you change the class at all,
even in ways that are purely internal to the class and don't really
affect any code that uses it.

If you put only the class definition in the header, and put the
implementations of most of its member functions in a separate source
file, you only force a re-compile of other code when/if you change the
interface to the class, not just something internal to its
implementation.

Another potential drawback is that putting the whole class definition in
a header also means that all the class' member functions are implemented
as inline functions. If they're big enough that the compiler decides not
to produce inline code for them, you end up with a separate copy of the
function for each source file that uses objects of this class. Depending
on your development system, the linker may merge those copies into one
function -- but then again, it may not.

 

[Alf P. Steinbach]

* Jerry Coffin:

Another potential drawback is that putting the whole class definition in
a header also means that all the class' member functions are implemented
as inline functions. If they're big enough that the compiler decides not
to produce inline code for them, you end up with a separate copy of the
function for each source file that uses objects of this class. Depending
on your development system, the linker may merge those copies into one
function -- but then again, it may not.

As I recall there is a requirement that the function has the same
address in all compilation units.

 

[Markus Grueneis]

Hi,
if I have the choice between puting a class in .h file or in .cpp file,
which one is more efficient?

Efficient in respect to ... ?

Some nitpicking: you probably meant class definition.

I prefer putting in .h file because the compilation and linking are
easier since I don't need to include so many .cpp files in the command.

You really should use Makefiles or the project managment system of your
favourite IDE. They exist for a reason. (I think you just discovered
it...)

But my guess is that there is a drawback though I don't know what
exactly.

Depending on compiler, project size, use of diverse features and the
like the compilation time may suffer between a little and very much. It
should not really matter for the resulting code.

It's usually said to be good practize keeping compilation units as small
as possible, and always just exhibiting as little information as
necessary (i.e., use forward declarations where possible, use only
interfaces, use only class declarations, and as last resort, put the
whole thing into a header (sometimes necessary with templates)).

This has usually the benefit of much faster compilation, the benefit
getting bigger as your project grows. If you use some really template
heavy stuff for just one of your classes (for instance boost::spirit),
compilation times can get unacceptable, even for small projects.

Additionally, putting everything into one place opens the door to bad
tricks. You probably will fail on some point to recognize certain
unnecessary depencies, which will cost time when you want to reuse your
code later, in another environment. And as we are humans, somebody
usually will start to rely on specific implementation of the other
classes interface (as they are always completly available), which can
(and will) lead to problems after a few months (because we all document
all our assumptions, don't we?).


best regards,
-- Markus

 

[Jerry Coffin]

As I recall there is a requirement that the function has the same
address in all compilation units.

If it has external linkage, that's correct.

 

[Rolf Magnus]

* Ivan Liu:

First, note that the C++ standard does not refer to files:

That's actually wrong. From the C++ standard:

The text of the program is kept in units called source files in this
International Standard.

 

[Alf P. Steinbach]

* Rolf Magnus:

That's actually wrong. From the C++ standard:

The text of the program is kept in units called source files in this
International Standard.

Yes. I should perhaps have written "does not refer to OS file system
files for the code". It's the same word, "file", for historical and
practical reasons, but C++ source files are simply not necessarily OS
file system files -- and C++ headers, whatever mystical beasts they
are, are not necessarily C++ source files, whatever /they/ are, which is
especially important to keep in mind when using conventions such as the
Unix forward slash in #include directives to improve portability.

The standard only goes out of its way to explain the latter difference
for standard library headers, in note #158 in §7.4.1.2/1, "A header is
not necessarily a source file".

The only problem with this is that the standard uses this terminology
inconsistently with existing practice. In §16.2/2 we're told that
'#include <blah>' searches for a header (only), while in §16.2/3 we're
told that '#include "bleh"' searches first for a source file, and if
that fails, then it searches as with angle brackets, i.e. for a header.
This might be deemed a defect: in practice the difference is not for a
search for headers, on the one hand, and a search for source files and
then possibly for headers, on the other, but that #include with quotes
introduces additional implementation-defined searching at the start.

 

[Alf P. Steinbach]

* Alf P. Steinbach:

* Rolf Magnus:

Yes. I should perhaps have written "does not refer to OS file system
files for the code". It's the same word, "file", for historical and
practical reasons, but C++ source files are simply not necessarily OS
file system files

I forgot to include an actual example.

Consider the following Windows command line session:

T:\> type con | g++ -x c++ - & a
#include <iostream>
#include <ostream>
int main() { std::cout << "This is permitted." << std::endl; }
^Z
This is permitted.

T:\>

In this case the source code does not reside in an OS file system file,
yet that does not preclude a translation (compilation) that starts with
§2.1/1/1 "Physical source file characters are mapped...". From the OS /
reality point of view the source code is provided by a "pipe". In the
standard's terminology, that pipe constitutes a "source file".