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?
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.