.h and .cpp

[razzle]

putting code in .h files:

Sure, it wouldn't be a good idea to start replacing .cpp files with .h files in an old rusty legacy project. In fact you should touch it as little as possible. Not only because even minor changes often result in huge recompilations but because they also very often result in unexpected bugs.

So firstly, even though the .h/.cpp separation may shield you from recompilation it doesn't improve your code. It's just a physical separation of code with no design benefits.

Secondly, good design and today's tools will shield you almost as much from recompilations as .h/.cpp splitting. And not only that, good design will truely benefit your program.

Finally thirdly, how bad is a recompilation really for small to medium sized projects?

I'm not saying you shouldn't have any .cpp files at all but why routinely make the .h/.cpp split when it's seldom necessary and doesn't have any real benefits? And why must every newbie be taught .h/.cpp splitting like it was the most important feature of C++ programming?

[razzle]

Have you ever dealt with C code written in early 90'th or earlier?

I understand that .h/.cpp splitting has a long history and that probably explains why it's so deeply rooted today. But maybe the time has come to reconsider this practice?

I started putting more and more code into .h files holding my breath. But nothing bad happened. Compilation didn't take longer and executables didn't grow. I even think my programs have become a little faster and if that's true it's because the compiler has been given more leeway to organise the code.

Maybe it has something to do with my programming style. The application-wide dependencies mostly consist of pure abstract base classes and different kinds of supporting library utilities, own and C++ standard. Both these categories seldom change. The implementation code on .h files are often derived classes and these get changed a lot but the dependecies are limited mostly to imported base classes and utility classes. This structure makes a .h only program almost as resilient to recompilation as .h/.cpp splitting would.

Well, for the time being I consider the .h/.cpp split an optimization I don't want to do prematurely.

[Arjay]

I understand that .h/.cpp splitting has a long history and that probably explains why it's so deeply rooted today. But maybe the time has come to reconsider this practice?

This is the 'looking weird' issue that I mentioned earlier. To me, it is always a great idea to revisit coding, styling and approach from time to time to make sure the code you write evolves and matures. I've done this several times in my career and am happy to report that the code I write today looks way cleaner than it was in the 1990's.

It's still as buggy, but hey, you can't have everything.

[OReubens]

PS. Why Java(Script) and C# programmers do not complain about not having include files?

C# doesn't need them, or rather, "the compiler makes them for you" (sort of).

If everything is within the project, it doesn't matter a lot.
if you make references to other projects, you're really making a reference to the interfaces only, and not tto the actual source files. During compilation the C# compiler builds this "interface definition file" from the class/code in the .cs files.

I'm oversimplifying here ofc, but that's the essense of it at least.



Javascript doesn't need it, because it's a dynamic scripting language, not a compiled language, and it's typically all included into a single chunk of script. so for all intents and purposes, you typically have the equivalent of a single large .js file.

[Arjay]

if you make references to other projects, you're really making a reference to the interfaces only, and not tto the actual source files. During compilation the C# compiler builds this "interface definition file" from the class/code in the .cs files.

In C# projects, it is perfectly valid to make a link to an external .cs file (or other type of file). A .cs file linked to a project gets compiled as if it were a .cs file included directly into the project.

[OReubens]

In C# projects, it is perfectly valid to make a link to an external .cs file (or other type of file). A .cs file linked to a project gets compiled as if it were a .cs file included directly into the project.

yes,
and you can do the same in C++. Though it may not Always work as you planned because of how the compiler searches for includes.

[ovidiucucu]

...and further we can see a lot of C++ code monkeys swearing whatever tools instead of shooting the architect which just has borrowed some cool practices from other programming languages.

[razzle]

To me, it is always a great idea to revisit coding, styling and approach from time to time to make sure the code you write evolves and matures. I've done this several times in my career and am happy to report that the code I write today looks way cleaner than it was in the 1990's.

Coming from Java I've always found this obsession with .h/.cpp kind of weird. It has no design benefits and regardless of how you split a program the tool chain responsible for producing an executable does pretty much what it likes anyway. The C++ standard is very clear about it,

"Source files, translation units and translated translation units need not necessarily be stored as files, nor need there be any one-to-one correspondence between these entities and any external representation. The description is conceptual only, and does not specify any particular implementation."

I've finally realized that .h/.cpp splitting is just ancient voodoo with no real effect (unless you are a zombie programmer of course ).

[ovidiucucu]

Coming from Java I've always found...

That explains everything.
No offense...

[Arjay]

That explains everything.
No offense...

The idea has merit, but as I mentioned the biggest obstacle is overcoming the weird feeling.

Actually, it's healthy to have other perspectives from other languages and environments (i.e. IDEs). If you only code in the one language, you might never find out what you are missing.

[ovidiucucu]

Arjay, I began coding long time ago with FORTRAN and COBOL-74.
But I never said (e.g. in a Java forum) something like
"Coming from C++ I've always found this obsession of using garbage collector kind of weird."
C++ is C++, Java is Java. Although they are somehow related, they are different programming languages with a pretty different philosophy behind.

[razzle]

But I never said (e.g. in a Java forum) something like
"Coming from C++ I've always found this obsession of using garbage collector kind of weird."

Well, before you do that I advice you to first improve your argumentation skills considerably.

No offence but there's a difference. I've argued my case whereas the only thing you've come up with so far is a meek ad hominem attack.

So what's the "philosophy" of .h/.cpp splitting and how is it essential to C++ today you think?

[superbonzo]

Actually, it's healthy to have other perspectives from other languages and environments (i.e. IDEs). If you only code in the one language, you might never find out what you are missing.

one thing is to be open-minded, another is hijacking the ( very flexible ) c++ compilation model.

yes, cpp files are neither part nor intrinsic to the c++ language, but translation units are. And it’s a basic fact about c++ programs that 1) they are made of one or more translation units and 2) certain entities need to satisfy the one definition rule across all translation units; these two facts imply that everything that is supposed to be liberally #included must not contain ODR entities in them; otherwise, placing everything inside an h file essentially limits ALL users of that file to a single TU ( per ODR entity ), is this acceptable ? I think not, at least not as a general guideline, not to speak of something a newbie should follow.

[Arjay]

one thing is to be open-minded, another is hijacking the ( very flexible ) c++ compilation model.

yes, cpp files are neither part nor intrinsic to the c++ language, but translation units are. And it’s a basic fact about c++ programs that 1) they are made of one or more translation units and 2) certain entities need to satisfy the one definition rule across all translation units; these two facts imply that everything that is supposed to be liberally #included must not contain ODR entities in them; otherwise, placing everything inside an h file essentially limits ALL users of that file to a single TU ( per ODR entity ), is this acceptable ? I think not, at least not as a general guideline, not to speak of something a newbie should follow.

Doesn't the STL do this?

[superbonzo]

Doesn't the STL do this?

no, the stl does not contain ODR entities in its headers ( just to be clear, by ODR entity I essentially mean anything that would give a linker error if compiled in multiple TUs ). As you know, inlines and templates are simply required to give the same definitions across TUs ( at the cost of UB otherwise, no diagnostic required ).

My point is that if we accept that is in the very nature of c++ having possibly more than one TU, then we must accept that any header containing ( non inlined, non templated) implementation goes against the nature of c++ ( or, just to be less pompous most c++ programmers will be very annoyed/surprised by realizing the limitations that such a choice brings in ).