Hacker News Reader

Comment by ddtaylor | Hacker News Reader

Thank you for sharing. The only thing I don't understand why this is a header only implementation with a macro that goes in a C++ file.

    #define CANVAS_ITY_IMPLEMENTATION

View on HN

It is common for header-only libraries: you need to include this header in one c++ using the macro for linking (don't use that macro in other c++ files to avoid duplicate symbols). In C++, you can declare a function as many times as you want, but you can only define it (write the actual body) once in the entire project.

I understand that part, but I don't see why do this instead of basic Makefile or CMake setup. It seems like more work than a regular linker at that point. For what purpose?

Because not everyone is using Makefiles or CMake.

A true header-only library should be build-system agnostic and this is one way to do that.

We can argue about build systems for C++ all day long and never come to an agreement. With this approach this piece of code can be used anywhere.

We can also argue C++ is not a scripting language, which is what is approach is all about.

When C and C++ were the main programming languages during the 1990's, and commercial compilers abounded strangely we could manage handling all those build systems approaches.

I think you are romanticizing the past. I’m pretty sure integration of third party C or C++ code sucked as much back then if not more. You just didn’t have as much of those dependencies because open source was in its infancy and the number of available libraries was much smaller too.

that's a common pattern in C++ land because there is no standard way to use libraries in C++

https://github.com/p-ranav/awesome-hpp

It is a common pattern among those that don't want to learn build systems, which isn't exactly the same.

Or among those who want to support any build system

We managed during the last 20 years just fine.

In my experience. I've run into the issue quite often. You find some library, it has its own build system (meaning not the one you're using). It has special rules etc... Integrating into your build system is time consuming and frustrating. Compiler errors from includes, linker errors, etc..

None of that happens with a single file C++ library.

Yeah, and?

There isn't a single build system without issues, other than siloed languages without language standards.

Header libraries only started to be a thing when scripting generation educated in Python and Ruby during the 2010's turned into compiled languages.

That's... definitely a way to describe Sean Barrett, whose excellent libraries popularized this style.

And what build system do you recommend the entire ecosystem support? Well, I choose (arbitrarily different and incompatible one to prove a point). Do you see the problem?

I see a learning problem, because there is hardly a programming language in widespread use using a single one.

And if you're going to point out Go or Rust, it kind of works as long, nothing else is used, and they don't need to interact with platform SDKs.

Everything is easier with single file headers. This idea that a build system and single header libraries are mutually exclusive is silly.

You can take multiple single file libraries and put them into one compilation unit. Then you have minimal files and minimal compilation units. Compilation is faster, everything is simpler.

What is silly is pretending everything is a scripting language.

I don't know what that is supposed to mean and I don't think it means anything.

I'm talking about real pragmatic benefits and you're making some vague hand wavy judgement without any tangible explanation.

I wrote a mildly popular header only library with exactly this pattern once. Then there came a guy adding cmake. I didn't really know it back then so I didn't stop him. The downloads went to literally zero lol. Cmake is an extremely vocal minority.

Who said anything about cmake specifically?

Reply on news.ycombinator.com