https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87106
--- Comment #7 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
> std::string is not trivially relocatable in libstdc++
This is surprising news to me! Just goes to show that we would benefit from an
accurate detection mechanism and type trait. :)
> so I won't waste any time there. IIRC, one difference with what you did is
> that I use relocation even for some types that are not trivially relocatable
> (in particular std::string)
...but which are is_nothrow_relocatable. Right. This is a good point in the
direction of maybe keeping is_nothrow_relocatable in P1144. I was thinking that
maybe it was pointless and should be removed until a use-case is found for it.
Now I'm even more unsure.
> 2) the conditionally trivial stuff is not very convenient, it seems to
> involve a lot of code duplication. People regularly suggest attributes of the
> form [[trivially_relocatable(condition)]] which might reduce the noise but
> are harder to specify.
Agreed on all counts. Particularly for this attribute, I worry that the common
use-case would be something really ugly like
template<class T, class A>
class [[trivially_relocatable(
is_trivially_relocatable_v<A> &&
is_trivially_relocatable_v<typename allocator_traits<A>::pointer>
)]] vector {
};
which I hope you'd agree would be even more ridiculous than the current
metaprogramming/duplication. And then on top of that, parsing an attribute-list
would become as hard as parsing all of C++, which I don't think we want.
> 4) ... Relocating a pair<A,B> where A is trivially relocatable and B is not
> can still benefit from doing piecewise relocations so it avoids A's
> super-costly move constructor.
Hmm, I see what you mean, and that is a relevant and novel point AFAIC. The
judo dodge for P1144 here is to point out that if today we provide a way to
warrant/detect *trivial* relocation, well, that is not incompatible with
providing a way to *customize* relocation tomorrow. We just need to agree that
relocation ought to be "tantamount to" a move plus a destroy.
> Ideally relocation would be a constructor or something similarly magic and
> the compiler would auto-generate it for aggregates, etc. But I am asking a
> bit much there...
Yes, Denis Bider's P0023 "Relocator"
http://open-std.org/JTC1/SC22/WG21/docs/papers/2016/p0023r0.pdf
went that route, and I think it was not well received -- or possibly just not
discussed at all, I'm not sure.
Thanks for the comments and the nice work!
