5 ms·

You're right. "Header only" libraries are an anti-pattern in C and the fastest way for me to close the tab when considering a new library. Just put it in two fi

You're right. "Header only" libraries are an anti-pattern in C and the fastest way for me to close the tab when considering a new library. Just put it in two files and it's still dead easy to incorporate into a project.

blondin 7y ago
> "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.
aninteger 7y ago
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.
deleted 7y ago
[deleted]
jeremycw 7y ago
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.
- Athas 7y ago
  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?
  - shakna 7y ago
    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 https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html [1] https://clang.llvm.org/docs/PCHInternals.html https://clang.llvm.org/docs/PCHInternals.html [2] https://www.qnx.com/developers/docs/6.3.2/neutrino/utilities/i/icc.html https://www.qnx.com/developers/docs/6.3.2/neutrino/utilities... (-pch flag) [3] https://cmake.org/cmake/help/latest/command/target_precompile_headers.html https://cmake.org/cmake/help/latest/command/target_precompil...
- pjmlp 7y ago
  Other than not being able to use pseudo-modules in C, using a gigantic header file instead.
inetknght 7y ago
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.
likeliv 7y ago
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.

blondin 7y ago

> "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.

aninteger 7y ago

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.

deleted 7y ago

[deleted]

jeremycw 7y ago

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.

Athas 7y ago
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?
- shakna 7y ago
  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 https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html [1] https://clang.llvm.org/docs/PCHInternals.html https://clang.llvm.org/docs/PCHInternals.html [2] https://www.qnx.com/developers/docs/6.3.2/neutrino/utilities/i/icc.html https://www.qnx.com/developers/docs/6.3.2/neutrino/utilities... (-pch flag) [3] https://cmake.org/cmake/help/latest/command/target_precompile_headers.html https://cmake.org/cmake/help/latest/command/target_precompil...
pjmlp 7y ago
Other than not being able to use pseudo-modules in C, using a gigantic header file instead.

inetknght 7y ago

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.

likeliv 7y ago

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.