Why are Graphics coded in Header-File?

Getting Started
1

I am just starting out with the JUCE Framework but have done some C/C++ Projects for University.
We got taught that Headerfiles should only be used for decleration of functions and defining Macros.
But all of the Graphic paint functions etc. are modified in the Header-files.
So I was wondering why this seems to be the best practice instead of modifing graphics in let’s say a MainComponent.cpp file

2

Separating the declaration in headers and the implementation is mostly a style choice, that I support strongly. Once you get to the point you can treat some classes as black box, it is great to get an overview of the functionality, without browsing all the implementation details (granted, there is also doxygen for that purpose).

For code to be optimised, it makes sense to have it in the header implemented, because that way the compiler can inline it. Otherwise this could only be done at the linker stage, which is not how the majority of compilers/optimisers work (take it with a pinch of salt, I am not a compiler expert).

My personal rule of thumb about methods, that are called in DSP or fast graphics (especially methods that are called per sample):

  • never call virtual methods
  • implement in header
    (inline has different meanings, I think you can add forcedinline instead, but the optimiser will take care of that anyway)
  • make it noexcept
    (will never throw an exception, but then you must code that it really can’t fail)

I think clever people here can add to that list…

1 Like
3

also not an expert here, but I usually I put simple implementations, like simple set and get methods, in the header while putting the more complicated stuff in the cpp.
I prefer my code more readable instead of over optimizing everything. later on, if you run into performance issues, you can still put certain functions in the header.

1 Like
4

AFAIK C++ was the last language to use this header/cpp pattern. It comes from C, and wasn’t designed because it’s a great way to work - it’s just a side-effect of a preprocessor being created in the early 1970s for systems without enough memory to run more complex parsers.

Really the only practical reasons for choosing header/cpp style in modern C++ is to help with compilation speed problems, or if you’re working with static libraries. Some people prefer it aesthetically, but it’s hard to argue that it’s the way we should teach beginners to do things.

Personally in new codebases these days I go header-only by default. Then when some classes get too big, or the build gets bogged-down, I go back and refactor/modularise as appropriate. And by leaving this until later means you’re refactoring with an understanding of the structure of the code which you didn’t have at the start of the project.

Just like the best practice in optimisation is to never do it prematurely, I’d say the same applies here. It makes little sense to always type everything twice, make your code bigger and harder to refactor and browse. The right time is only when it provides a net benefit to what you’re making.

11 Likes
5

Thank you for the insights, apparently our lecturer fibed a bit so we stick to his coding standards :smiley:
But if it truly just is for aesthetically reasons I can live with coding in the header. Thanks again :slight_smile: