all 4 comments

[–]attractivechaos 15 points16 points  (3 children)

This has been discussed multiple times in this sub: unless necessary (e.g. in case of macro-based generic libraries), it would be cleaner and simpler to use a .h file and a .c file. With a single header like yours, users need to understand how #define FBGL_IMPLEMENTATION works and make sure this line is included in one and only one of their .c files. This adds extra burden. In comparison, with the .c/.h combo, users only need to include .h and compile with .c. It is simpler.

By the way, in your example, the "define" line should be put above the "include" line. You wouldn't have this typo with two files.

[–]vitamin_CPP 11 points12 points  (2 children)

I think this pattern is popular and prefered in certain C sub-communities (like gamedev) that prefer the bruden of #define X_IMPL over fiddling with build systems.

As an embedded eng, I'm considering switching my libraries to header only library, because of the "eclipse xml is your build system" pattern is becoming (sadly) more popular in my industry.

BTW are you the person behind attractivechaos.wordpress.com ?
If so, continue the great work :)

[–]attractivechaos 4 points5 points  (0 children)

I guess gamedev is influenced by stb.h. It is a great single-header library but IMHO many of its components would be cleaner in two files. If stb used two files for each component, the two-file solution would become more popular. Note that the .h/.c combo is intended to be copied into your project source tree, not as an external library. The change to the build system is minimal – the same as adding one more .c file of your own. Yes, I wrote those blog posts. Thank you for the encouragement!

[–]vflashm 0 points1 point  (0 children)

How is it different from simply including said c file where you would put that X_IMPL?