Hacker News new | ask | show | jobs
by heleninboodler 2376 days ago
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"
1 comments
BubRoss 2376 days ago
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.

link
heleninboodler 2372 days ago
> 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

link