Hacker News new | ask | show | jobs
by pjmlp 335 days ago
How can they be expected to learn this, when it is now fashionable to treat C and C++ as if they are scripting languages, shipping header only files?

We already had scripting engines for those languages in the 1990's, and the fact they are hardly available nowadays kind of tells of their commercial success, with exception of ROOT.

3 comments

It makes more sense for c++ due to templates, but the header only C library trend is indeed very strange. It's not surprising that people are coming up now who are writing articles about being confused by static linking behavior.
Even with C++ templates, if you want faster builds, header files aren't the place to store external templates, which are instantiations for common type parameters.
Header-only is simpler to integrate, so it makes sense for simple stuff, or stuff that is going to be used by only one TU there.

However, the semantics of inline are different between C and C++. To put it simply, C is restricted to static inline and, for variables, static const, whereas C++ has no such limitations (making them a superset); and static inline/const can sometimes lead to binary size bloat

It's not strange at all. You only have one file to keep track of and it does everything, you put the functions in any compilation unit you want, C compilation is basically instant, and putting a bunch of single file libraries into one compilation unit simplifies things further.
That might be why back in 1999 - 2002, I was waiting around 1h for each OS build variant of our product, a mix of Tcl and C native libraries, super fast.

It is only basically instant in toy examples, or optimizations completely disabled.

Sqlite is 6 MB and can compile in 2 seconds on msvc.

It's 25 years later, if you are waiting for an hour to compile a single normal C program, there is a lot of room for optimization. Saying C doesn't compile fast because 25 years ago your own company made a program that compiled slow is pretty silly.

Single file C libraries are fantastic because they can easily all be put into more monolithic compilation units which makes compilation very fast and they probably won't need to be changed.

Have you actually tried what I'm talking about? What are you trying to say here, that you think single file libraries would have made your 1 hours pure C program compile slower?

I used to compile sqlite regularly on msvc and it was more than 2 seconds. If this is a measurement it is a recent one with recent hardware.

Sqlite is a single compilation unit for much very different reasons than the header only libraries by the way. It's developed as many different files and concatenated together for distribution because the optimizer does better for it that way.

If this is a measurement it is a recent one with recent hardware.

This was on a 10 year old Xeon CPU.

Sqlite is a single compilation unit for much very different reasons than the header only libraries by the way. It's developed as many different files and concatenated together for distribution because the optimizer does better for it that way.

What difference does that make? What does it have to do with anything? You could develop anything like that.

The point here is that single file libraries work very well. If anything they end up making compilation times lower because they can be put into monolithic compilation units. When I say single file C libraries, I'm talking about single files that have a header switch to make them header declarations or full functions implementations. I'm not sure what you're trying to say.

> It makes more sense for c++ due to templates, but the header only C library trend is indeed very strange.

This is a symptom of the build tools ecosystem for C and C++ being an absolute dumpster fire (looking at you CMake).

> How can they be expected to learn this

It's the first thing Google and LLMs 'tell' you when you ask about reducing binary size with static libraries. Also LTO does most of the same.

To learn, first one needs to want to learn, which was my whole point.
Agreed, but article's author mentioned this as an issue, I would have expected him to find about and mention these flags as well.
An STB-style header-only library is actually quite perfect for eliminating dead code if the implementation and all code using that library is in the same compilation unit (since the compiler will not include static functions into the build that are not called).

...or build -flto for the 'modern' catch-all feature to eliminate any dead code.

...apart from that, none of the problems outlined in the blog post apply to header only libraries anyway since they are not distributed as precompiled binaries.