All the reasons to go header-only are superficial, as is the counter to the compile time problem with thorough templating of every function. This isn't about minor pros and cons, it's about not breaking stuff.
One of the great things about separate declaration and implementation is exactly that, the latter is totally shielded from impact and from impacting anything else. To argue for header-only is to claim that the implementation does not and will never cause any conflict with anything else ever, which is pretentious bullshit.
Sqlite gets it right - they produce amalgamated source, but it's one header file and one source file. The header looks suspiciously large, but that's only because it's 99% comment text to document it.
Some libraries are designed header-only but have a separated version available or a script to produce that, so they get a pass, at least it's not forced header-only.
Then we have shit like Eigen. Nice actual library, but good god damn have they caught the gay header-only HIV. It's just too much time to hit an unexpected compile error for which the resolution involves editing an included library, in this case just to move implementation out of the headers.
For anyone who needs an analogy, the problem with header-only libraries is the same as the problem with open-plan offices.
I mostly touch modern languages today, and I do like writing out a function header only once. But there is a reason why implementing a plugin for any modern language involves C or C++. Nobody is backing a python module with nodejs or a nodejs module with python.
Of course performance is a factor, but part of it is the header files, and being able to ship an implementation separately as a resource that many languages can load.
Yes C/C++ have libraries that are very nice to access from other languages. Accessing libcurl or libsqlite3 is great. But other languages besides C have things to offer to other languages. If pandoc wasn't implemented in Haskell every language would be wrapping libpandoc. But they don't, and instead use IPC to make use of that. Why? It's technically infeasible. Why? No headers separate from a binary.
x0x7 0 points 5 months ago
I mostly touch modern languages today, and I do like writing out a function header only once. But there is a reason why implementing a plugin for any modern language involves C or C++. Nobody is backing a python module with nodejs or a nodejs module with python.
Of course performance is a factor, but part of it is the header files, and being able to ship an implementation separately as a resource that many languages can load.
Yes C/C++ have libraries that are very nice to access from other languages. Accessing libcurl or libsqlite3 is great. But other languages besides C have things to offer to other languages. If pandoc wasn't implemented in Haskell every language would be wrapping libpandoc. But they don't, and instead use IPC to make use of that. Why? It's technically infeasible. Why? No headers separate from a binary.