> Want to make a copy of something? Who is responsible for calling constructor/destructor.
What do you mean? The compiler will do it for you.
> This should be the exception - rather than the default way to think about structs.
the way that RAII in C++ recursively construct and destroys arbitrary object graphs is extremely powerful. It is something that very few other languages have (Rust, any other?). It should definitely be the default.
> I think we should separate resource allocation from use. Allocators are the things that care about cleanup, move, etc.
I'm not sure what you mean by use. If you mean we should separate allocation from construction, I agree! But then so does C++. They are tied by default, but it is easy to separate them if you need it.
> What do you mean? The compiler will do it for you.
It will. And the only cost to you is you have to understand initializer lists, pod types, copy constructors, move constructors, launder, trivially_destructible, default initialization, uninitialized_storage, etc.
> the way that RAII in C++ recursively construct and destroys arbitrary object graphs is extremely powerful
And extremely complex.
The big fallacy here is that you would want to manage resources at the individual node level - rather than for a batch.
> I'm not sure what you mean by use
It’s similar to the idea of arenas (also made difficult by constructors btw). You can make sophisticated systems for managing allocations of individual nodes in a graph - like reference counted smart pointers. Or you can avoid the problem entirely by deallocating the whole group at once.
Imagine if C++ structs were required to be pod and classes were not. Then you could always know that a struct can be trivially allocated/deallocated etc.
Then you could design data structures for pod types only that didn’t have to worry about O(n) cleanup and init.
There is often value in putting a class in a struct. Your proposed rule of struct is POD means there will be many less structs, and force people to think about POD or not when the vast majority of the time that doesn't matter to them.
> There is often value in putting a class in a struct.
And what’s the cost?
Note that a reference to a class is still POD. It just doesn’t have ownership.
Also I’m not making a specific policy proposal. Im identifying constructors and destructors as the source of complexity. What should we do about it?
> and force people to think about POD or not
No such thing as feature you don’t have to understand. The reason this article exists is that C++ programmers must deal with complex initialization behavior.
Can a C++ programmer not understand move semantics? Or copy constructors?
Most of the time the cost is not worth worrying about.
Most of the time you don't need to think about move or copy - the compiler does the right thing for you. When there are exceptions it is generally when you need to disable them which is simple enough. When you think about constructors you only need to think about the local class in general, and not how they interact with the larger world.
constructors and destructors eliminate a lot more complexity than they solve. They enable RAII and thus clear ownership of everything (not just memory!).
Sounds like C++ has everything you want and is just the right amount of complexity for you.
Every version of c++ has added something I want and overall makes the language better. backward compatibility means I can start using the new stuff without rewritting the old and so I can take advantage of it now. (At least somewhat - calling old APIs is weird)
> Imagine if C++ structs were required to be pod and classes were not. Then you could always know that a struct can be trivially allocated/deallocated etc.
static_assert(is_trivial_v<T>)
Unfortunately other people aren’t writing simple C structs they are using the full feature set of C++ and I have to use their code.
So no this doesn’t solve C++ complexity including the initialization problem.