search

sheredom / subprocess.h

🐜 single header process launching solution for C and C++
The Unlicense
1.1k stars 97 forks source link

Separate implementation from declaration #47

Closed edubart closed 3 years ago

edubart commented 3 years ago

It's a common practice to make single header C libraries with implementation guards, this allow isolating the implementation details code from the main program, thus avoiding variable name conflicts, speeding up compile time if the user include from multiple C files, and also making the library more friendly to generate libraries for other programming languages (that's my intent).

See other awesome single header C libraries such as sokol_gfx.h, miniaudio.h, as examples.

Example of possible change

The user would use like this:

#define SUBPROCESS_IMPL
#include "subprocess.h"

And somewhere in the C header

#ifdef SUBPROCESS_IMPL
/* all function implementations */
#include "subprocess.h"

Although this would break user code when he updates the library, you could negate the ifdef like STB libraries do in some headers, with a define like SUBPROCESS_ONLY_IMPL.

API declaration qualifier

It's also a good practice to allow the user to change the library API declaration qualifier, for example I would like to add static all the library functions, again sokol and miniaudio are good examples on that. Usually the compiler inline static functions.

Discussion

Separating implementation from the declaration at first looks that this would make harder for the C compiler to inline the code, but the compiler can usually inline functions by itself when the static qualifier is used. Also not everybody want to all their functions to be inlined as may increase binary size, also build times, so it's

Post Notes

I was about to ask the same for your JSON library. Although the implementation is inlined to be fast, would still be good to separate the implementation code, and this can be done without much penalties.

sheredom commented 3 years ago

Hey there! Thanks for your comments - I already know well how other libraries choose to tackle this problem and evaluated the model.

I just fundamentally dislike the approach though in all honesty on a personal level. You can mimic the model by only including my header in a single file and then expose your own APIs that use it, but I'm not in favour of this approach for my libraries.

Thanks for the very detailed description though!

edubart commented 3 years ago

Ok, thanks for clarifying and for the awesome library!