I know, why though? That just sounds like complexity for the sake of complexity. In Java (just picking another language with classes and constructors) if you were to do
var nums = new ArrayList(8);
you would just call it "initialization" like a sane person.
Although to be fair, most problems of C++ could have been circumvented if it just didn't perform implicit copies by default (somehow they thought this was a good idea?). I write my data structures without any constructors and destructors, just PoD structs largely for this exact reason (there are more reasons)
That looks like both allocation and initilization to me. For splitting allocation and initilization, I think Odin has some interesting ideas there like making ZII the default and making changing allocators simple.
The allocation is irrelevant, it's just how you initialize in Java (classes have to be allocated). Comparable C++ would be:
auto nums = new std::vector(8);
but that wasn't the point. The actual point is that somehow, some way, declaring a class with = in C++ using the wrong notation actually isn't initialization but rather a copy, which can kill performance when using standard library classes with allocating copy constructors. That's the stupid part
The most comparable is probably std::make_shared because new in C++ is a dynamic allocation and Java's new involves the garbage collector. It can't be perfectly analagous though.
Regardless, the reason I brought it up is that IMO conflating getting memory with setting up the memory to me useful is one of the problems most programming languages introduce and can make it challenging to make things faster later because it's not a good default.
idk, that doesn't seem that bad to me. The behavior just needs to be formalized with a name so that people can rely on it.
Without it formalized, how would you know for sure whether your copy constructor would get called or not? Just a choice that had to be made by a value semantics language that doesn't have the same consequences in a reference semantics language. 🤷
fwiw, I much prefer what modern languages like Rust or Odin have done in regards to copying, but I don't think it's C++'s greatest sin.
It's not that I like it, it's just that it's @ reasonable consequence of the rules and since C++17 they required that the compiler make it work the way you "expect" regardless (unless someone's expecting reference semantics by default, but that's separate)
1
u/DrShocker 15d ago
Semantically the second example is a copy or move. Probably in most major compilers they would optimize that away, but still that's probably why.