On Thu, Jul 17, 2025 at 10:39 PM Jonathan Wakely <jwak...@redhat.com> wrote:
> On 17/07/25 15:23 -0400, Patrick Palka wrote:
> >On Thu, 17 Jul 2025, Tomasz Kamiński wrote:
> >> + constexpr inplace_vector&
> >> + operator=(const inplace_vector& __other)
> >> + noexcept(is_nothrow_copy_assignable_v<_Tp>
> >> + && is_nothrow_copy_constructible_v<_Tp>)
> >> + {
> >> + assign(__other.begin(), __other.end());
> >
> >Do we need to worry about self-assignment here? IIUC it's a
> >precondition violation to call assign with an iterator into the
> >container being assigned to. LGTM other than that.
>
> Good question. It will actually work fine for self-assignment; we
> don't enforce the precondition. We'll just loop over the elements and
> do self-assignment for each one. That's wasteful, but not wrong
> (assuming the elements themselves are safe for self-assignment).
>
> It would be more efficient to not do that loop though, and the check
> for `if (addressof(__other) == this)` can be marked [[unlikely]].
>
I was going to mention that this will make a self-assigment for non-trivial
types
faster than one for trivial types (where we copy bytes). But this is
already the case
for empty inplace vector. Will add this check to both assignments.
