C++: Drawbacks to writing whole classes in Header

Question

Just a style question...

I'm a lowly indie game dev working by myself, and I developed what I have been told is a 'bad' habit of writing whole classes in my headers. Some of the benefits I know .h/.cpp file combos have are they allow code to be split into compilation chunks that won't need recompiled so long as they remain unchanged. And allows for splitting interface from implementation.

However, neither of those things are of any benefit to me, since I tend to favour having my implementation in a spot where I can easily improve it, change it, read it. And my compile times are nigh instantaneous (2-4 seconds, 15 if I updated SFML or Box2D to their latest versions and they need recompiled too)

Coding like this has been saving me a very noticeable amount of time I think, and since there are less files, my code feels less 'overwhelming' to me.

But in light of that, and in general, is there any compelling reason to follow the "file.cpp" for every "file.h" setup for a small project where compile time and interface/implementation separation are not priorities?

Answer 1

I think both compile time and interface/implementation separation are good reasons. Even if the former is not a problem right now, in most decent-sized projects, it does become a problem.

But, since you asked for other reasons, I think a big one is that it reduces dependencies. The implementation of your class probably requires more #includes than the interface. But if you put the implementation in the header file, you drag along those dependencies with the header. Then every other file that includes that also has those dependencies.

There is no one-size-fits-all rule, though. And some classes (especially "small" ones) are probably best placed entirely in a header.

Answer 2

What you're doing sounds sensible for your situation. Two other potential issues:

• one definition rule
• testing

If you've got just one cpp file and a couple dozen headers, then you can afford to be careless about the one definition rule (assuming you have include guards). This could bite you if you one day find a need to move to compiling/linking the project as a number of translation units. That might happen in not-so-obvious ways, such as wanting to let other people supply a library that they're to build using a couple of your headers. implicitly (defined inside the class) or explicitly (using the keyword) inline functions will be ok, but beware others. Usual rules for variables etc..

For testing: sometimes it helps to have at least a token .cpp file that includes the .h and gets compiles, just so you get some early warning if the contents of one header can't "stand alone", probably due to a forgetten #include. If you have per-header test .cpp files then that kills two birds etc.. If you don't want testing at that level and are happy to clean up any minor dependency bugs reactively then might as well forget it.

Answer 3

is there any compelling reason to follow the "file.cpp" for every "file.h" setup for a small project where compile time and interface/implementation separation are not priorities?

Nope; there's nothing wrong with defining classes and functions in header files, especially not in small projects where compile times aren't a concern.

For what it's worth, my current, in-progress hobby project has 33 header files and a single .cpp file (not including unit tests). That is largely due to just about everything being a template, though.

If you have a huge software project or if you need to encapsulate your code into a library and actually need the modularity, then it might make sense to split code out of a header file. If you want to hide some implementation detail (e.g., if you have some ugly header that you don't want to include elsewhere in your project--WinAPI headers, for example), then it makes sense to split code into a separate source file to hide those details. Otherwise, it may just be a lot of work for not a lot of gain.