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@lists.isocpp.org>
Gesendet: Sa 25.10.2025 04:54
Betreff: Re: [std-proposals] Consistent behavior on Container actions
An: Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org>;
CC: organicoman <organicoman@yahoo.fr>;
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 GalaxyOn Friday, 24 October 2025 17:01:46 Pacific Daylight Time Jonathan Wakely via-------- Original message --------From: Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org>Date: 10/25/25 3:23 AM (GMT+01:00)To: std-proposals@lists.isocpp.orgCc: Thiago Macieira <thiago@macieira.org>Subject: Re: [std-proposals] Consistent behavior on Container actions
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@lists.isocpp.org https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals