confused about .h and .cpp definition vs implementation

[michael.goossens]

Hello everyone,
maybe some usefull information first: I'm a student, I can program and
most of my experience is in java but I always had the feeling java is
"the easy way out" so now I'm interested in some c++. I'm longing to
make a speedy raytracer and that is why I need c++ and need to learn
alot about how it works internally to see what choices are the best
way for an optimal speed result.

I have some troubles understanding the concepts of a header and all
around it. It seems that a header has the purpose to define classes
and functions. But its also possible to actually implement the classes
and functions in there. But why would someone do that? Is it better?

I see three options of implementation at the moment:

1) defining a header with the definitions and implement them in a .cpp
file
2) defining a header with the definitions and the implementations
3) using a cpp file and implement it all in there.

So what are the pro's and contras here? Currently I'm using using
option 1 since I learned it that way in a basic OO-language course.

Also, it is possible to define a range of multiple classes in the same
header file, why would I want that over the 1 header - 1 class
structure that I'm using now(probably a java influence here).

 

[Alf P. Steinbach]

* (e-mail address removed):

Hello everyone,
maybe some usefull information first: I'm a student, I can program and
most of my experience is in java but I always had the feeling java is
"the easy way out" so now I'm interested in some c++. I'm longing to
make a speedy raytracer and that is why I need c++ and need to learn
alot about how it works internally to see what choices are the best
way for an optimal speed result.

I have some troubles understanding the concepts of a header and all
around it. It seems that a header has the purpose to define classes
and functions. But its also possible to actually implement the classes
and functions in there. But why would someone do that? Is it better?

I see three options of implementation at the moment:

1) defining a header with the definitions and implement them in a .cpp
file
2) defining a header with the definitions and the implementations
3) using a cpp file and implement it all in there.

So what are the pro's and contras here? Currently I'm using using
option 1 since I learned it that way in a basic OO-language course.

Also, it is possible to define a range of multiple classes in the same
header file, why would I want that over the 1 header - 1 class
structure that I'm using now(probably a java influence here).

Headers and implementation files are a way to emulate logical separately
compiled modules in a language that has a pre-processor but no direct
support for separately compiled modules.

Separately compiled modules are a way to physically split and package a
large system so as to reduce complexity and build times, and allow
concurrent development of different parts.

Method (1) achieves these goals for pure OO code, but with current
compilers (except Comeau) fails to provide information hiding for
template code, because current compilers don't support "export" so that
the template implementations must be provided in the header file.

Method (2) supports template code, and can avoid some extra work, at the
cost of possibly longer build times and not providing information
hiding. In particular, it does not support the common PIMPL idiom.

Method (3) means essentially that the program is so small that there's
no need for physical packaging.


Cheers, & hth.,

- Alf

 

[michael.goossens]

So what is the best choice for a rendering program? Takes alot of
memmory and computation. Obviously its not method 3. And is there any
gain by putting classes together in a header?

 

[Alf P. Steinbach]

* (e-mail address removed):

So what is the best choice for a rendering program? Takes alot of
memmory and computation. Obviously its not method 3. And is there any
gain by putting classes together in a header?

Rendering program = irrelevant, what's relevant is the size and
complexity of the source code.

Lot of memory and computation = irrelevant, as above.

Gain by putting classes together in one header, yes, e.g. if they're a
set of strongly related classes used for one purpose. Unrelated classes
are generally best distributed in different headers. It also depends on
whether the classes are meant to be reused, where client code programmer
may want to use just one or a few classes without dragging in a lot of
unrelated stuff that may clash with other things, and it depends on what
size and complexity the resulting headers are (judgement call that too).

Possibly you will do as engineers have traditionally done when designing
bridges.

First, make bridge too weak, collapse. Respond by making bridge to
strong, high cost. Make weaker and weaker bridges until new collapse.
Say oops, now make really really strong but costly bridge. So on.


Cheers, & hth.,

- Alf

 

[michael.goossens]

So classes like Vector - Point and Normal, which are heavely used and
strongly related should better be put together and a class like
Texture should be on its own. Should the implementation be in the same
file? My guess would be yes because otherwise the compiler won't know
where the implementation is?

Thanks for answering my questions , will have more in the future.

 

[michael.goossens]

O yeah, I don't think engineers can afford to see their bridge
collapse . Just as I want to make a good program with solid
foundations. Even though the odds are against me, implementing
something difficult in a language I have no expertise of .

 

[Pavel]

So what is the best choice for a rendering program? Takes alot of
memmory and computation. Obviously its not method 3. And is there any
gain by putting classes together in a header?

I would suggest you to keep using method (1). The Alf's reference to the
small program, BTW, referred to the amount of source code, not the
amount memory and computation so if you hoped to fit all your ray tracer
code in less than about 500 lines of code, you (3) would not be
theoretically too bad.

But the main question then is the purpose of your ray tracer. If it is
going to be a library (like a Java jar file with packages to use in
different program), it has to have an interface that the client program
will need to use at compile time.

In C++, the only way to "import" such interface is to textually include
it (into the file, using #include <header> preprocessor directive). So,
if you are building a library the general rules will be:

1. Use method (1).

2. Put only as little as you can code into the header to avoid making
the client code dependent on unnecessary implementation details (which
you might want to change often) and save compilation time.

3. Make sure you break down your API to headers in a way that you won't
forget what's where if you have to leave your code and return to it
after 3 months. Many strategies can work for you in this regard and it
is sometimes a matter of a personal taste and maybe of the size of the
API code (only API is counted here, no implementation so for a basic
raytracer it can be quite compact). For example:

3.1. 1 single header file with API.
3.2. 1 header per publicly exposed class and/or a related group of the
freestanding functions.
3.3. A combination of both: have your library delivered to the clients
with a single header file as per 3.1. (clients will appreciate that,
they will have enough headache with their own multiple header files to
remember about them all) and work with multiple files yourself if you
feel so (which will also spare you some compilation time). A single
header file you deliver to your client then will mostly consist of
#include statements including your smaller header files.

On the other hand, if it is just a test ray tracer utility you are
writing it is sometimes pays off to start with method (3), especially in
the beginning where you do not yet know the final breakdown yourself or
just want to play with some algorithms.

Hope this will help.

-Pavel

 

[michael.goossens]

The goal is a physically based raytracer, global illumination etc.
Should be a pretty huge thing.

 

[michael.goossens]

Can someone explain:

explicit Normal(const Vector &v) : x(v.x), y(v.y), z(v.z) { }

if I implement that in the header it works. If I just define it in the
header and try to implement it in the c++ file I get: illegal storage
class as error notification. Is it that explicit can only be defined
in the class definition itself rather than a Class:: reference thingy?

 

[Pavel]

Can someone explain:

explicit Normal(const Vector &v) : x(v.x), y(v.y), z(v.z) { }

if I implement that in the header it works. If I just define it in the
header and try to implement it in the c++ file I get: illegal storage
class as error notification. Is it that explicit can only be defined
in the class definition itself rather than a Class:: reference thingy?

Yes, `explicit' is a part of the declaration (interface), do not use it
in the constructor *definition* outside of the class:

class C {
explicit C(); // declaration
};

C::C() {} // definition

-Pavel

 

[michael.goossens]

Yes, `explicit' is a part of the declaration (interface), do not use it

in the constructor *definition* outside of the class:

class C {
explicit C(); // declaration

};

C::C() {} // definition

-Pavel

Why can't they just put that information on the pages with tutorials,
api's and such . All those examples are always just implementation
in the c++ file but nothing with header thingies .

But good thing I got you guys

 

[Juha Nieminen]

It seems that a header has the purpose to define classes
and functions.

No. The purpose of a header file is to declare the *public interface*
of a module. In other words, to declare what other modules should see
from this module.