In Defense of C++

I feel like C++ is a bunch of long chains of solutions creating problems that require new solutions, that start from claiming that it can do things better than C.

Problem 1: You might fail to initialize an object in memory correctly.

Solution 1: Constructors.

Problem 2: Now you cannot preallocate memory as in SLAB allocation since the constructor does an allocator call.

Solution 2: Placement new

Problem 3: Now the type system has led the compiler to assume your preallocated memory cannot change since you declared it const.

Solution 3: std::launder()

If it is not clear what I mean about placement new and const needing std::lauder(), see this:

https://miyuki.github.io/2016/10/21/std-launder.html

C has a very simple solution that avoids this chain. Use structured programming to initialize your objects correctly. You are not going to escape the need to do this with C++, but you are guaranteed to have to consider a great many things in C++ that would not have needed consideration in C since C avoided the slippery slope of syntactic sugar that C++ took.

I absolutely agree - your chain of reasoning follows as well. It doesn't seem like it at first, but the often praised constructor/destructor is actually a source of incredible complexity, probably more than virtual.

But the c++ solution is transparent to the user. You can write entire useful programs that will use std:: containers willy-nilly and all propagate their allocators automatically and recursively without you having to lift a finger because all the steps you've mentioned have been turned in a reusable library, once.

I'd file that in the category of "what I can't recreate, I can't understand".

With that argument you could discard JavaScript because V8 is hard to understand.

C++ giving you the ability to create your own containers that equal the standard library is a bonus, it doesn't make those containers harder to use.

Yes, and to get that nice feature you have to pay an enormous cost.

Problem 1 happens, say, 10% of the time when using a C struct.

Problem 2 happens only when doing SLAB allocations - say, 1% of the time when using a C++ class. (Might be more or less, depending on what problem space you're in.)

Problem 3 happens only if you are also declaring your allocated stuff const - say, maybe 20% of the time?

So, while not perfect, each solution solves most of the problem for most of the people. Complaining about std::launder is complaining that solution 2 wasn't perfect; it's not in any way an argument that solution 1 wasn't massively better than problem 1.

That's a false comparison. There's a huge difference between a standard container library, and the combination of a (a) best-in-class byte code interpreter with a (b) caching, optimizing JIT, supported by (c) a best-in-class garbage collector.

I would argue that it's reasonable to say that creating a robust data structure library at the level of the STL shouldn't be that arcane.