[krychu]

That work will be done by the preprocessor and should be fairly quick given it doesn't compile the duplicated code and only removes it.

[titzer]

It may still generate code for function definitions, which are deduped by the linker, so a lot of the code can still go through the whole compiler.

[flohofwoe]

An STB-style header with the implementation disabled (which is the default) looks exactly the same to the compiler as a regular C header which only contains public API declarations (e.g. just struct declarations and function prototypes, and most importantly, no inline code).

All code that would otherwise live in .c files is between an #ifdef/#endif block which is only activated in a single compilation unit in the whole project.

Not sure how this approach would lead to redundant "function definitions" which would need to be deduped by the linker. The only overhead is in the preprocessor for skipping the implementation block, but that happens pretty much at IO speed - it's not comparable with the parsing overhead in typical C++ headers with template and inline code.

[titzer]

Sure, after brushing up on this "stb style", then I see what you mean.

Still, it seems like an ugly kludge to cope with a breathtakingly antiquated way of doing things.

[flohofwoe]

> with a breathtakingly antiquated way of doing things.

I think it's mainly a fix/workaround for the breathtakingly antiquated build systems in the C/C++ world ;)

In the end, STB-style single-header vs. a single .h/.c pair is not all that different, both are equally straightforward to integrate into a project.

The actual problem are libraries made of dozens/hundreds/thousands of header and source files and coming with their own complex build system setup.

[sledgehammers]

Why should it be any more complicated than that?

What ever happened to keeping it simple?

[titzer]

Things can be locally simple but have complex and chaotic implications. E.g. just by pushing the complexity up a level and dumping it on literally everyone else. I've learned over the years that complexity sometimes has a right place and a wrong place. (Most times complexity ends up everywhere, TBH.) I think resolving references between different parts of code in different compilation units is definitely within the purview of a compiler/build system, and should not be up to every programmer to flail at poorly with #ifdefs.