Re: Optimizing C++ Move Functions in Stl

[Jonathan Wakely <jwakely at redhat dot com>]

On 10/12/18 16:09 -0500, nick wrote:
> Greetings All,
>
> Sorry I was busy last week but did get my forms signed off for the
> required copyright assignment. Anyhow seems that the tuple and other
> classes mentioned aren't the only only ones that could do noexpect
> optimization either for all cases or some in the header files.
>
> I am proposing that I sent either a patch series or a patch per class
> that actually could use this extension of the standard including the
> string class I believe.
>
> Not sure if this is a good idea but have opening it from discussion
> for what classes should this touch in the std helper files,

We'll consider any patches that add noexcept appropriately.

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.