Skip to content

<flat_meow>: Should move constructors use the extract() && member function? #5991

@vmichal

Description

@vmichal

Followup to the discussion of @StephanTLavavej and @AlexGuteniev at https://discord.com/channels/737189251069771789/1120873380615295027/1449085881079169194
with goal of clarifying the decision

"If we change flat_set's move assign to use extract() like flat_map does, libcxx\test\std\containers\container.adaptors\flat.multiset\flat.multiset.cons\move_assign.pass.cpp fails because they have a squirrelly container that has (implicitly) deleted copy/move ctors. I think this fails the sequence container requirements so the test is bogus." We could leave this as-is, but it might be worth investigating upstream.

In my humble opinion, using extract is not desirable. The pattern _STD move(_Other).extract(); seems reasonable when constructing a new object due to guaranteed copy elision, but it constructs an unnecessary temporary when used in operator=. Although extract() elegantly solves the self-assignment problem, I believe if (this != _STD addressof(_Other)) is not worse.

A minimal example for experiments https://godbolt.org/z/7744YMxGb shows the difference between the two implementations.

I have speculatively implemented the fix in #5990, among other things. I wanted to revisit this question to clarify the chosen solution.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementSomething can be improvedfixedSomething works now, yay!flat_meowC++23 container adaptors

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions