Hacker News Reader

Comment by ktpsns | Hacker News Reader

This is a typical idiom frequently seen in modern C and C++ codes. As https://github.com/krychu/wfc#how-to-use-the-library says, you need to define a macro in a C file in order to "expand" the actual code there.

Having the code in the header gives a bit more flexibility considering the file layout. IMHO this is an awkward consequence of the missing de-facto-standard in C/C++ build systems.

View on HN

How is it more flexible exactly?

I hate this idiom every time I come across it. I like to look at the header file to see the interface and important documentation, and this just obscures it. Depending on your compiler it can make debugging a huge pain as well.

It does seem that 'modern' idioms tend to just be doing the same thing in a more obfuscated manner. Just a .c/.h pair would have been easier to add to your source.

That would be easier if the most popular build systems weren’t terrible

Or I don't know, people actually bothered to learn them.

Learning something doesn't stop it being terrible. One time I ran `cmake`, and forgot to run `sudo -k` beforehand. It reconfigured my system.

That has more to do with sudo than cmake.

This might be an unpopular opinion, but compiling a program into a local directory shouldn't try to install packages globally. `make install`, I could understand doing that.

I had no idea that cmake would do this, after reading quite a lot of things about cmake v.s. make and how to write various makefiles for them. I posit that the C build tools are fundamentally hard to comprehend.

Any build tool can do whatever they feel like.

Blindly trusting it will lead to the same outcome, regardless of the programming language ecosytem.

Sure, but should it? Do you really want nasal demons from your build tool?

Due to the success of build tools like Gradle, build.rs or any other one that packages a Turing complete language to steer a build, apparently many want such daemons on their homedir.

Just because you can do something, doesn't mean you should. A `build.rs` is supposed to be for compiling non-Rust code and stuff like that, not mucking about with the package manager – and by and large, people don't use it for mucking about with the package manager.

People use it to muck with the host OS in any possible way, unless one bothers to do the necessary code audit.

Besides that was just one example, there are plenty of them with turing complete languages.

If the library is installed separately, the terribleness is about adding "-lfunkylib" to your linker command.

If you embed the source in your project, the terribleness is about adding to your Makefile:

  funkylib.o: funkylib.c
       $(CC) $<

  myfinalexe: ... funkylib.o ...
       # your existing executable creation (linking) command

This is a valid point. I was on the fence between doing .c/.h pair and a single .h. But finally took the inspiration from: https://github.com/nothings/stb.

Overall I think the code in the library is good, this was just the thing that stuck out to me most. Congrats on getting shared on HN.

> I like to look at the header file to see the interface and important documentation

This still works nicely: the important stuff (documentation and public interface) is at the top, followed by the 'unimportant' implementation at the botton of the file.

STB-style headers are a bit different from typical C++ 'single header libraries' in that they put the declaration and implementation into separate sections in the header file (with the implementation inside an #ifdef/#endif pair), while C++ headers are usually a wild mix of class declarations intermixed with implementation code in template and inline functions (which is indeed harder to read).

I don't quite understand how debugging is affected? E.g. there are (usually) no inline functions in STB-style headers.

Its a slow to compile idiom. The only reason to use it is if you expect people to download the header and plop it in. Basically its an end-run around build systems.

In my tests with STB-style headers written in C between a few thousand to a few tens of thousands of line of code, the compilation speed difference between including the header with disabled implementation, versus including with the implementation section removed from the file is absolutely negligible. This is because the implementation block is already skipped in the preprocessor, and never parsed by the compiler frontend.

Again, this is different from typical C++ single-header-libraries (e.g. pretty much all C++ stdlib headers) where the implementation code is inlined or in template code.

This is a sad idom followed in C and C++ libraries that cannot be bothered to learn build tools, dealing with C and C++ as if they were scripting languages.

Have you ever tried using a unity build?

Another nonsense, no I haven't ever bothered with it.

A hack designed by those that cannot be bothered to modularize a build with binary libraries.

It definitely is a hack, but it's not nonsense. The speedups on large projects are significant, even on modularised ones.

Not entirely. If you think about it, a resulting C binary is just data and text - it’s all compiled into a single unit of globals and functions, much like a unity build layout. Regarding optimization it allows for LTO without the need for a link time optimizer. Regarding convenience, it spares one from function prototypes and using Make or CMake. Should one use Make to speed up build times it’s as simple as tossing the unity code you’re not working on into a precompiled header; this primes the compiler for a quick compilation of the newly written code. As for design, I find unity builds resemble the design mind of a mechanical, civil, or electrical engineer - a single assembly (main.c) incorporates sub assemblies (*.c) like a CAD designer would design SolidWorks parts for a vehicle or spacecraft

I rather prefer the software engineering mind to use binary libraries for what they were designed for.

It's a completely valid and useful idiom. Whatever build system you use, it's trivial to add these kind of libraries to the project.

The fact that one has to learn complex build tools (and often multiple ones), is the sad thing here. Luckily there are also unity builds, which are extremely handy in many contexts, because they are so fast and easy to use between different platforms without having to deal with annoying external tools.

You don't need an elaborate build system to add a single .c file to your project

and now you need to add a .h to where ever you need to call those function. This .h will need to know if it got included multiple times, and so isn't just a trivial declaration.

It's just easier to have a single .h you include.

>to add a .h to where ever you need to call those function

No, it can be in a single place and you can just #include it.

>This .h will need to know if it got included multiple times, and so isn't just a trivial declaration.

This is the point of using header guards.

>It's just easier to have a single .h you include.

Depending on the build tool it's the same or only marginally easier (you save like 10 characters)

All code in the header leads to a lot of duplicated work for the compiler, which means slow build times. You should avoid this unless it is absolutely necessary for performance to inline methods.

That work will be done by the preprocessor and should be fairly quick given it doesn't compile the duplicated code and only removes it.

It may still generate code for function definitions, which are deduped by the linker, so a lot of the code can still go through the whole compiler.

An STB-style header with the implementation disabled (which is the default) looks exactly the same to the compiler as a regular C header which only contains public API declarations (e.g. just struct declarations and function prototypes, and most importantly, no inline code).

All code that would otherwise live in .c files is between an #ifdef/#endif block which is only activated in a single compilation unit in the whole project.

Not sure how this approach would lead to redundant "function definitions" which would need to be deduped by the linker. The only overhead is in the preprocessor for skipping the implementation block, but that happens pretty much at IO speed - it's not comparable with the parsing overhead in typical C++ headers with template and inline code.

Sure, after brushing up on this "stb style", then I see what you mean.

Still, it seems like an ugly kludge to cope with a breathtakingly antiquated way of doing things.

Why should it be any more complicated than that?

What ever happened to keeping it simple?

Things can be locally simple but have complex and chaotic implications. E.g. just by pushing the complexity up a level and dumping it on literally everyone else. I've learned over the years that complexity sometimes has a right place and a wrong place. (Most times complexity ends up everywhere, TBH.) I think resolving references between different parts of code in different compilation units is definitely within the purview of a compiler/build system, and should not be up to every programmer to flail at poorly with #ifdefs.

> with a breathtakingly antiquated way of doing things.

I think it's mainly a fix/workaround for the breathtakingly antiquated build systems in the C/C++ world ;)

In the end, STB-style single-header vs. a single .h/.c pair is not all that different, both are equally straightforward to integrate into a project.

The actual problem are libraries made of dozens/hundreds/thousands of header and source files and coming with their own complex build system setup.

Reply on news.ycombinator.com