5 ms·

> "Header only" libraries are an anti-pattern in C says who? care to elaborate?

hamburglar 7y ago
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.
- tom_ 7y ago
  Only one inclusion expands to produce the implementation.
  - hamburglar 7y ago
    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.
    - jeremycw 7y ago
      This only causes a problem if you define HTTP_BODY in the same file that you define HTTPSERVER_IMPL when including httpserver.h
      - hamburglar 7y ago
        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.
    - BubRoss 7y ago
      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.
      - hamburglar 7y ago
        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.
        BubRoss 7y ago
        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.
        heleninboodler 7y 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"
        BubRoss 7y 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.

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.

tom_ 7y ago
Only one inclusion expands to produce the implementation.
- hamburglar 7y ago
  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.
  - jeremycw 7y ago
    This only causes a problem if you define HTTP_BODY in the same file that you define HTTPSERVER_IMPL when including httpserver.h
    - hamburglar 7y ago
      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.
  - BubRoss 7y ago
    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.
    - hamburglar 7y ago
      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.
      - BubRoss 7y ago
        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.
        heleninboodler 7y 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"
        BubRoss 7y 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.