合并头文件和cpp文件

Question

I'm working on a C++ project where I've implemented every class as a separate .h file and .cpp file. I'm finding out this wasn't worth the hassle. - I'm editing back and forth between two files - It caused me a lot of unsuspected headaches (having to add predeclaration, explicitly export templated classes) - I don't see a direct benefit, my code base is bound to stay relatively small (say < 10,000 lines of code) and compilation time isn't substantial.

My question is two fold

a) Is there a benefit I might have missed in keeping implementation and prototype separated?

b) If not, is there any free tool or ide that has the capability of merging a cpp file back into the header file?

Answer 1

Don't do this. For most simple classes, where you want to expose the class for use somewhere else, you should always* have the declaration of the class in a .h header file, and the definition (code) in a .cpp file.

You then include the .h file wherever you want to use the class (ie. instantiate it). However, the linker is responsible for "linking" the code up after each .cpp is compiled separately.

My question for you would be, "how else would you do it?" One mistake I see many n00bs make is to #include "foo.c . Then what happens is, not only do you lose the independent compilation, you run into problems at link-time because there are multiple definitions of the same class . Remember, when you #include a file, it literally plops in the body of that file where you say.

[*] There are of course exceptions to this rule:

One exception to this is for template classes . These have to be in a header file in their entirety. The reason is because the actual code is not generated until the class is instantiated with a type parameter. Then, the compiler essentially "fills-in" the body of the class with the specified type where required. Since the type is not known until then, it cannot be compiled independently and linked-up later.