On 3/16/25 16:40, Giuseppe D'Angelo via Std-Discussion wrote:
> On 16/03/2025 13:46, Ell via Std-Discussion wrote:
>>
>> On 3/13/25 20:36, Giuseppe D'Angelo via Std-Discussion wrote:
> Yes, one could also refine the replacement operation with "... assuming
> the move constructor doesn't throw" or something like that.

That makes replacement a non-standalone operation -- you have to
eliminate the move constructor somehow -- since you can't *actually*
make this assumption. Which maybe is cool, it's definitely enough for
trivial relocation. I got the impression the paper was going for it
being independent.
> Again, the point is to signal a container that it _can_ replace move
> assignments with destructions+move constructions. The container doesn't
> _have to_ do such a thing, especially if move assignments are nothrow
> and replacements are throwing.

I get it, it's just pedantry :)

> Concretely speaking I'd expect an implementation of vector<T>::erase /
> insert/emplace/... to have a decision tree like this:
>
>
> 1) Is T replaceable? If not, keep doing move assignments.
>
> T may even be trivially relocatable. However an implementation may not
> be willing to change its current implementation from move assignments to
> a (trivial-)relocation-based approach, because it changes the behavior
> of existing code.
>
> (Aside: if we're talking about std::vector specifically, it may not even
> be *authorized* to do so by the container requirements, which still say
> things like "the assignment operator of T is called the number of times
> equal to the number of elements in the vector after the erased elements"
> https://eel.is/c++draft/vector#modifiers-5 or similar.
>
> Despite a lot of discussions it is still very much unclear whether
> "equal to" is a literal "equal to" or it's an upper bound as per
> https://eel.is/c++draft/structure.specifications#7 , so doing 0
> assignments is fine. While the Standard is not a tutorial, saying "equal
> to" but meaning "up to" sounds *very* misleading IMHO.)
Especially since that paragraph has two "equal to"s, and one of them
(number of destructor calls) would be a lower bound...

> 2) Otherwise, T is replaceable.
>
> 2a) Is T trivially relocatable? Then do trivial relocation.
>
> 2b) Is T nothrow relocatable? Then do relocation (maybe).
>
> 2c) Otherwise: keep doing move assignments. The idea here is that either
> move assignments don't throw (for instance a non-TR std::list that
> allocates the sentinel node); or, if they do, you have optimized your
> type already for this use case as this is the current behavior from
> containers. For instance, you may prefer a result where a throwing move
> assignment thrown during erase/insert/... leaves "something" behind for
> you, whereas a throwing relocation would wipe out all the affected elements.
>
>
> 2b at the moment is still a bit of a question mark. There are certainly
> some types that are nothrow relocatable but not trivially relocatable
> (for instance a std::string with SSO which contains a pointer into
> itself). The question is whether move assignments would be faster than
> destroy+move construct for these types. In the experiments I've run the
> answer seems to be yes (e.g. libstdc++ string gives anywhere between 10%
> and 50% speedup), but that's far from a universal metric.

Nontrivial-relocation would be nice here. I actually did some simple
tests with libstdc++ vector<string> that suggested there's performance
gains to be had.

> In any case,
> if you're fine with it, then 2a+2b can be handled together by the
> uninitialized relocation algorithms proposed by P3516, covered by a "is
> T nothrow relocatable" guard.
>
>
> My 2 c,
>
>