9 minutes ago, a light breeze said:
I would actually recommend going the other direction and making just a single .cpp files and putting everything else in headers.
This is how unity builds work, and they are awesome (in fact you can have lots of .cpp files, you just include them all from one (or a few) .cpp file which is passed to the compiler, the effect is the same). It can still be a good idea to use a few different modules with unity builds though, so you get most of the benefits from both approaches.
Even with unity builds, even though the headers may only be included once, they can still take a while, if you are impatient like myself, so having wrappers can still be a good thing for thirdparty stuff.
As a project gets bigger, the link time can get more of an issue, my current preference is to have a bunch of modules and dynamically link them for fast iteration, and statically link for final release. That way if you touch a file in 1 module out of 10, it only needs to link 1/10 of the codebase. I suspect it may be even less than that in terms of linking time (link time might not scale linearly with size of project).
As an example I recently experimented making unity builds of Godot, which decreases the full build time:
https://github.com/lawnjelly/godot_SCU
Unfortunately for everyday developer iteration the link time is more of a rate limiting step because it is all built as one executable. i.e. you touch a file, and it can compile super fast, but still takes 30 seconds linking. With dynamic linking this could be reduced to e.g. a couple of seconds.
Quote
Why would you parameterize that with a macro, when you can just isolate that implementation detail into its own .CPP?
Your implementation looks quite nice, although really all I was trying to show was an example of wrapping an external library, rather than selection between libraries, perhaps I shouldn't have used windows.h as an example(!).
Having the macro in the header file is to ensure that calling the third party library is in the same translation unit. Compilers used to be rubbish at inlining anything that wasn't in a header files, but with link time optimization that is less of an issue now. I still prefer it out of habit (plus link time optimization is SLOOWWW
).