I don't really understand what your criticisms are. There is literally no functional code difference between a single header library and a two file library. Your aversion is as arbitrary as saying you don't consider libraries if the API uses camel case.

Other than not being able to use pseudo-modules in C, using a gigantic header file instead.

Can you compile a header to an object file so that its definitions don't have to be recompiled every time the including file is recompiled?

Eh... Yes?

GCC [0], Clang [1] and others [2] have supported for compiled headers. Cmake also has support for precompiled headers [3].

I would say both the tool and architecture to do that is well supported.

[0] https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

[1] https://clang.llvm.org/docs/PCHInternals.html

[2] https://www.qnx.com/developers/docs/6.3.2/neutrino/utilities... (-pch flag)

[3] https://cmake.org/cmake/help/latest/command/target_precompil...

I can sort-of understand (and still disagree) for header-only template libraries. But in general yes I agree, "header-only" is an anti-pattern for high quality C and C++ projects.

> "Header only" libraries are an anti-pattern in C

says who? care to elaborate?

Separating the interface from the implementation details? Isolating the server code from the module that uses it? Because the implementation is in the header, including it defines a bunch of macros that could easily collide with macros in the larger project.

Not knocking the overall effort here, but yes, "header only" libs are definitely an anti-pattern in real world C. I assume the author considers it a curiosity, a novelty, or something that would only be used in very limited circumstances that make such a design an advantage.

Only one inclusion expands to produce the implementation.

Still suffers from the isolation problem. For example, if you happen to define HTTP_BODY in your own code, it segfaults.

This can be avoided by being careful to only define HTTP_BODY after including httpserver.h, but avoiding this type of thing to worry about is the entire point of interface/implementation separation.

This only causes a problem if you define HTTP_BODY in the same file that you define HTTPSERVER_IMPL when including httpserver.h

Well yes, it's a small isolation failure, but a failure nonetheless. It may seem like a contrived example, but "HTTP_BODY" would be a perfectly reasonable choice of variable or macro name for someone building a tiny embedded web server, and then you have a user (the user in this case being a developer using your library) having to debug your code because its internal assumptions collide with the outside world in a way that's completely avoidable if you just put it in a separate compilation unit.

How is that different.from anything else in C or C++? What does that have to do with single header libraries? Preprocessor isolation is just now possible with C++ modules.

It's different because normally your header files don't contain internal implementation details like this that spill out all over everyone who #includes them.

This only includes the implementation if a certain IMPL symbol is defined, so it doesn't 'spill' the implementation every time it is included. That wouldn't work anyway because you would get multiple definitions. Single header files like this and the commonly used stb libraries include the implementation so that there is a single file to keep track of, but the implementations are still explicitly included in only a single complication unit.

What you are talking about is not an issue in practice.

It's pretty simple: Is HTTP_BODY part of the interface of the module? No. Is the consumer of this library secretly prevented from using HTTP_BODY itself in the module that includes it? Yes. Is this a big deal? For a toy module, no. Would this pass design review in any company I've ever worked in? No. The feedback would look like this:

  // httpserverlib.c
  #define HTTPSERVER_IMPL
  #include "httpserver.h"
  // TODO: look up definition of "compilation unit"

That's just part of C and C++. When people do 'unity builds' to make larger compilation units the same rule applies. I think it is much more about avoiding the preprocessor as much as possible than some sort of fatal flaw with single header libraries. The advantages far outweigh the downsides since minimal dependencies means that you have real modularity. Pragmatically there is much more reuse with single header libraries like this. Search github for how many things depend on stb libraries and would not be possible without them or would end up with spidering dependencies and build systems.

Even windows.h redefines min and max - blaming single file libraries is ridiculous.

Using a single .c file that includes the file and defines the IMPL symbol would negate what you are saying anyway and in fact is a common way to use them.

> Using a single .c file that includes the file and defines the IMPL symbol would negate what you are saying anyway and in fact is a common way to use them.

Ok, well we're obviously arguing semantics at this point, then, because in my opinion, moving the IMPL definition into a single .c file doesn't negate the complaint about single-header libraries, it makes it no longer a single-header library. :D

100% agree with you. I really think adding a source file to your build tool of choice (Make, CMake, Visual Studio project) is a basic fundamental skill that a C or C++ developer should know.

C is already an anti pattern for a library.

It is soon 2020, there is no reasons to use C in new code. Because of security and also convenience.

Maybe it is a nice mental exercise (also try brainfuck and malbolge), but not something for production.