Re: Optimizing C++ Move Functions in Stl

[Ville Voutilainen <ville dot voutilainen at gmail dot com>]

On Wed, 12 Dec 2018 at 14:59, Jonathan Wakely <jwakely@redhat.com> wrote:
> >> It's not always worth doing though. For constructors it can matter,
> >> because it can affect the result of the is_nothrow_xxx_constructible
> >> traits, which can cause different code paths to be taken elsewhere in
> >> the library. For arbitrary member functions it doesn't usually make a
> >> difference. The compiler can already see that most inline functions
> >> can't throw, and so can already optimize accordingly.
> >>
> >> I suggest a series of patches, split along sensible lines (i.e. don't
> >> propose changes to unrelated types like std::basic_string and
> >> std::atomic in the same patch, which is always good advice anyway).
> >>
> >> Be aware that GCC is in Stage 3 of its development cycle, and changes
> >> like this which do not fix any bugs are probably going to have to wait
> >> for the next Stage 1. See https://gcc.gnu.org/develop.html#stage1 for
> >> more information.
> >>
> >>
> >
> >Sorry for keeping this thread open. The only nit about your above comments related
> >to the inlining from assignment operators always is in the same boat if I understand
> >you then. This is probably the only member operator exception but it's basically
> >a constructor that returns something into another object so that's why.
>
> If there's a question here, I can't parse it, sorry.

I think there's an attempt to ascertain that mostly constructors and
assignment operators need noexcept-fixes,
because that noexcept-ness is directly trait-detectable.
That would match my current understanding of the situation for at
least pair and tuple.