4 ms·

It is form over function. This works for simpler libraries and templates, obviously, but once the function becomes less trivial, it should really be going into

It is form over function. This works for simpler libraries and templates, obviously, but once the function becomes less trivial, it should really be going into a separate source file. Readability and manageability aspects aside, keeping implementation in a header causes all dependencies of that implementation to be pulled into your code as well. Including the heavy platform-specific stuff. If I need to do some string conversion, I really don't care for the implementation sneaking in <windows.h> into my sources just so that it can call WideCharToMultiByte.

rogual 6y ago
Sometimes it's not quite so bad, because the single file will contain both implementation and header, with an #ifdef to switch between them, so you're supposed to make your own source file which uses a #define to include just the implementation part.
jb1991 6y ago
Yet there are very many substantial libraries that go well beyond small tasks that are implemented this way, some of them very popular.
flohofwoe 6y ago
Single-file-libs done right have the implementation in a separate #ifdef/#endif block. They don't pollute your code any differently than a regular .h/.c setup would (at least outside that one source file which includes the implementation).
- huhtenberg 6y ago
  > They don't pollute your code any differently than a regular .h/.c setup would. For that to happen you'd need to have a separate .c to include just that .h with IMPLEMENTATION defined. So in the end there's still an .h and a .c, except the .c is now completely superficial.
  - flohofwoe 6y ago
    Yeah I just added that while you wrote your comment, sorry. You can still put multiple implementations into the same source file and compile that into a library, for example: https://github.com/floooh/sokol-samples/blob/master/libs/sokol/sokol.c https://github.com/floooh/sokol-samples/blob/master/libs/sok... That's what I usually do for projects that don't just consist of a single source file (e.g. simple command line tools). An actual advantage of this approach is that you can add any configuration defines in that same source file, instead of passing them in from the build system via compiler command line args. Also for bigger projects you can have dozens or hundreds of header files but only a small number of source files (e.g. one source file per "system" or split by change frequency, or by any other criteria (like whether the implementations include Windows.h or other system headers). A small number of compilation units means fast compile times (since it's essentially a unity build), but at the same time you have enough control over the project's file structure to balance compile times vs "namespace pollution" vs what changes trigger a rebuild.
  - hburd 6y ago
    You can avoid the .c file by building the .h and passing the compiler a -DIMPLEMENTATION option.
thisiswas 6y ago
stb actually went to extreme lengths on his SDL/GLFW-like library where he didn't even depend on windows.h, i.e he put just the structs and function(pointers) he needed into the header (under stbxxx_ prefixes), hardcoded magic numbers instead of windows.h's #defines, bootstrapped with __declspec(dllimport) GetProcAddress (and even that symbol can be omitted with some trickery, there is a way to get to kernel32.dll functions from any .exe)

rogual 6y ago

Sometimes it's not quite so bad, because the single file will contain both implementation and header, with an #ifdef to switch between them, so you're supposed to make your own source file which uses a #define to include just the implementation part.

jb1991 6y ago

Yet there are very many substantial libraries that go well beyond small tasks that are implemented this way, some of them very popular.

flohofwoe 6y ago

Single-file-libs done right have the implementation in a separate #ifdef/#endif block. They don't pollute your code any differently than a regular .h/.c setup would (at least outside that one source file which includes the implementation).

huhtenberg 6y ago
> They don't pollute your code any differently than a regular .h/.c setup would. For that to happen you'd need to have a separate .c to include just that .h with IMPLEMENTATION defined. So in the end there's still an .h and a .c, except the .c is now completely superficial.
- flohofwoe 6y ago
  Yeah I just added that while you wrote your comment, sorry. You can still put multiple implementations into the same source file and compile that into a library, for example: https://github.com/floooh/sokol-samples/blob/master/libs/sokol/sokol.c https://github.com/floooh/sokol-samples/blob/master/libs/sok... That's what I usually do for projects that don't just consist of a single source file (e.g. simple command line tools). An actual advantage of this approach is that you can add any configuration defines in that same source file, instead of passing them in from the build system via compiler command line args. Also for bigger projects you can have dozens or hundreds of header files but only a small number of source files (e.g. one source file per "system" or split by change frequency, or by any other criteria (like whether the implementations include Windows.h or other system headers). A small number of compilation units means fast compile times (since it's essentially a unity build), but at the same time you have enough control over the project's file structure to balance compile times vs "namespace pollution" vs what changes trigger a rebuild.
- hburd 6y ago
  You can avoid the .c file by building the .h and passing the compiler a -DIMPLEMENTATION option.

thisiswas 6y ago

stb actually went to extreme lengths on his SDL/GLFW-like library where he didn't even depend on windows.h, i.e he put just the structs and function(pointers) he needed into the header (under stbxxx_ prefixes), hardcoded magic numbers instead of windows.h's #defines, bootstrapped with __declspec(dllimport) GetProcAddress (and even that symbol can be omitted with some trickery, there is a way to get to kernel32.dll functions from any .exe)