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