Date: Sun, 26 Oct 2025 18:00:17 +0100
-------- Original message --------From: Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]> Date: 10/26/25 4:52 PM (GMT+01:00) To: std-proposals_at_[hidden] Cc: Sebastian Wittmeier <wittmeier_at_[hidden]> Subject: Re: [std-proposals] Consistent behavior on Container actions
>You can create a container, which applies >certain operations (like copy, move, >empty) on all of its contained objects.It would be more intuitive to have this as the default. ///vec(const vec&) ;// copy each elemvec(vec&&);// move each elemvec& operator =(const vec&);//assignment by copy construction or copy assign each elemvec& operator =(vec&&);// assignment by move construction or move assign each elemvoid clear();//destroy each elem///The common behavior is that after each operation the source container, still have the same capacity and size, and the internal pointer to the heap is still valid (!= nullptr). Except for clear() where size =0;In this scenario, the moved-from state of the container could be delegated to its elements, given a conventional protocol...for expl, if we agree that we never move individually any element , then it is safe to test if the container is moved-from by delegating to one of its element i.evec.is_moved_from() <=> vec[idx].is_moved_from();//idx < vec.size()>You can create a container, which allows >all or more operations (including >is_moved_from()) in its moved from state. >What the standard specifies, is a minimum for the classes to follow. Even the >standard library containers are allowed >to do more than the minimum for a >specific implementation.The minimum should be the default and the correct behavior,.Specializing the behavior must be for real special cases.>A more 'extreme' variant of movement is >relocation.>Perhaps in all or at least most cases, >the program could (in theory in the >future) statically at compile-time test, >whether a variable was relocated. Or >alternatively it is possible to reuse the >name after relocation.>A relocated object has no moved from >state, but cannot be accessed at all.In my little side research, i found that the concept of 'borrow checker' and 'pointer provenance' combined must be a compiler only concept i.e as a user you cannot introduce them into your code, but the compiler use them to check for correctness, static analysis and function overload.Right now, i don't have a full view of how this should be done, but i started this thread from the same start point which lead me to the above observation.I assumed it will lead everyone here to the same result, and i was interested to see how everyone will tackle it..... well not everything we assume will happen :|Anyway...Thanks all for your feedback.End of thread. -----Ursprüngliche Nachricht-----Von: organicoman via Std-Proposals <std-proposals_at_[hidden]>Gesendet: So 26.10.2025 16:05Betreff: Re: [std-proposals] Consistent behavior on Container actionsAn: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>; CC: organicoman <organicoman_at_[hidden]>; body { font-family: monospace; } On Fri, Oct 24, 2025 at 10:54 PM organicoman via Std-Proposals<std-proposals_at_[hidden]> wrote:>>>> 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.>Does it impose anything, though? Yes Jason, if for example the growth factor of the implementation is different, the side effects will be different. >What implementation details does code*need to know* about this? Some examples would be, growth factor, ×2? ×1.5?....what optimization used for trivially copyable value_type... 'noexcept' aware code...etc >When would it actually *matter* to theuser, and why? Local reasoning...- I expect copy assignment, then i see mixture of copy assignment/construction...why?- Test case implementation. If your only way is to test against a text string.And other reasons not on top of my head right now. In my little research I'm doing right now, I found that move operations are missing something A move operation should allow to be tested against.... vec.is_moved_from(); Should yield 'true' or 'false'.Which is not the case in the current state of the language.>Copy assignment and copy construction fundamentally should yield thesame result: two objects with equal values. No >code should *care* if>this is accomplished by constructing a new >object or assigning into an>existing one; the result ought to be the same. >That's what "copy">means, and if your code cares about the >difference, then I would>suggest that its idea of what "copy" means is >incorrect.>The same goes for movement, but even >moreso (and that's ignoring the>issue everyone else brought up about how >moving in containers ought to>work).>Your code can tell the difference. But I >submit that if it *cares*>about the difference in some meaningful >way, your code is wrong to do>so. Where am I going with all this?The overall idea is to keep a consistent behavior for what a container should do, let say, in the Algebraic sense i.eOne action on the container means the same action on all of its elements. And if we need to rename well established things then let that be. For example, if you analyze what the literature conveys about what a moved-from object means, you will find something similar to the following:"A moved from abject is in undefined but valid state, and the only operations allowed are assignment or destruction"Given the above... then i can assume that : vec[idx] = val ; // where vec is a moved-from vector, and idx < vec.size() before move ops. Is a well defined operation...since i just assigned a value to a moved-from element of a moved-from container, as per the definition above.But in reality, that's an undefined behaviour. So what the literature describes as 'undefined but valid stat', is in itself unclear and bears many meanings. Which adds to burden of the C++ language, which is already full of those fuzzy constructs.> 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.>You aren't supposed to be able to tell from within the code; that's on>you to pay attention to. That's why >dereferencing a point to an object>past its lifetime is UB instead of ill-formed. >You have the>responsibility to know what you're doing if >you're playing with raw>pointers. Yes i know Jason.This question was meant to trigger some brainstorming debate...unfortunately other people responding to this thread, give the sentiment that they are happy with the current state of the language, and any question that would trigger innovation is silly....that's Ok for me no problem at all. -- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>You can create a container, which applies >certain operations (like copy, move, >empty) on all of its contained objects.It would be more intuitive to have this as the default. ///vec(const vec&) ;// copy each elemvec(vec&&);// move each elemvec& operator =(const vec&);//assignment by copy construction or copy assign each elemvec& operator =(vec&&);// assignment by move construction or move assign each elemvoid clear();//destroy each elem///The common behavior is that after each operation the source container, still have the same capacity and size, and the internal pointer to the heap is still valid (!= nullptr). Except for clear() where size =0;In this scenario, the moved-from state of the container could be delegated to its elements, given a conventional protocol...for expl, if we agree that we never move individually any element , then it is safe to test if the container is moved-from by delegating to one of its element i.evec.is_moved_from() <=> vec[idx].is_moved_from();//idx < vec.size()>You can create a container, which allows >all or more operations (including >is_moved_from()) in its moved from state. >What the standard specifies, is a minimum for the classes to follow. Even the >standard library containers are allowed >to do more than the minimum for a >specific implementation.The minimum should be the default and the correct behavior,.Specializing the behavior must be for real special cases.>A more 'extreme' variant of movement is >relocation.>Perhaps in all or at least most cases, >the program could (in theory in the >future) statically at compile-time test, >whether a variable was relocated. Or >alternatively it is possible to reuse the >name after relocation.>A relocated object has no moved from >state, but cannot be accessed at all.In my little side research, i found that the concept of 'borrow checker' and 'pointer provenance' combined must be a compiler only concept i.e as a user you cannot introduce them into your code, but the compiler use them to check for correctness, static analysis and function overload.Right now, i don't have a full view of how this should be done, but i started this thread from the same start point which lead me to the above observation.I assumed it will lead everyone here to the same result, and i was interested to see how everyone will tackle it..... well not everything we assume will happen :|Anyway...Thanks all for your feedback.End of thread. -----Ursprüngliche Nachricht-----Von: organicoman via Std-Proposals <std-proposals_at_[hidden]>Gesendet: So 26.10.2025 16:05Betreff: Re: [std-proposals] Consistent behavior on Container actionsAn: Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>; CC: organicoman <organicoman_at_[hidden]>; body { font-family: monospace; } On Fri, Oct 24, 2025 at 10:54 PM organicoman via Std-Proposals<std-proposals_at_[hidden]> wrote:>>>> 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.>Does it impose anything, though? Yes Jason, if for example the growth factor of the implementation is different, the side effects will be different. >What implementation details does code*need to know* about this? Some examples would be, growth factor, ×2? ×1.5?....what optimization used for trivially copyable value_type... 'noexcept' aware code...etc >When would it actually *matter* to theuser, and why? Local reasoning...- I expect copy assignment, then i see mixture of copy assignment/construction...why?- Test case implementation. If your only way is to test against a text string.And other reasons not on top of my head right now. In my little research I'm doing right now, I found that move operations are missing something A move operation should allow to be tested against.... vec.is_moved_from(); Should yield 'true' or 'false'.Which is not the case in the current state of the language.>Copy assignment and copy construction fundamentally should yield thesame result: two objects with equal values. No >code should *care* if>this is accomplished by constructing a new >object or assigning into an>existing one; the result ought to be the same. >That's what "copy">means, and if your code cares about the >difference, then I would>suggest that its idea of what "copy" means is >incorrect.>The same goes for movement, but even >moreso (and that's ignoring the>issue everyone else brought up about how >moving in containers ought to>work).>Your code can tell the difference. But I >submit that if it *cares*>about the difference in some meaningful >way, your code is wrong to do>so. Where am I going with all this?The overall idea is to keep a consistent behavior for what a container should do, let say, in the Algebraic sense i.eOne action on the container means the same action on all of its elements. And if we need to rename well established things then let that be. For example, if you analyze what the literature conveys about what a moved-from object means, you will find something similar to the following:"A moved from abject is in undefined but valid state, and the only operations allowed are assignment or destruction"Given the above... then i can assume that : vec[idx] = val ; // where vec is a moved-from vector, and idx < vec.size() before move ops. Is a well defined operation...since i just assigned a value to a moved-from element of a moved-from container, as per the definition above.But in reality, that's an undefined behaviour. So what the literature describes as 'undefined but valid stat', is in itself unclear and bears many meanings. Which adds to burden of the C++ language, which is already full of those fuzzy constructs.> 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.>You aren't supposed to be able to tell from within the code; that's on>you to pay attention to. That's why >dereferencing a point to an object>past its lifetime is UB instead of ill-formed. >You have the>responsibility to know what you're doing if >you're playing with raw>pointers. Yes i know Jason.This question was meant to trigger some brainstorming debate...unfortunately other people responding to this thread, give the sentiment that they are happy with the current state of the language, and any question that would trigger innovation is silly....that's Ok for me no problem at all. -- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-10-26 17:00:29