C++ Question Multiple .cpp & .h files : whats the point ?

[N_Molson]

Hello, :hello:

I've seen that many advanced projects, including samples from the Orbiter SDK like Atlantis, use quite a lot of different .cpp and .h files.

When I work on a project, I make only one .h file and one .cpp file. It seems it doesn't cause problems.

So I wonder what are the benefits of multiple files, and what's the general purpose. The obvious one I can guess is organization. With a single file, you quickly have thousands of lines of code, which is not fun to browse, even with bookmarks (hence a loss of time and efficiency). But there is to be something else.

Thanks for sharing your thoughts / experience :tiphat:

 

[jedidia]

So I wonder what are the benefits of multiple files

OVERSIGHT!! (sorry for all caps, but this had to be said loud).

If you have a project with 20 classes and 10'000 lines of code in one header and one cpp file, you're so screwed.

Usually, you make one pair of header/source file per class. An additional plus is that it will be very easy to add this class to any other project it might come in handy for.

 

[MeDiCS]

Mostly organizational. Not only there may be varius header and source files, but they may be distributed throughout various subdirectories.

There are also two other advantages you get when splitting the source: partial recompilation is easier and faster (that is, you simply recompile the files changed since the last build), and conditional compilation may be cleaner.

The first point is specially important in large projects, which may take hours to be fully built. It'd be unproductive to have to wait hours to build and test a single line change.

The second point depends more on the programmer's style and on the program itself. For example, if a specific software has optional support (at compile-time) for, say, a specific file format, then either #ifdef guards are used, or the optional code is segregated to a separate file which will only be built if necessary.

 

[jedidia]

The first point is specially important in large projects, which may take hours to be fully built. It'd be unproductive to have to wait hours to build and test a single line change.

Right, forgott about that...

 

[Moach]

i keep my header count at a must-organize pace...

if i find there's something growing too large to keep in check all in one place, i'll split it up to a separate header....

i often also use more than one .cpp to define a single class... some functions can get loooong... and so i group them by purpose in separate modules when needed :hmm:


i hear the "standard" practice is to have one .h for each class, and a .cpp to implement it... but i find that doesn't really mean the "best" way of doing it for any project whatsoever - there's often a better solution, but each case is different...

so if whatever way you're doing it helps keeping your code organized, well, in my book you're doing it right :thumbup:

 

[N_Molson]

I see. What is still very blurry for me at this point is the class concept. What I can read on Wikipedia doesn't help much, its already too much specialist stuff for me. :hmm:

 

[Enjo]

I'll resort to replying quickly this time:
You need to read a good book on programming, like "Thinking in Java" or "Thinking in C++" or any other. Believe me, reading just one book can change your entire career, because most people never read programming books, so you'll be ahead of them already. Unfortunately some of the ignorant people were programmers working with me :thumbsdown:

 

[N_Molson]

Believe me, reading just one book can change your entire career

But I'm not a programmer, merely an aspiring primary-school teacher with a severe addiction to Orbiter ! :lol: :lol: :lol:

Well if I see "C++ for dummies" in a store, I'll buy it.

 

[Enjo]

Then I find it even a better reason to promote writing state-of-the art code, because kids will be following you.

Well if I see "C++ for dummies" in a store, I'll buy it.

Not for dummies. You need an author that gets the point of object oriented programming. There's no reason to be afraid of it. You learn it only once and can use it in any modern language. You'll start to perceive these languages as just sets of APIs with common general handling (common object oriented programming).

 

[orb]

I'm not sure how is it in other than COFF object formats, but if you create a static link library with many different functions, the best is to put each function in a separate source file, which will make as many small object files put into library as possible, which will be only linked with your project when needed (when a function defined in object file is used), instead of one large, which otherwise will be always linked in any project using just a single function or variable from that object file / library, but it could have changed with other object file formats, so this may be irrelevant there.

 

[jedidia]

What is still very blurry for me at this point is the class concept.

Oh, it's only the basis for pretty much everything...

 

[Artlav]

It's like the difference between this

And this.

On large projects it also allows for faster compile time through partial recompilation.

None less important is modularity - you can add the cpp&h pairs as separate modules to other projects, instead of hunting for code inside one big spaghetti factory.

 

[MeDiCS]

I'm not sure how is it in other than COFF object formats, but if you create a static link library with many different functions, the best is to put each function in a separate source file, which will make as many small object files put into library as possible, which will be only linked with your project when needed (when a function defined in object file is used), instead of one large, which otherwise will be always linked in any project using just a single function or variable from that object file / library, but it could have changed with other object file formats, so this may be irrelevant there.

Static libraries, both in the *nix world (*.a) and on Windows* (*.lib), are simply archives in the ar format. If you do extract a static library, you'd simply end up with a collection of object files (*.o on *nix, *.obj on Windows).


* Although it seems this is not explicitly stated on the official documentation from Microsoft.

 

[orb]

Static libraries, both in the *nix world (*.a) and on Windows* (*.lib), are simply archives in the ar format. If you do extract a static library, you'd simply end up with a collection of object files (*.o on *nix, *.obj on Windows).


* Although it seems this is not explicitly stated on the official documentation from Microsoft.

Not the point. My point was that ELF or other object format taken from static link library may not be required to be linked entirely with the program if only one function among many others present in it is used, but I'd need to read about it more to be sure. COFF for example is linked with program as a whole .obj, not just section of it containing only required function. That's why creating static link libraries is better with many small object files, which are compiled from many small source files, as each source file creates one object file.

 

[MeDiCS]

Not the point. My point was that ELF or other object format taken from static link library may not be required to be linked entirely with the program if only one function among many others present in it is used, but I'd need to read about it more to be sure. COFF for example is linked with program as a whole .obj, not just section of it containing only required function. That's why creating static link libraries is better with many small object files, which are compiled from many small source files, as each source file creates one object file.

Exactly the point. Or rather, the exact reason why splitting code between different sources may be good: a static library consists of object files, and not, for example, a collection of isolated functions.

 

[Enjo]

You guys are right about the technical details, but the most important features of OOP are:
- code reusability
- ease of maintenance

Even if you had to link the entire library into your executable, it would still be profitable to use OOP, where storing each class in a seperate file stresses the fact that you're coding using OOP.

 

[orb]

Exactly the point. Or rather, the exact reason why splitting code between different sources may be good: a static library consists of object files, and not, for example, a collection of isolated functions.

But I can also create a static library containing only one large object file, so that's why it wasn't my point, but whatever.

 

[mjessick]

Another organizational benefit in large projects derives from the actions of Source Code Control systems. These tools keep track of every change. if two or more programmers (starting from the same state of the code) change the same line of code then check the changes back into the system, the system can't choose which line is correct by itself - it needs human intervention to "merge" the changes (choose which lines to keep and which to toss.) This can be time consuming and error prone.

Splitting up the code into many files makes it slightly less likely that any part of it will be part of an overlapping change at any particular time. The project I'm working on now has 75 developers. We are split into sub-groups such that only the few people in one's sub-group normally have reason to be changing any particular file. Certain areas of the code (such as initializations where a lot of churn is expected) we consciously split into more files than we might otherwise, in order to reduce the amount of these overlapping changes.

Our kind of code tends to be used for 20 years or more after it is first made operational. We are basically writing the code for someone to be reading a decade later, hoping to be able to maintain it efficiently. The organization of the thousands of source files is a very important part of making that job as easy as possible.

 

[Hlynkacg]

Ok you've convinced me to split my code up.

How do i do it?

Cutting functions into seperate cpp files sounds great and all but the moment I try to include my .h the compiler craps itself. If I don't include the .h all i've got is a crap-ton of undefined variables and no class definition.

 

[Enjo]

It's not about splitting functions but classes - thematically organized and isolated data and functions which operate on the data.