Question

One of my “non-programmer” friends recently decided to make a C++ program to solve a complicated mechanical problem.

He wrote each function in a separate .cpp file, then included them all in the main source file, something like this:

main.cpp:

#include "function1.cpp"
#include "function2.cpp"
...
int main() 
{
...

}

He then compiled the code, with a single gcc line:

g++ main.cpp    // took about 2 seconds 

Now, I know that this should work, but I’m not sure whether including .cpp files directly into the main program is a good idea. I have seen the following scheme several times, where all the function prototypes go into a header file with the extern keyword, like this:

funcs.h:

extern void function1(..);
extern void function2(..);
...

main.cpp:

...
#include "funcs.h"
...

& compiling with:

g++ -c function1.cpp
g++ -c function2.cpp
...
g++ -c main.cpp
g++ -o final main.o function1.o function2.o ...

I think that this scheme is better (with a makefile, ofcourse). What reasons can I give my friend to convince him so?

Answer 1

The main reason people compile object by object is to save time. High-level localised code changes often only require compilation of one object and a relink, which can be faster. (Compiling too many objects that draw in heaps of headers, or redundantly instantiate the same templates, may actually be slower when a change in common code triggers a fuller recompilation).

If the project is so small that it can be compiled in 2 seconds, then there’s not much actual benefit to the traditional approach, though doing what’s expected can save developer time – like yours and ours on here :-). Balancing that, maintaining a makefile takes time too, though you may well end up doing that anyway in order to conveniently capture include directories, libraries, compiler switches etc.

Actual implications to written/generated code:

• cpp files normally first include their own headers, which provides a sanity check that the header content can be used independently by other client code: put everything together and the namespace is already “contaminated” with includes from earlier headers/implementation files
• the compiler may optimise better when everything is in one translation unit (+1 for leppie’s comment, do do the same…)
• static non-member variables and anonymous namespaces are private to the translation unit, so including multiple cpps means sharing these around, for better or worse (+1 for Alexander :-))
• say a cpp files defines a function or variable which is not mentioned in its header and might even be in an anonymous namespace or static: code later in the translation unit could call it freely without needing to hack up their own forward declaration (this is bad – if the function was intended to be called outside its own cpp then it should have been in the header and an externally exposed symbol in its translation unit’s object)

BTW – in C++ your headers can declare functions without explicitly using the extern keyword, and it’s normal to do so.