You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
#defineSUBPROCESS_IMPL#include"subprocess.h"
And somewhere in the C header
#ifdefSUBPROCESS_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.
The text was updated successfully, but these errors were encountered:
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.
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:
And somewhere in the C header
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, againsokol
andminiaudio
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'sPost 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.
The text was updated successfully, but these errors were encountered: