https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #11 from Marc Glisse <glisse at gcc dot gnu.org> --- (In reply to Arthur O'Dwyer from comment #10) > Here's the commit where I trivially-relocatable-ized `std::deque`. 34 lines > added, 18 more lines changed. There's some duplication, but it's not > literally "duplicating the whole class." Indeed. It requires defaulting some methods in the outer class. And it requires some artificial base classes, something I've been fighting against with [[unique_address]]. But it looks doable... > > I was looking into using relocation in std::swap. ... Maybe types that are > > trivially relocatable but not trivially movable and destructible? Or just > > non-trivial? > > My commit for `std::swap` is here: > https://github.com/Quuxplusone/libcxx/commit/ > 4d89aa95a7da86d1671d3e4441967782399fc3f9#diff- > d436eb0fd9de10b54a828ce6435f7e81 > It's extremely naive. I just say, if the type is_trivially_relocatable, then > we use memcpy --- EXCEPT, if the type is_empty, then we should NOT use > memcpy, because that is highly likely to break real code. > https://quuxplusone.github.io/blog/2018/07/13/trivially-copyable-corner- > cases/ Those are real pre-existing problems. As long as we deal with vector<T>, we know that T is the real type so we are safe. But indeed for one-element functions like swap it is more dangerous. I was considering not just cases that are dangerous, but also cases (like int) that are safe but where memcpy might hinder some optimizations using tbaa. > I'm not sure I follow. Are you relying on the premise that move-constructing > an object, and then destructing a moved-from object, is more expensive than > move-assigning into a moved-from object? I would expect move-assigning to be > *no cheaper* than move-constructing, and so constructing and destructing a > new temporary for each element ought to be *no more expensive* (and possibly > cheaper) than reusing the same one. For a type that always has some memory allocated, say std::list in visual studio, constructing+destructing means allocating and deallocating a sentinel, which can be skipped when assigning.
