as well as a include "charicter.h", I would also add that to the main.cpp. What do I need to put into the header file itself... and am I going about this the rigth way?

roxtar
—
2005-12-16T14:02:43Z —
#2

Usually you will just declare the class in the header file and specify the implementation of that class in the .cpp file. What I mean by "declaring the class" is that you specify the data members and the interface of the member functions. You shouldn't implement the functions in the header file. For example :

great thanks guys... I was unsure wat to put in the header.. so the entire class "definition" with all the variables and the functions decleratons in the header.. Then the actual functions themselves in the cpp bit...

If you are including any other header files like string.h etc you don't need to do separate #ifndef #defines for them, as it is already done in those header files.

juhnu
—
2005-12-16T15:32:29Z —
#6

For many cases it's not really that useful to split classes for the separate "implementation" and "header" file. I see it quite often that people split all the classes they write without thinking if that's really needed and without knowing what kind of implications it has.

There are reasons and situations when the splitting is a good idea, but there also are situations where it's not...that said I would like to rant about the whole #include system C++ has but would go bit off-topic..

@juhnu - You are right I do not really understand "what kind of implications it has." to split the files up.. I am mainly doing it as a way of understanding how seperate files function as well as making "seperating" all the code up so I can read it easyer.... it seams logical to me to have everything split up where you can as a way to just make the code easyer to read. Mabey a better way to do it would be to group a bunch of classes that relate to a simular "thing-e-ma-bobs" in the program. So you get the code seperate for easy reading latter but minimize the seprate files... as well as keeping related code all in the one place.

monjardin
—
2005-12-16T16:08:12Z —
#8

The way you seperate your code is usually a matter of personal taste and coding standards. There are some exceptions.

Typically, you want to keep the number of dependencies to a minimum. For example, say class A uses class B internally, but class C only uses class A and doesn't care about class B. It that case, it makes sense to hide class A's use of class B from class C. In doing so, making changes to class B's interface does not require a recompile of class C.

Could that have been any more obtuse? :blink:

eddie
—
2005-12-16T16:10:05Z —
#9

I personally always do the .hpp/.cpp split myself. It lowers build times when my implementation changes but my interface does not, which allows me to develop faster.

In cases where inlining is necessary, that's an optimization that can be done later.

eddie
—
2005-12-16T16:10:38Z —
#10

@monjardin: Sounds like you're setting up someone to talk about forward declaring.

monjardin
—
2005-12-16T16:11:46Z —
#11

That's true eddie. You can always mash stuff together after you getting it working and "know" it won't change anymore.

I'm a big believer in Knuth's saying: "Premature optimization is the root of all evil". It applies to everything, from inlining to code layout to actual algorithm design.

Get it working first, be happy with it, and then massage it to the specs you need it to be.

\

In that same line of thought, How do you know what to optimize, if you haven't finished your code and ran a profiler against it? Answer: You don't. So don't bother optimizing until your code works AND it is slow, if it runs as fast as you need it to, don't break it by trying to optimize it.

I personally always do the .hpp/.cpp split myself. It lowers build times when my implementation changes but my interface does not, which allows me to develop faster.

It doesn't necessarily lower the build times. For example if you have lots of small classes, it's better to keep them all in the same compilation unit, especially if your compiler of choice doesn't support precompiled headers.

There are pros and cons for the splitting, but it seems people tend to prefer it in every case. How does it improve readibility to keep declaration of member variables, implementation specific inner classes and method prototypes in one file, while keeping implementations of all the functions in another?

I can understand the idea of separating the public interface of a class and the private implementation, but C++ style of splitting doesn't really do this. If the headers needn't to contain private methods and member variables, it would be ok, but that's not the case.

We are using abstract interfaces paradigm quite often and separating an actual implementation class into two distinct files makes little sense here.

Other situation is when you take advantage of the inner classes. They come in handy sometimes when you need to cross reference between two classes and when the other class is implementation specific to another. Of course you can try to split inner classes as well, but it really makes it hard to read.

Don't get me wrong though. I'm personally using the splitting when it's needed to lower compilation dependencies or for other justificated purpose, but thats probably 20% of the classes or less.

monjardin
—
2005-12-17T15:59:18Z —
#17

You can also use the pimpl (pointer-to-implementation) idiom to avoid the necessity of virtual function calls and inhereitence.

// something.hpp
class SomethingPrivate; // forward declaration
class Something
{
SomethingPrivate *pimpl;
public:
... a bunch of functions that will call the pimpl to do the work
};
// something.cpp
class SomethingPrivate
{
... all of your private member variables
public:
... the real implementation of the Something methods
};
... the implementation of the Something methods that redirect to the pimpl

If you need inner classes, then you can fully define them in the pimpl class in the same file and noone is the wiser.

Reedbeta
—
2005-12-17T19:24:55Z —
#18

Yeah, but the fact that you have to use something like the pImpl idiom is rather annoying. In truth, it's a hack to get around the fact that C++ doesn't allow proper implementation/interface separation.

(In C++'s defense, the reason it needs private variables to be declared in the definition is so it knows how big the class is in case you need to allocate space for an object of it. Otherwise all objects of the class would have to go on the heap, since it wouldn't know their sizes until link time.)

Personally, I use abstract interfaces and factories when I want to hide implementation completely. The abstract stuff goes in the header file and then a concrete class implementation deriving from the interface is hidden in a .cpp file.

It doesn't necessarily lower the build times. For example if you have lots of small classes, it's better to keep them all in the same compilation unit, especially if your compiler of choice doesn't support precompiled headers.

Right. Perhaps I stated it wrong. It often helps reduce rebuild times.

At my last work place, they had one file called 'library.hpp' that included *every* other header in the module. You changed *one* thing, and it would cause everything in your entire tree to rebuild. Tres annoying.

I've known some people to still do the split-your-classes thing, but then have one master .cpp file that #includes everything. I've never done it myself, but I understand it makes compilation ridiculously fast.

You also bring up a good point about hiding the private implementation. I agree that C++ doesn't do it that well, although understandably, since C++ has to guarantee structure layout of it's private members. Still, it would be nice if I could achieve the separation of implementation from definition, without resorting to pimpl. (I've never liked pimpl: granted, I've never really seen it in all it's glory, so it could be a bad prejudice to have).