C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Defined STL containers moved-from state

From: Bo Persson <bo_at_[hidden]>
Date: Wed, 22 Jan 2025 18:22:08 +0100
On 2025-01-22 at 18:17, Gia Phan via Std-Proposals wrote:
> That's what I was thinking, it's hard to predict the output of some
> program given that the only guarantee is "valid but unspecified" state.
> I know basically no implementation does such thing, but if they do,
> there is really no way to know if it's safe or not. In my opinion, we
> should have some guarantee saying which operation will and will not work

But we do - all operations without preconditions. And that is only
because you don't know the state - the string might be empty, or it
might not.

So you can perform any operation that doesn't care, like assigning a new
known value. You cannot erase a character in the middle, because you
don't know if there is one.



>
> On Wed, Jan 22, 2025 at 8:30 AM Ivan Matek via Std-Proposals <std-
> proposals_at_[hidden] <mailto:std-proposals_at_[hidden]>> wrote:
>
>
>
> On Wed, Jan 22, 2025 at 5:23 PM Ville Voutilainen via Std-Proposals
> <std-proposals_at_[hidden] <mailto:std-
> proposals_at_[hidden]>> wrote:
>
> On Wed, 22 Jan 2025 at 18:16, Gia Phan via Std-Proposals
>
>
> > For example, assignment and destruction are obvious, but what
> about something like resize(), reserve()? Shouldn't we have some
> clearly defined behavior?
>
> We do.
>
>
> I guess this depends on what you mean by "clearly defined". I
> believe result of this program is not clearly defined as in we know
> what it will output:
> int main()
> {
> std::string s{"abc"};
> auto s2 = std::move(s);
> s.resize(5,'x');
> std::print("{}",s);
> }
> (and that is intentional, since in theory because of SSO it is
> faster to leave source of move unmodified, although no
> implementation does that).
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals>
>
>

Received on 2025-01-22 17:22:13