In Defense of C++

fouronnes3

This is a good article but it only scratches the surface, as is always the case when it comes to C++.

When I made a meme about C++ [1] I was purposeful in choosing the iceberg format. To me it's not quite satisfying to say that C++ is merely complex or vast. A more fitting word would be "arcane", "monumental" or "titanic" (get it?). There's a specific feeling you get when you're trying to understand what the hell is an xvalue, why std::move doesn't move or why std::remove doesn't remove.

The Forest Gump C++ is another meme that captures this feeling very well (not by me) [2].

What it comes down to is developer experience (DX), and C++ has a terrible one. Down to syntax and all the way up to package management a C++ developper feels stuck to a time before they were born. At least we have a lot of time to think about all that while our code compiles. But that might just be the price for all the power it gives you.

[1] https://victorpoughon.github.io/cppiceberg/

[2] https://mikelui.io/img/c++_init_forest.gif

jandrese

In Linuxland you at least have pkg-config to help with package management. It's not perfect but neither is any other package management solution.

If I'm writing a small utility or something the Makefile typically looks something like this:

    CC=clang
    PACKAGES=libcurl libturbojpeg
    CFLAGS=-Wall -pedantic --std=gnu17 -g $(shell pkg-config --cflags $(PACKAGES))
    LDLIBS=$(shell pkg-config --libs $(PACKAGES))

    ALL: imagerunner

    imagerunner: imagerunner.o image_decoder.o downloader.o

scj

"you can write perfectly fine code without ever needing to worry about the more complex features of the language. You can write simple, readable, and maintainable code in C++ without ever needing to use templates, operator overloading, or any of the other more advanced features of the language."

You could also inherit a massive codebase old enough to need a prostate exam that was written by many people who wanted to prove just how much of the language spec they could use.

If selecting a job mostly under the Veil of Ignorance, I'll take a large legacy C project over C++ any day.

gmueckl

C++ will always stay relevant. Software has eaten the world. That transition is almost complete now. The languages that were around when it happened will stay deeply embedded in our fundamental tech stacks for another couple decades at least, if not centuries. And C and C++ are the lion's share of that.

COBOL sticks around 66 years after its first release. Fortran is 68 years old and is still enormously relevant. Much, much more software was written in newer languages and has become so complex that replacements have become practically impossible (Fuchsia hasn't replaces Linux in Google products, wayland isn't ready to replace X11 etc)

Night_Thastus

When it comes to programming, I generally decide my thoughts based on pain-in-my-ass levels. If I constantly have to fiddle with something to get it working, if it's fragile, if it frequently becomes a pain point - then it's not great.

And out of all the tools and architecture I work with, C++ has been some of the least problematic. The STL is well-formed and easy to work with, creating user-defined types is easy, it's fast, and generally it has few issues when deploying. If there's something I need, there's a very high chance a C or C++ library exists to do what I need. Even crossing multiple major compiler versions doesn't seem to break anything, with rare exceptions.

The biggest problem I have with C++ is how easy it is to get very long compile times, and how hard it feels like it is to analyze and fix that on a 'macro' (whole project) level. I waste ungodly amounts of time compiling. I swear I'm going to be on deaths door and see GCC running as my life flashes by.

Some others that have been not-so-nice:

* Python - Slow enough to be a bottleneck semi-frequently, hard to debug especially in a cross-language environment, frequently has library/deployment/initialization problems, and I find it generally hard to read because of the lack of types, significant whitespace, and that I can't easily jump with an IDE to see who owns what data. Also pip is demon spawn. I never want to see another Wheel error until the day I die.

* VSC's IntelliSense - My god IntelliSense is picky. Having to manually specify every goddamn macro, one at a time in two different locations just to get it to stop breaking down is a nightmare. I wish it were more tolerant of having incomplete information, instead of just shutting down completely.

* Fortran - It could just be me, but IDEs struggle with it. If you have any global data it may as well not exist as far as the IDE is concerned, which makes dealing with such projects very hard.

* CMake - I'm amazed it works at all. It looks great for simple toy projects and has the power to handle larger projects, but it seems to quickly become an ungodly mess of strange comments and rules that aren't spelled out - and you have no way of stepping into it and seeing what it's doing. I try to touch it as infrequently as possible. It feels like C macros, in a bad way.

lordleft

Great article. Modern C++ has come a really long way. I think lots of people have no idea about the newer features of the standard library and how much they minimize footguns.

sunshowers

Lambdas, a modern C++ feature, can borrow from the stack and escape the stack. (This led to one of the more memorable bugs I've been part of debugging.) It's hard to take any claims about modern C++ seriously when the WG thought this was an acceptable feature to ship.

Of course, the article doesn't mention lambdas.

im3w1l

Why wouldn't it be acceptable to ship? This is how everything works in C++. You always have to mind your references.

sunshowers

Exactly! This is my problem with the C++ community's culture. At no point is safety put first.

nzeid

> Just using Rust will not magically make your application safe; it will just make it a lot harder to have memory leaks or safety issues.

You know, not sure I even agree with the memory leaks part. If you define a memory leak very narrowly as forgetting to free a pointer, this is correct. But in my experience working with many languages including C/C++, forgotten pointers are almost never the problem. You're gonna be dealing with issues involving "peaky" memory usage e.g. erroneously persistent references to objects or bursty memory allocation patterns. And these occur in all languages.

whobre

> C++ is very old, in fact, it came out in 1985, to put it into perspective, that’s 4 years before the first version of Windows was released

Nitpick, I guess, but Windows 1.0 was released in November 1985:

https://en.m.wikipedia.org/wiki/Windows_1.0

jasperry

The author argues that if rewriting a C++ codebase in Rust makes it more memory-safe, that's not because Rust is memory-safe. What?

justicehunter

I'm not sure what I feel about the article's point on boost. It does contribute a lot to the standard library and does provide some excellent libraries, like boost.Unordered

AHTERIX5000

I write C++ daily and I really can't take seriously arguments how C++ is safe if you know what you're doing like come on. Any sufficiently large and complex codebases tend to have bugs and footguns and using tools like memory safe languages limit blast radius considerably.

Smart pointers are neat but they are not a solution for memory safety. Just using standard containers and iterators can lead to lots of footguns, or utils like string_view.

franky47

What’s a good (ie: opinionated) code formatter and unit test framework for C++ these days?

I just had a PR on an old C++ project, and spending 8 years in the web ecosystem have raised the bar around tooling expectations.

Rust is particularly sweet to work with in that regard.

lang4d

My go to for formatting would be clang-format, and for testing gtest. For more extensive formatting (that involves the compiler) clang-tidy goes a long way

IshKebab

The only formatter is clang-format, and it isn't very good. Better than nothing though.

jonstewart

Catch2 is great as a unit test framework.

Running unit tests with the address sanitizer and UB sanitizer enabled go a long way towards addressing most memory safety bugs. The kind of C++ you write then is a far cry from what the haters complain about with bad old VC6 era C++.

g42gregory

I am not sure C++ needs a defense. Especially after C++ 11 cleanup.

HN

In Defense of C++

In Defense of C++