Optimizing C++ Move Functions in Stl

[nick]

On 2018-12-12 9:00 a.m., Ville Voutilainen wrote:
> 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.
> 


Yes that's true. I was also asking about is there a TODO list for the current release
of gcc 9 as Jonathan mentioned this work is a stage 1 fix or feature and should wait
until gcc 10 stage 1 so was wondering what work is needed in the current stage 3.

Sorry for the confusion with the previous email and hopefully this makes more sense,

Nick