Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > confused about .h and .cpp definition vs implementation

Reply
Thread Tools

confused about .h and .cpp definition vs implementation

 
 
michael.goossens@gmail.com
Guest
Posts: n/a
 
      01-26-2008
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).
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      01-26-2008
* http://www.velocityreviews.com/forums/(E-Mail 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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
 
 
 
michael.goossens@gmail.com
Guest
Posts: n/a
 
      01-26-2008
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?

 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      01-26-2008
* (E-Mail 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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
michael.goossens@gmail.com
Guest
Posts: n/a
 
      01-26-2008
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.
 
Reply With Quote
 
michael.goossens@gmail.com
Guest
Posts: n/a
 
      01-26-2008
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 .

 
Reply With Quote
 
Pavel
Guest
Posts: n/a
 
      01-26-2008
(E-Mail Removed) wrote:
> 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
 
Reply With Quote
 
michael.goossens@gmail.com
Guest
Posts: n/a
 
      01-26-2008
The goal is a physically based raytracer, global illumination etc.
Should be a pretty huge thing.
 
Reply With Quote
 
michael.goossens@gmail.com
Guest
Posts: n/a
 
      01-26-2008
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?
 
Reply With Quote
 
Pavel
Guest
Posts: n/a
 
      01-26-2008
(E-Mail Removed) wrote:
> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
confused between declaration & definition arnuld C++ 3 11-08-2006 01:40 PM
Automagic determination of definition based on definition location. Jon Slaughter C++ 4 10-26-2005 05:00 PM
can a class definition inside another class's definition Jianli Shen C++ 1 03-13-2005 06:02 PM
help?: incomplete definition with complete definition in scope Ark C Programming 1 08-07-2004 04:21 PM
Confused over definition of "root" of site Larry Woods ASP General 2 01-13-2004 01:48 PM



Advertisments