I don’t see what’s “problematic” about running gdb on the core dump.

Curious. Is there a lint utility for C++?

They're called static analysis tools, and any editor or IDE worth using is going to integrate one. I use clangd, which can be integrated into vim, neovim, Helix, VSCode, etc.

If you just want a command-line tool, then I like clang-tidy.

There are many others.

gdb is a very inefficient way to catch a bug. You may say almost the last resort.

Yes, nowadays we have tools, static code analyzers, like CodeChecker to catch them.

I mean, I know from your other posts that you’re saying to just let an AI analyze the core dump. But that proves my point.

The very first thing is the correct error handling, do not allow to continue if "something went wrong"
the second best thing is the correct logs/messages, to inform the user (or developer) about what's going on.
the next is static analyzers
next is dynamic analyzers
Eye rolling, praying, crossing your fingers, and if nothing else helps, then welcome to gdb.

The “first thing” for your example would have been an address sanitizer. Works the same in both C and C++.

Don't forget that all that just happened because Microsoft refused to implement C99 in MSVC back in the 2000s. Now they fell behind with C++26 compiler support themselves.

Yes I believe you are correct, but that only proves Linus's point that he didn't need C++ to do it.

But it's also important to note, and something nobody here seems to be talking about; Linus was clearly speaking in the kernel context, and not generally, as the subsurface diving app that Linus wrote is in fact written, at least in part, in C++.
So clearly writing a kernel (or driver) verses writing an application are two completely different things, and with completely different concerns. So I can understand both Linus's point of view and the C++ creator's point of view, and do agree with both in the kernel context and application context respectively.
In that, you need to have total control over what happens and exactly how things are done (particularly memory management) in the kernel context, and having things hidden from you would be bad in that case. Whereas, in an application, you have the OS to manage resources, so therefore you only need to worry about how the app does things and manages whatever memory it has allocated to it. Therefore, you can leave the details of memory allocation for one thing to the language and OS to worry about.

If you're using an MVC approach to write your app, than using OOP would be practically mandatory, and it would be difficult, not to mention wouldn't make a lot of sense, to use C and "mimic" OOP with function pointers and therefore it would make a lot more sense to use C++ instead (particularly for graphical apps) - if the two choices of language was C or C++. The Qt library is a good example of that, itself is written in an MVC way, so it makes it very easy to write a Qt app in an MVC way (as I have done myself).

Personally, I prefer the MVC approach when writing apps and using OOP, as it does make a lot of sense to me.

My point was that you can make mistakes in C++, as much as you can in C. And if you're not using OOP, you wouldn't be using constructors (or deconstructors for that matter) - because you wouldn't have any classes in the first place.

While you can choose to ignore this in an application (why not go 4GL then right way?), memory access is still hundreds of times slower than L1/L2 cache access. If you do not make sure to arrange your data in a way, that it doesn't trash caches and produce 99 % overhead with caches misses, then the application is just painfully slow. Just imagine the compiler itself taking a day to compile a Linux kernel instead of a few minutes.

The OS doesn't do this arrangement for you and the compiler cannot either, because the latter would break the C++ ABI. Storing data in OOP class hierarchies is diametral to the design of real hardware.

TL;DR: Beyond trivial example code you need control over memory management in user space applications and work with custom allocators.

GTK has an object-oriented API written in C using GObject. It is a massive kludge involving type-casting macros, but the C API enabled widespread use.
Ed

In the kernel context, "C" makes sense. The kernel is a rarified environment with very specific (and actually, limited) responsibilities that require you to have absolute control. You don't have things like "runtime libraries" there. Your code includes direct assembler-language instructions that are architecture specific.

In "userland," on the other hand, "C++" is convenient because it does more of the heavy lifting for you. A nice, well-behaved "string" type. Lots of handy storage classes so that you're not hand-writing a linked list or a binary tree (again ...). And the compiler is efficient. By doing more of the messy work itself, it means less work (and, less opportunity for "stpuid tpyos") for you. You can simply focus on what you want to accomplish, and you have more powerful tools to do it with.

Of course, also in "userland," interpreted and semi-compiled languages hold sway. Many of these are implemented in C or C++, but they do even more of the work for you, at an acceptable cost in overhead. They all give you access to very large contributed libraries of already-debugged source code that you can simply pick up and use. (Want a complete web server? You can do it in six lines in Perl ... leveraging hundreds of lines that somebody else wrote and debugged.)

Funny you mention cache misses; I was reading something on another forum about game development where there was a comment that said something to the effect of storing certain data in contiguous memory (ie. arrays) to avoid cache misses. Otherwise and as you say, your game would be very slow because of constant cache misses.

So I assume games would use custom allocators, and would need to manage memory to make effective use of memory so said data can be loaded into processor cache memory the first time, rather than in separate chucks to avoid misses. Although we might be drifting off topic all that said...

I suspect that concern about "cache misses" qualifies as "bleeding edge." Which is, of course, where "games" commonly reside, especially when the user can't afford the most-expensive hardware.