Optimizing C++ Move Functions in Stl
Jonathan Wakely
jwakely@redhat.com
Wed Dec 12 12:59:00 GMT 2018
On 11/12/18 19:36 -0500, nick wrote:
>
>
>On 2018-12-11 8:37 a.m., Jonathan Wakely wrote:
>> 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.
>>
>>
>
>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.
More information about the Libstdc++
mailing list