Hacker News Reader

Comment by int_19h | Hacker News Reader

These are kinda misleading - "single-file" is a technically accurate term, but if you think that implies that you can just #include them, it's not that (i.e. not what is normally called "header-only"). It's basically a header and implementation combined into a single file, with the implementation part #ifdef'd. So you need manually instantiate that implementation in one of your existing translation units, or add a new one specifically for that purpose. At that point, I don't see how this is preferable to just having an .h/.cpp as usual, and zipping it for distribution purposes.

View on HN

They're also known as STB-style headers, but IMHO all those names are correct.

One advantage is that you don't need to mess with build systems for configuration, instead put the configuration defines before the implementation right in the source code.

Another advantage is potentially faster compilation if you put many implementations into the same implementation source. Same idea as unity-builds basically. Even though you're using dozens of header-only-"modules", the compiler only builds a single file.

I disagree it's as simple as you suggest. Trouble seems to be that in a perfect world, you're right. It would be the same.

In the nasty real world, these build systems introduce more issues for more people. Then linking the shared object or DLL adds management issues, naming issues, arch etc. But that's for separate dependency building as a binary.

Has every one of these side compilation steps gone perfectly for you? No. At some point they wasted your time.

This concatenation-build step is done reliably beforehand, even if simple, can be assembled and be tested by the releasing party. Saves the user some trouble.

A pre-built binary is about as easy if done sensibly. Boost is mainly header only but has some libs still requiring linking, which requires you digging into that library's particulars.

All of those are steps that have tradeoffs in time, attention, flexibility and risk.

Careful of that word "... just". Just do this! I can just do that! The full hassle/cost requires pulling out of just the compile step, in this instance.

I'm not talking about prebuilt binary libraries, much less DLLs. I'm comparing it to just dropping an .h and a .cpp file directly into your project. This one requires dropping an .h file, and then either adding a .cpp file (which you have to write manually, even if it's just one line of code), or adding an implementation #include to one of the existing .cpp files.

I guess my point is that I just don't see the benefit of concatenation here.

It looks like every chnage will also lead to recompiltion of all dependent files. It seems quite inefficient.

Such library-style headers that you drop into your own project are usually never changed.

You can also group the stable headers into a different implementation source file from the headers that change frequently.

less messing with build systems.

You could still #include the .cpp file even if they were seperate files. You wouldn't even need the define.

I don't see why tho - either way you have an implementation file to add, so what's the difference?

Reply on news.ycombinator.com