It is the task of the one writing a class to make it behave as regular as possible. This includes avoiding side-effects of a change between construction and assignment. The containers assume your class is well-behaving.   In many cases this can be delegated to the members (rule of 0), if the member types are well-written (RAII). Owning raw C pointers are not good members in this regard.     To your free question: Dereferencing a non-initialized pointer p with *p won't allocate memory. It makes the program invalid (UB).   It is not useful to talk about C++ principles and then using C pointers.   In C++ you can have empty objects or containers, which still can do operations or allocate memory on the fly together with nice syntax.   (In C you would have to emulate the object orientedness with functions receiving structs as this pointer; some C frameworks or libraries or custom codebases do.)   Best use std::vector or std::string and recreate an example.   -----Ursprüngliche Nachricht----- Von:organicoman via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Sa 25.10.2025 04:54 Betreff:Re: [std-proposals] Consistent behavior on Container actions An:Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]>; CC:organicoman <organicoman_at_[hidden]>; Given a container of capacity 8, but has 5 elements.  Let copy assign to it a container of same capacity and full (8 elements) All current containers implementation mixe two operations,   5 copy assignment + 3 copy construction.  The same for move assignment: 5 move assignment + 3 move construction.  If the value_type of the container has some side effects for its move/copy assignment operators (like a log msg), that will be very confusing,  and imposes on the user to get in the implementations details of the container.   However, if the container keeps a consistent action distribution over the elements, and avoid mixing two actions (construction and assignment, above), then local reasoning will be sufficient for testing and debugging.  Apart from this explanation. As a free question, how can we tell the difference between dereferencing a pointer to an object within its lifetime,  and the one not yet initialized. Like in this example   ///  T t1, t2;  T* p;  T* q = &t1;  *p = t2; // must pick construct by copy assign  *q = t2; // must pick regular copy assign ///    Sent from my Galaxy   -------- Original message -------- From: Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> Date: 10/25/25 3:23 AM (GMT+01:00) To: std-proposals_at_[hidden] Cc: Thiago Macieira <thiago_at_[hidden]> Subject: Re: [std-proposals] Consistent behavior on Container actions  On Friday, 24 October 2025 17:01:46 Pacific Daylight Time Jonathan Wakely via Std-Proposals wrote: > Why? > > Your mental model is not how it works, why would we complicate things to > support an incorrect model? Agreed, it seems to apply a pedantic purism of what a container should do, instead of being practical. The example of moving is telling: technically, moving one container to another could just move all elements - it is what a container using Small Container Optimisation (like std::string) does. But in practice, doing that for arbitrarily-sized containers is just wasteful, because the operation can in many cases be achieved in O(1), and in the worst it's an O(n) destruction of the target container's elements. Non-move assignment usually does try to assign element by element, provided the target container has that many elements. The question is what happens when it has fewer: should the container default-construct elements just so they be assigned to? That might be correct, but it's wasteful. And if someone *really* needs that, they can just ensure the target container has the right size before the assignment. There's no need to change anything in the library. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org   Principal Engineer - Intel Data Center Group -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals