C++ no except updates

[nick]

On 2019-05-07 3:42 p.m., Jonathan Wakely wrote:
> On 07/05/19 12:48 -0400, nick wrote:
>>
>>
>> On 2019-05-07 5:45 a.m., Jonathan Wakely wrote:
>>> Removing the gcc@ list, as there's no need to cross-post this to two
>>> lists.
>>>
>>>
>>> On 07/05/19 00:17 -0400, nick wrote:
>>>> Jonathan,
>>>>
>>>> I don't know what work is remaining in my ideas with inlining r value functions as you
>>>
>>> I don't know what work you're referring to.
>>>
>> If I recall that was done with the C++20 filesystem and perhaps new networking
>> classes. You sent a patch to the list if I recall.
>>
>>> If you mean https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02618.html
>>> then that patch was simply wrong, and not needed.
>>>
>>>> seemed to have already taken up and probably finished my ideas from reading the list.
>>>> If you want help finishing it just send me a ToDO of since C++11 and C++20 classes have
>>>> not been made noexcept for the move constructor and assignment operator.
>>>
>>> I'm not going to perform such an audit for you. The types I'm aware of
>>> that have potentially throwing moves are like that for a reason, and
>>> need to stay that way.
>>>
>>>
>> No of course not this was your actually wording,
>>
>> We'll consider any patches that add noexcept appropriately.
> 
> Ah so that's the thread you're talking about. You said:
> 
> "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."
> 
> It's hard to know what your "ideas with inlining r value functions"
> are from this, it's a bit vague.
> 

While noexcept really has two reasons to be used normally. The first in
giving the compiler the ability to inline and remove the catch parts
of functions. Actually if you don't do it and call this will throw
std::terminate as you know, that's part of the standard to my knowledge.
Therefore adding it inlines or removes the required std::terminate
catch block which most compilers than just inline itself.

The second is that removes ad hoc code with the default catch block added
by compilers as part of the spec. As you mentioned this seems to be only
for constructors or move operators which makes the most sense as those
are harder to remove try/catch defaults for in compiler optimization.

As for my papers those were signed off as Ville asked. 


Again maybe the compiler proper is doing more these days but that's from
my memory of the standard and hopefully it's a little clearer now,

Nick
> The following revisions added noexcept in the past few months:
> r270632, r270501, r270175, r270173, r268713, r267865, r267235, r267106
> 
> If you think it should be added elsewhere please send patches.
> 
>