C++ no except updates

Jonathan Wakely jwakely.gcc@gmail.com
Wed May 8 12:05:00 GMT 2019


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.



More information about the Libstdc++ mailing list