In Defense of C++

It's really not that big of a deal once you know how it works, and there are tools like CMake and IDEs that will take care of it.

On Windows and OSX it's even easier - if you're okay writing only for those platforms.

It's more difficult to learn, and it seems convoluted for people coming from Python and Javascript, but there are a lot of advantages to not having package management and build tooling tightly integrated with the language or compiler, too.

I used to write a lot of C++ in 2017. Now in 2025 I have no memory of how to do that anymore. It's bespoke Makefile nonsense with zero hope of standardization. It's definitively something that doesn't grow with experience. Meanwhile my gradle setups have been almost unchanged since that time if it wasn't for the stupid backwards incompatible gradle releases.

This is pure Stockholm syndrome. If I were forced to choose between creating a cross-platform C++ project from scratch or taking an honest to god arrow to the knee, the arrow would be less painful.

Why? There are lots of cross platform libraries and most aspects are not platform specific. It's really not a big deal. Use FLTK and you get most of the cross platform stuff for free in a small package.

I agree -- I've been at it long enough -- cmake etc makes stuff pretty darn easy.

But in industrial settings where multi groups share and change libs something like debpkg may be used. You add caching and you can go quite deep quickly esp after bolting on cdci.

One must cop to the fact that a go build or zig build is just fundamentally better.

> It's bespoke Makefile nonsense with zero hope of standardization

technically Makefile is standardized (by POSIX), contrary to most alternatives.

/extremely pedantic

I would rather deal with Makefiles than Gradle.

I don't want any arrows in my knees but I agree.

The main reason I don't want to use C/C++ are the header files. You have to write everything in a header file and then in an implementation file. Every time you want to change a function you need to do this at least twice. And you don't even get fast compilation speed compared to some languages because your headers will #include some library that is immense and then every header that includes that header will have transitive header dependencies, and to solve this you use precompiled headers which you might have to set up manually dependending on what IDE you are using.

It's all too painful.

So I come from the C/C++ world, that's part of why I disagree with these takes. I wouldn't say any process involving CMake is "not that big of a deal" because I routinely see veteran developers struggle to edit cmake files to get their code to compile and link.

"It's not really that big a deal once you know how it works" is the case with pretty much everything though. The question is whether the amount of time needed to learn how something works is worthwhile though, and the sheer number of things you need to invest the time to learn in a language like C++ compared to more modern languages is a big deal. Looking at a single one of them in isolation like the build system essentially just zooms in one problem far enough to remove the other ones from the picture.

I think we can afford to strive for more than just "not quite the absolute worst" (for however we decide to measure quality).

Yeah, I definitely agree the newer tools are better, but sometimes the arguments against C++ get blown out of proportion.

It definitely has a lot of flaws, but in practice most of them have solutions or workarounds, and on a day-to-day basis most C++ programmers aren't struggling with this stuff.

It is a big deal even after you know how it works.

The thing is, the languages like Rust only make this easier within their controlled "garden". But for C and C++, you build in the "world outside the garden" to begin with, where you are not guaranteed of everyone having prepared everything for you. So, it's harder, and you may need third-party tools or putting in some elbow grease, or both. The upside is that when rustaceans or go-phers and such wander outside their respective gardens, most of them are completely lost and have no idea what to do; but C and C++ people are kinda-sorta at home there, already.

If you were forced to choose between creating a cross-platform project in one of the trendy language, but of course, which must also work on tiny hardware with a weird custom OSes on some hobbyist hardware, and with 30-year-old machines in some large organization's server farm - then you would choose the C++ project, since you will be able to make that happen, with some pain. And with the other languages - you'll probably just give up or need to re-develop all userspace for a bunch of platforms, so that it can accommodate the trendy language build tool. And even that might not be enough.

Also: If you are on platforms which support, say, CMake - then the multi-platform C++ project is not even that painful.

> I used to write a lot of C++ in 2017... It's bespoke Makefile nonsense

1. Makefiles are for build systems; they are not C++. 2. Even for building C++ - in 2017, there was no need to write bespoke Makefiles, or any Makefiles. You could, and should, have written CMake; and your CMake files would be usable and relevant today.

> Meanwhile my gradle setups have been almost unchanged since that time

... but, typically, with far narrower applicability.

It gets better with experience. You can have a minimal base layer of common but rarely changing functionality. You can reduce static inline functions in headers. You reduce data structure definitions, but put only forward declarations in header files. (Don't use C++ methods, at least don't put them in an API, because they force you to expose your implementation details needlessly). You can separate data structures from functions in different header files. Grouping functions together with types is often a bad idea since most useful functionality combines data from two or more "unrelated" types -- so you'd rather make function headers "by topic" than putting them alongside types.

I just created a subsystem for a performance intensive application -- a caching layer for millions or even billions of objects. The implementation encompasses over a 1000 LOC, but the header only includes <stdint.h>. There are about 5 forward struct declarations and maybe a dozen function calls in that API.

To a degree it might be stockholm syndrome, but I feel like having had to work around a lot of C's shortcomings I actually learned quite a lot that helps me in architecting bigger systems now. Turns out a lot of the flexibility and ease that you get from more modern languages mostly allows you to code more sloppily, but being sloppy only works for smaller systems.

What is "outside the garden" for Rust?

> but of course, which must also work on tiny hardware with a weird custom OSes on some hobbyist hardware, and with 30-year-old machines in some large organization's server farm - then you would choose the C++ projectt, since you will be able to make that happen, with some pain.

With the old and proprietary toolchains involved, I would bet dollars to doughnuts that there's a 50% odds of C++11 being the latest supported standard. In that context, modern C++ is the trendy language.

Go build is fundamentally better? How so? Go build is so light on features that adding generated files to source control is a norm in go land.

Generated files are noise.

Newer languages builds have built in version resolution to resolve dependencies together with smarter ways to reference dependencies without #include.

And that's better

CMake has become the defacto standard in many ways, but I don't think it's that easy to deal with. There's often some custom support code in a project (just as with make files) that you need to learn the intricacies of, and also external 3pp modules that solve particular integration issues with building software that you also need to learn.

For me, base CMake is pretty easy by now, but I'd rather troubleshoot a makefile than some obscure 3pp CMake module that doesn't do what I want. Plain old makefiles are very hackable for better or worse [1]. It's easy to solve problems with make (in bespoke ways), and at the same time this is the big issue, causing lots of custom solutions of varying correctness.

[1]: Make is easy the same way C is easy.

I didn't say "easy to deal with", I said it's not bespoke nonsense, and that you could keep it mostly unchanged today, 8 years later.

Plus - the "obscure third party modules" have been getting less obscure and more standard-ish. In 2017 it was already not bad, today it's better.

Oh, say, use some binary C library with some header, that you found on some system.

That shouldn't be too tricky, assuming the binary is built for the sort of device you want to run on. At least not much more complicated than calling any other C code, using bindgen.

Yep, Rust made design decisions to make this case as zero overhead as it can be.

> You have to write everything in a header file and then in an implementation file.

No you don't. You write your guaranteed to the public interface into the header file. When you start to put code in there it stops being a header file.

> because your headers will #include some library that is immense and then every header that includes that header will have transitive header dependencies

Your approach is what leads to this problem. Your header files should be tiny and only composed of, well, headers. Also almost all header files should have include guards, so including more then once should be a no-op.[1] Nothing stops you from including implementation files.

[1] When you say that your or compiler doesn't have that optimization: When it has the complexity to support precompiled header files, it can also implement this optimization.