C++ no except updates

[Jonathan Wakely]

On Wed, 8 May 2019 at 13:05, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> On Wed, 8 May 2019 at 05:59, nick <xerofoify@gmail.com> wrote:
> >
> >
> >
> > 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.
>
> I can't parse this last sentence.
>
> > 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.
>
> I don't know what "the default catch block" is, but this second reason
> seems to be the same as the first.
>
> > 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,
>
> Please read what I said in
> https://gcc.gnu.org/ml/libstdc++/2018-12/msg00021.html again.
>
> "The compiler can already see that most inline functions can't throw,
> and so can already optimize accordingly."
>
> Adding 'noexcept' doesn't usually make any difference for optimization purposes.
>
> The primary advantage of adding it is just to benefit user code (or
> other libstdc++ code) that might want to query whether something can
> throw, in order to take a different code path when nothing can throw.
> If functions in our implementation guarantee not to throw, even though
> the standard says they are potentially-throwing, then we might as well
> add noexcept to make that guarantee statically testable. But that's
> not to help the compiler optimize better. It's just to use C++ to
> express a guarantee, instead of using comments or documentation.

Instead of any further discussions about 'noexcept' I'm going to
repeat what I said yesterday:
If you think it should be added elsewhere please send patches.