Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Summary of C++0x Feature Availability

196 views
Skip to first unread message

Scott Meyers

unread,
Mar 7, 2010, 10:38:05 PM3/7/10
to
Participants in this newsgroup for the past many months will likely
have noticed my postings asking about details related to various C++0x
features. My primary motivation was to learn enough about C++0x to be
able to explain it to other people, but along the way I put together a
summary of C++0x support in gcc and MSVC, and I think this summary may
be useful to others. It's now available at
http://www.aristeia.com/C++0x/C++0xFeatureAvailability.htm .

Both C++0x and compiler support for it are moving targets, so the
information in the summary will get out of date over time, and of
course there may be errors in the summary as it stands now. My goal
is to keep the summary both accurate and up to date, so if you see
anything that needs improvement, please let me know:
sme...@aristeia.com.

Thanks,

Scott

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]

REH

unread,
Mar 10, 2010, 9:48:10 PM3/10/10
to
On Mar 7, 10:38 pm, Scott Meyers <NeverR...@aristeia.com> wrote:
> Participants in this newsgroup for the past many months will likely
> have noticed my postings asking about details related to various C++0x
> features. My primary motivation was to learn enough about C++0x to be
> able to explain it to other people, but along the way I put together a
> summary of C++0x support in gcc and MSVC, and I think this summary may
> be useful to others. It's now available athttp://www.aristeia.com/C++0x/C++0xFeatureAvailability.htm.
>
> Both C++0x and compiler support for it are moving targets, so the
> information in the summary will get out of date over time, and of
> course there may be errors in the summary as it stands now. My goal
> is to keep the summary both accurate and up to date, so if you see
> anything that needs improvement, please let me know:
> smey...@aristeia.com.
>

Scott, not to hijack your thread, but I was just wondering. Do you
have any plans to update your awesome "effective" books when the new
standard becomes ubiquitous?

REH

Scott Meyers

unread,
Mar 12, 2010, 3:07:58 AM3/12/10
to
REH wrote:
>
> Scott, not to hijack your thread, but I was just wondering. Do you
> have any plans to update your awesome "effective" books when the new
> standard becomes ubiquitous?

There's no specific plan, but one never knows what will happen. I
have something related to C++0x in the works, but it's not a
traditional "Effective" book. When there's more to say, I'll announce
it to my mailing list and, if the moderators approve, here, too.

Scott

Marco

unread,
Mar 21, 2010, 1:58:53 PM3/21/10
to
On Mar 7, 8:38 pm, Scott Meyers <NeverR...@aristeia.com> wrote:

> Both C++0x and compiler support for it are moving targets,

What is the current best guestimate for the next ISO C++ standard?
(obviously it missed 0x)

Scott Meyers

unread,
Mar 23, 2010, 5:35:28 AM3/23/10
to
Marco wrote:
>
> What is the current best guestimate for the next ISO C++ standard?

Per http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/
, its 2011.

Scott

Stefanus Du Toit

unread,
Mar 23, 2010, 5:35:32 AM3/23/10
to
On Mar 21, 1:58 pm, Marco <prenom_no...@yahoo.com> wrote:
> What is the current best guestimate for the next ISO C++ standard?
> (obviously it missed 0x)

If all goes well, 2011:

http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/

Stefanus

Balog Pal

unread,
Mar 23, 2010, 5:35:31 AM3/23/10
to
"Marco" <prenom...@yahoo.com>

>
> What is the current best guestimate for the next ISO C++ standard?
> (obviously it missed 0x)

2011. The final committee draft was finished like a week ago. Guess
the papers will appear in another 2-3 weeks on the wg21 site.

Herb Sutter

unread,
Mar 23, 2010, 6:05:27 AM3/23/10
to
On Sun, 21 Mar 2010 11:58:53 CST, Marco <prenom...@yahoo.com>
wrote:

> What is the current best guestimate for the next ISO C++ standard?
> (obviously it missed 0x)

Possibly C++11, if no untoward surprises happen.

For more, see my trip report a week ago at
http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-
c-standards-meeting/

(Tiny: http://tinyurl.com/yz9r9ay .)

Herb


---
Herb Sutter (herbsutter.wordpress.com) (www.gotw.ca)

Convener, SC22/WG21 (C++) (www.gotw.ca/iso)
Architect, Visual C++ (www.gotw.ca/microsoft)

Pete Becker

unread,
Mar 24, 2010, 7:51:23 AM3/24/10
to
Balog Pal wrote:
>
> "Marco" <prenom...@yahoo.com>
>>
>> What is the current best guestimate for the next ISO C++ standard?
>> (obviously it missed 0x)
>
> 2011. The final committee draft was finished like a week ago.

Huh. I guess I've been wearing myself out for two weeks over nothing,
trying to finish the FCD. <g>

The technical decisions were all made at the Pittsburgh meeting, with
the final votes on Mar. 13. But there's still a lot of work going on,
integrating the changes, checking that they're right (I haven't
counted yet, but there are about two dozen people who have reviewed
various stages of the new document), preparing the document itself,
and preparing a Record of Response to the National Body comments that
came out of the previous CD. After all that, the documents themselves
(the FCD and the RoR) go to ISO for publication and balloting. And
then we get to go through NB comments yet again...

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)

Alexander Terekhov

unread,
Mar 27, 2010, 2:40:58 PM3/27/10
to

Herb Sutter wrote:
[...]
> (Tiny: http://tinyurl.com/yz9r9ay .)

"There was general (but not universal) agreement that the program should
not be allowed to continue executing if a noexcept is violated because
in that case the program will almost certainly be in a corrupt state,
and so the consensus was in favor of guaranteeing to call terminate()
instead of allowing arbitrary undefined behavior, but it’s possible that
a comfortable middle ground between those two options may yet be found.
"

Is it kind of like extending the structure of frogs so they have wings
and thus don't bump their a....? C'mon, an unexpected throw shall
terminate() at throw point without any unwinding!

regards,
alexander.

Steve Clamage

unread,
Mar 29, 2010, 3:01:03 PM3/29/10
to
On Sat, 27 Mar 2010 12:40:58 CST, Alexander Terekhov <tere...@web.de>
wrote:

>
>Herb Sutter wrote:
>[...]
>> (Tiny: http://tinyurl.com/yz9r9ay .)
>
>"There was general (but not universal) agreement that the program should
>not be allowed to continue executing ...

>
>Is it kind of like extending the structure of frogs so they have wings
>and thus don't bump their a....? C'mon, an unexpected throw shall
>terminate() at throw point without any unwinding!

There is room for more than one opinion on this topic. See the
discussion following Herb's blog posting:
http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/

Herb Sutter

unread,
Mar 30, 2010, 12:50:28 PM3/30/10
to
On Mon, 29 Mar 2010 13:01:03 CST, Steve Clamage
<stephen...@sun.com> wrote:
>On Sat, 27 Mar 2010 12:40:58 CST, Alexander Terekhov <tere...@web.de> wrote:
>>Herb Sutter wrote:
>>> (Tiny: http://tinyurl.com/yz9r9ay .)
>>"There was general (but not universal) agreement that the program should
>>not be allowed to continue executing ...

To summarize, the main two points of view that were expressed were
that that trying to propagate an exception out of a noexcept function
should result in:

a) All bets off: Undefined behavior, no guarantees at all, including
that the program may try to continue executing in a corrupted state.
In particular, destructors might or might not be run, and caller and
callee optimizations might have been made that assume this could never
happen and could result in anything up to and including hard drive
formatting (less likely) and random code execution (more likely, and
possibly exploitable).

b) Termination: Like (a), except replace "the program may try to
continue executing in a corrupt state" with "terminate will be called
so that execution will not continue in the caller." The other badness
is possible but constrained to between the throw point and the
noexcept point, and we take down the process (intended to be at
debug/test time).

The committee has currently penciled in (b). To implement this, it's
sufficient to have one bit on the stack frame of the noexcept, and a
single "if( flag_noexcept && propagating_an_exception
call_terminate()" which results in near-zero overhead in the case when
the noexcept is not violated.

The following, however, is a new proposal that would be far stricter
than any proposal I've seen debated:

>>[...] C'mon, an unexpected throw shall


>>terminate() at throw point without any unwinding!

Hmm. At first blush, there seem to be at least two difficulties with
this.

First, like throw(), it seems to prevent callee optimizations. In
particular, noexcept enables optimizations not only in the caller but
also in the callees, so that the optimizer can assume that functions
called in a noexcept function and not wrapped in a try/catch are
themselves noexcept without being declared such (e.g., C standard
library functions are not so annotated). Requiring terminate to be
called deterministically at exactly the throw point in the code
inhibits the ability to optimize callees, including desirable loop
optimizations like loop interchange and vectorization that can change
the order in which elements are processed.

Seconed, it doesn't seem to be efficiently implementable. How would
you implement your rule? For example, what about:

void f() noexcept { // line A
...
X x;
...
{
...
Y y;
...
throw "hahaha"; // line B
...
}
...
}

Q: In your suggestion, at line B, what should happen? Should the
program terminate? Or should the destructor of Y be run? Or should the
destructors of Y and X be run?

A: In your suggestion, it would depend on whether any (and which) of
the "..." lines contains a catch that would absorb the thrown
exception.

And how will you determine that? Remember that line B may be deep
inside some (possibly-nested) third-party library call, and lines A
and B authored by different people and linked together in object form
only (again, possibly nested with ten other libraries authored by ten
other companies in between them).

Are you suggesting the implementation be required to traverse the
stack to look for a noexcept and along the way inspect all handlers
above it in the call chain and see whether any catch handler might
catch this exception... for every throw-statement in the program? (I'm
assuming that you don't want to additionally then look inside the
handler to see whether the handler re-throws this exception or throws
a new exception, and if so rinse-and-repeat all the way up to the
noexcept -- just terminate on the "last" exception throw/re-throw that
would violate the noexcept.)

>There is room for more than one opinion on this topic. See the
>discussion following Herb's blog posting:
>http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/

Herb

Convener, SC22/WG21 (C++) (www.gotw.ca/iso)
Architect, Visual C++ (www.gotw.ca/microsoft)

--

Alexander Terekhov

unread,
Mar 31, 2010, 8:11:46 PM3/31/10
to

Herb Sutter wrote:
[...]

> Are you suggesting the implementation be required to traverse the
> stack to look for a noexcept . . .

Yes, in effect, the implementation shall be required to traverse the
stack to look for a noexcept (manifesting lack of exception handler) and
call terminate() at throw point (without any unwinding) if it finds
noexcept (or finds no matching exception handler). It's a two phase
process: first phase is searching the stack and the second one is
calling the cleanup *if* matching handler is found.

regards,
alexander.

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use

mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>

Martin B.

unread,
Mar 31, 2010, 8:11:10 PM3/31/10
to
Herb Sutter wrote:

> On Mon, 29 Mar 2010 13:01:03 CST, Steve Clamage
> <stephen...@sun.com> wrote:
>
>> On Sat, 27 Mar 2010 12:40:58 CST, Alexander Terekhov <tere...@web.de>
>> wrote:
>>
>>> Herb Sutter wrote:
>>>
>>>> (Tiny: http://tinyurl.com/yz9r9ay .)
>>>>
>>> "There was general (but not universal) agreement that the program should
>>> not be allowed to continue executing ...
>>>
>>
> To summarize, the main two points of view that were expressed were
> that that trying to propagate an exception out of a noexcept function
> should result in:
>

> a) All bets off: (...)


>
> b) Termination: Like (a), except replace "the program may try to
> continue executing in a corrupt state" with "terminate will be called
> so that execution will not continue in the caller." The other badness
> is possible but constrained to between the throw point and the
> noexcept point, and we take down the process (intended to be at
> debug/test time).
>
> The committee has currently penciled in (b). To implement this, it's
> sufficient to have one bit on the stack frame of the noexcept, and a
> single "if( flag_noexcept && propagating_an_exception
> call_terminate()" which results in near-zero overhead in the case when
> the noexcept is not violated.
>
>

Note that I'm pretty sure I do not understand this. :-) Especially in how
it's different from throw().

The following, however, is a new proposal that would be far stricter
> than any proposal I've seen debated:
>
> [...] C'mon, an unexpected throw shall
>>> terminate() at throw point without any unwinding!
>>>
>>
> Hmm. At first blush, there seem to be at least two difficulties with
> this.
>
> First, like throw(), it seems to prevent callee optimizations. In
> particular, noexcept enables optimizations not only in the caller but
> also in the callees, so that the optimizer can assume that functions
> called in a noexcept function and not wrapped in a try/catch are
> themselves noexcept without being declared such (e.g., C standard

> library functions are not so annotated). (....)
>

The issue with noexcept==terminate()confuses me no end.
Can anybody explain (or provide some links to an explanation) how noexcept
would be different from throw() in terms of semantics and in terms of
performance/optimization??

Current situation:
throw() -> exception happens -> unexpected() is called (which probably will
terminate() the program)

New situation:
noexcept -> exception happens -> terminate() is called

=> /Me/ doesn't get it.

cheers,
Martin

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use

mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>

Jonathan de Boyne Pollard

unread,
Apr 1, 2010, 12:49:04 AM4/1/10
to
>
>
> To summarize, the main two points of view that were expressed were that that trying to propagate an exception out of a noexcept function should result in:
>
> a) All bets off: Undefined behavior [...]
>
> b) Termination: [...]

>
> The committee has currently penciled in (b).
>
Another choice that was suggested by some members of the BSI C++ Panel is:

c) implementation-defined behaviour

It's not undefined behaviour, but, equally, it's not as rigid as "the
program shall always terminate", either; which would satisfy those who
are (I am told) in the "option (b) is premature standardization" camp.

> In particular, noexcept enables optimizations not only in the caller but also in the callees, so that the optimizer can assume that functions called in a noexcept function and not wrapped in a try/catch are themselves noexcept without being declared such (e.g., C standard library functions are not so annotated).
>

That's not the way that other people are seeing this. Indeed, one
question that is doing the rounds is whether the two strchr()s in the
C++ library should be declared noexcept(true) in the text of the
standard.

Alexander Terekhov

unread,
Apr 1, 2010, 1:52:09 PM4/1/10
to

"Martin B." wrote:
[...]

> The issue with noexcept==terminate()confuses me no end.
> Can anybody explain (or provide some links to an explanation) how noexcept
> would be different from throw() in terms of semantics and in terms of
> performance/optimization??

throw() implies catch(...) and it mandates unwinding up to that
catch(...). The noexcept doesn't mandate unwinding. The issue is that it
doesn't mandate a two-phase exception-handling model. For details, see

http://www.codesourcery.com/public/cxx-abi/abi-eh.html

"A two-phase exception-handling model is not strictly necessary to
implement C++ language semantics, but it does provide some benefits. "

regards,
alexander.

Alexander Terekhov

unread,
Apr 1, 2010, 1:51:14 PM4/1/10
to

Jonathan de Boyne Pollard wrote:
[...]

> Another choice that was suggested by some members of the BSI C++ Panel is:
>
> c) implementation-defined behaviour
>
> It's not undefined behaviour, but, equally, it's not as rigid as "the
> program shall always terminate", either; which would satisfy those who
> are (I am told) in the "option (b) is premature standardization" camp.

A two-phase exception-handling model is decades old. It's time to
mandate it.

regards,
alexander.

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use

mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>

Herb Sutter

unread,
Apr 2, 2010, 2:06:54 AM4/2/10
to
On Wed, 31 Mar 2010 18:11:46 CST, Alexander Terekhov <tere...@web.de>
wrote:

>Herb Sutter wrote:
>[...]
>> Are you suggesting the implementation be required to traverse the
>> stack to look for a noexcept . . .
>
>Yes, in effect, the implementation shall be required to traverse the
>stack to look for a noexcept (manifesting lack of exception handler) and
>call terminate() at throw point (without any unwinding) if it finds
>noexcept (or finds no matching exception handler). It's a two phase
>process: first phase is searching the stack and the second one is
>calling the cleanup *if* matching handler is found.

And this would be required to be performed on every throw? By all
conforming compilers, up the call chain across an arbitrary number of
independently authored libraries?

Just curious, which implementations currently implement two-phase
exception handling?

Herb

Convener, SC22/WG21 (C++) (www.gotw.ca/iso)
Architect, Visual C++ (www.gotw.ca/microsoft)

--

Kazutoshi Satoda

unread,
Apr 2, 2010, 2:06:38 AM4/2/10
to
To summarize, the main two points of view that were expressed were
>> that that trying to propagate an exception out of a noexcept function
>> should result in:
>> a) All bets off: Undefined behavior [...]
>> b) Termination: [...]
>> The committee has currently penciled in (b).
>>
> Another choice that was suggested by some members of the BSI C++ Panel is:
> c) implementation-defined behaviour
>

How about static checking?

d) Render them ill-formed if possible (and terminate if not)

void may_throw() noexcept(false);

// ill-formed
void f0() noexcept { may_throw(); }
// well-formed but terminates at runtime if the exception was not caught
void f1() noexcept { try { may_throw(); } catch (int) {} }
// ill-formed
void f2() noexcept { try { may_throw(); } catch (int) { may_throw(); } }
// ill-formed
void f3() noexcept { try { may_throw(); } catch (int) {} may_throw(); }

Here, f0() can achieve zero-overhead. In f1(), compilers only have to
adds an implicit handler - catch (...) { std::terminate(); } - at the
end of explicit catch handlers. This behavior is same as the current
draft, but the overhead will be buried under the existing cost of
explicit handers.

I believe compilers can check this in the same way to implement the
operator noexcept(expr).

Within this way, throw() will work as a way to escape from this static
checking as needed to call old (having no exception specification)
library functions, as const_cast works for const correctness.


This may require huge amount of efforts to ensure that the standard
library functions and compiler generated functions are suitably
annotated with noexcept. But I think the new exception specification is
not worth adding unless it enables static checking, and I'm afraid of
that current draft (choice b) will make noexcept accused of
non-zero-overhead, as same as throw(), and to be another burden to
introduce static checking later.

--
k_satoda

Herb Sutter

unread,
Apr 2, 2010, 2:07:36 AM4/2/10
to
On Wed, 31 Mar 2010 18:11:10 CST, "Martin B." <0xCDC...@gmx.at>
wrote:

>The issue with noexcept==terminate()confuses me no end.
>Can anybody explain (or provide some links to an explanation) how noexcept
>would be different from throw() in terms of semantics and in terms of
>performance/optimization??

throw() requires stack unwinding and so (a) disables optimizing
callees and (on at least some compilers) zero-cost implementation when
an exception is not thrown. It also (potentially) allows continued
execution.

>Current situation:
>throw() -> exception happens ->

Here add:
stack unwinding ->

>unexpected() is called (which probably will
>terminate() the program)
>
>New situation:
>noexcept -> exception happens -> terminate() is called

Yes.

Herb

Convener, SC22/WG21 (C++) (www.gotw.ca/iso)
Architect, Visual C++ (www.gotw.ca/microsoft)

--

Herb Sutter

unread,
Apr 2, 2010, 1:37:55 PM4/2/10
to
On Fri, 2 Apr 2010 00:06:38 CST, Kazutoshi Satoda
<k_sa...@f2.dion.ne.jp> wrote:
>To summarize, the main two points of view that were expressed were
>>> that that trying to propagate an exception out of a noexcept function
>>> should result in:
>>> a) All bets off: Undefined behavior [...]
>>> b) Termination: [...]
>>> The committee has currently penciled in (b).
>>>
>> Another choice that was suggested by some members of the BSI C++ Panel
is:
>> c) implementation-defined behaviour
>>
>
>How about static checking?
>
>d) Render them ill-formed if possible (and terminate if not)

It looks like you posted this *just* after April 1 was over. :-)

But to give a serious answer, since the above is a frequently asked
question: The trouble with (d) is that then you get all the problems
Java gets with statically checked exceptions, such as that that scheme
doesn't work at all with templates (what exactly would you write?) and
even when it does work more often than not quickly devolves into the
meaningless "throw(exception)". As often as I hear a C++ programmer
wish their exception specifications had Java's static semantics, I
hear a Java programmer wish theirs had non-static semantics.

Herb

Convener, SC22/WG21 (C++) (www.gotw.ca/iso)
Architect, Visual C++ (www.gotw.ca/microsoft)

--

Scott Meyers

unread,
Apr 2, 2010, 8:01:55 PM4/2/10
to
Herb Sutter wrote:
> Just curious, which implementations currently implement two-phase
> exception handling?

FWIW, the following simple test, when compiled with both VC10 and gcc 4.4,
suggest that both these compiler do two-phase exception handling. In the code
below, no Talker destructors are called, presumably because the thrown
exception
is not caught anywhere. Add a try/catch in main, and all the Talker
destructors
are called with both compilers. This suggests that both implementations first
search the stack for a handler before invoking destructors.

Scott

#include <iostream>

struct Talker {
~Talker() { std::cout << "Destroying Talker\n"; }
};

void f3() { Talker t; throw 0; }
void f2() { Talker t; f3(); }
void f1() { Talker t; f2(); }
int main() { Talker t; f1(); }

Alexander Terekhov

unread,
Apr 4, 2010, 2:03:36 PM4/4/10
to

Herb Sutter wrote:
>
> On Wed, 31 Mar 2010 18:11:46 CST, Alexander Terekhov <tere...@web.de>
> wrote:
> >Herb Sutter wrote:
> >[...]
> >> Are you suggesting the implementation be required to traverse the
> >> stack to look for a noexcept . . .
> >
> >Yes, in effect, the implementation shall be required to traverse the
> >stack to look for a noexcept (manifesting lack of exception handler) and
> >call terminate() at throw point (without any unwinding) if it finds
> >noexcept (or finds no matching exception handler). It's a two phase
> >process: first phase is searching the stack and the second one is
> >calling the cleanup *if* matching handler is found.
>
> And this would be required to be performed on every throw? By all
> conforming compilers, up the call chain across an arbitrary number of
> independently authored libraries?

Yes, what is the problem?

>
> Just curious, which implementations currently implement two-phase
> exception handling?

Your favourite certainly does implement it. ;-)

I think that two-phase is the rule rather than the exception.

regards,
alexander.

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]

[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]

Kazutoshi Satoda

unread,
Apr 4, 2010, 2:04:30 PM4/4/10
to
Herb Sutter wrote:
>
> The trouble with (d) is that then you get all the problems
> Java gets with statically checked exceptions,

I re-read some articles about what was wrong with checked exceptions.
http://www.artima.com/intv/handcuffsP.html
http://googletesting.blogspot.com/2009/09/checked-exceptions-i-love-you-but-you.html
For all problems written there, I thought they won't be problems with
noexcept because noexcept is not the default and not written for
specific types.

> that scheme doesn't work at all with templates (what exactly would you
> write?)

Like this:

template <class T, class Allocator = allocator<T> >
class vector {
...
iterator erase(const_iterator position) noexcept(
has_nothrow_copy_constructor<T>::value &&
has_nothrow_move_constructor<T>::value &&
has_nothrow_copy_assign<T>::value &&
has_nothrow_move_assign<T>::value)

For vector::erase(), we have now the following specification.
Throws: Nothing unless an exception is thrown by the copy constructor,
move constructor, assignment operator, or move assignment operator
of T.
The above declaration looks very straightforward based on this
specification. It will give a compile error when erase() is called in a
noexcept(true) function with T which doesn't fulfill the above
conditions. That sounds fine and great.

> and even when it does work more often than not quickly devolves into the
> meaningless "throw(exception)".

I don't think this will be a problem in C++ since such
"throw(exception)" specification is the default (no exceptions
specification). This is very different situation than that in Java.

Programmers won't be forced to write exception specifications until they
write static exception specification for their own function, or they
pass a type for a template which has a static exception specification.

> As often as I hear a C++ programmer
> wish their exception specifications had Java's static semantics, I
> hear a Java programmer wish theirs had non-static semantics.

Static checking with noexcept is very different with Java's static
checking, in that is default or not, that is a type list or a binary.
I think the problem should be reconsidered separately, shouldn't it?

--
k_satoda

[ comp.std.c++ is moderated. To submit articles, try just posting with ]

[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]

Herb Sutter

unread,
Apr 5, 2010, 2:36:14 AM4/5/10
to
On Sun, 4 Apr 2010 12:04:30 CST, Kazutoshi Satoda
<k_sa...@f2.dion.ne.jp> wrote:
>Herb Sutter wrote:
>>
>> The trouble with (d) is that then you get all the problems
>> Java gets with statically checked exceptions,
>
>I re-read some articles about what was wrong with checked exceptions.
>http://www.artima.com/intv/handcuffsP.html
>
http://googletesting.blogspot.com/2009/09/checked-exceptions-i-love-you-but-you.html
>For all problems written there, I thought they won't be problems with
>noexcept because noexcept is not the default and not written for
>specific types.

It's true that Yes/No is a much simpler subset of SetOfTypes/None. But
it's still the same principle. The question is whether the great
reduction of possibilities makes the problem tractable.

It seems to me that there are some fundamental things here:

1. Static checking inherently defeats writing naturally
exception-neutral code which should be the default, because the
specifications have to be written explicitly to be useful (and this is
true whether the default is "throws nothing" or "throws anything").

2. Static checking is intrusive and viral from the bottom up and has
to be explicitly written to be useful (again, whether the default is
"throws nothing" or "throws anything").

3. Noexcept used "for correctness" is for only a very small set of
code, and its new use of "for performance" applies to general purpose
code but has to be very simple to write if it's to be used there.

Taking them in order:

Most code is supposed to be exception-neutral by design. The code
(below) that detects an error throw, the code (above) that can handle
an error catches, and the rest of the code is supposed to just stay
out of the way.

So the key problem inherent in any static checking is that it defeats
this model by being intrusive: For static checking to be useful it
requires all code to now declare and know under what circumstances
exceptions can be thrown through it (even if we don't require listing
the types of exceptions, as in Java). And it's not enough to say "in
C++ the default is 'throws something'" because that just means that
"in C++ the default is 'can't be called from a noexcept function'" if
we enforce static checking.

That's untenable in general, and it's why in Java most people quickly
end up with the useless-and-soul-destroying "throws Exception" that
defeats the purpose of checked exceptions in the first place and whose
moral equivalent here is the default nothrow(false). At least in C++
we'd devolve to the default which is easier to spell than "throws
Exception," but it still defeats the purpose of static checking. And
of course it's particularly hard in generic code (more on this below).

Static check would be viral from the bottom up because: a) you would
have to annotate all callees (or wrap those calls in a try/catch
whether or not it's really necessary) before you can annote your own
function; and b) you would have to annotate your own function before
it's usable from callers taht are annotated with noexcept.

Further, noexcept targets the (one) important case of "throws
nothing," but note that this is primarily for a very restricted set of
code -- notably destructors, deallocation functions, and swap, a very
small amount of code that offer the nothrow/nofail exception safety
guarantee for correctness in order to implement the "commit/rollback"
part of a function. In fact it's even stronger -- these functions have
to be guaranteed not to fail, not just not to throw, so that they can
be used as the building commit/rollback code that can reliably take
interim work that was done off to the side and either accept it as the
new state or else throw it away.

Now, granted, the current formulation of noexcept is intended to
expand that important case to a (to me secondary, but still
interesting and probably much more common) additional case of code
that wants to offer nothrow/nofail for optimization purposes. In
particular, unlike today's exception specifications, including even
throw(), noexcept allows optimization of the noexcept function's
callees (functions called by the noexcept function, for example to
assume those must be noexcept as well if they are not called within a
try/catch), not just its callers. This latter use is what I expect to
broaden the scope of the code that cares about nothrow, but it has to
be usable by a wide audience of programmers, which I don't think it is
if we follow what you write below.

So I see two uses: nothrow for correctness which applies to very
little code and so benefits little from static checking, and nothrow
for performance which to be useful has to be easily usable by general
C++ programmers and so requires near-seamless static checking which I
haven't seen practically proposed yet.

In that context:

>> that scheme doesn't work at all with templates (what exactly would you
>> write?)
>
>Like this:
>
> template <class T, class Allocator = allocator<T> >
> class vector {
> ...
> iterator erase(const_iterator position) noexcept(
> has_nothrow_copy_constructor<T>::value &&
> has_nothrow_move_constructor<T>::value &&
> has_nothrow_copy_assign<T>::value &&
> has_nothrow_move_assign<T>::value)

This seems problematic for several reasons, mostly on the grounds of
usability:

- Usability: To me, this falls squarely into "the cure is worse than
the disease" territory. A few library writers may do this to gain some
potential performance (and they can do it whether we mandate static
checking or not!), but C++ programmers in general are just not going
to write this code (and mandating static checking would attempt to
make them do so). If the goal is to allow C++ programmers in general
to write "this doesn't throw" on a function in order to make it
faster, which I suspect is the goal for many, I don't think this meets
the bar.

- Usability: Requiring static checking means you couldn't
instantiate vector<T> and call erase with any type T that doesn't
write noexcept on its user-written special functions, right?

- Usability: What about more general template functions that would
call named member functions, operators, etc. on the type T? Are we
going to have to correctly list every possible member function that
might be called? What about if it's an overloaded member function?

- Generality/readiness: Has someone tried this system with complex
examples to see how it deals with issues like the above, such as
overloading? Note that many of these same problems have already been
analyzed in the context of concepts, which had a very similar model of
expressing things in terms of callee capabilities, but with less
syntactic overhead and more flexibility than the above, and that model
still hasn't been fully explored and understood in production-level
code.


>For vector::erase(), we have now the following specification.
> Throws: Nothing unless an exception is thrown by the copy constructor,
> move constructor, assignment operator, or move assignment operator
> of T.
>The above declaration looks very straightforward

To a template metaprogrammer, maybe. :)

Also, for this specific example, I think you would want to include
requiring a nothrow destructor too, right? How easy would it really be
to write these specifications correctly?

>based on this
>specification. It will give a compile error when erase() is called in a
>noexcept(true) function with T which doesn't fulfill the above
>conditions. That sounds fine and great.
>
>> and even when it does work more often than not quickly devolves into the
>> meaningless "throw(exception)".
>
>I don't think this will be a problem in C++ since such
>"throw(exception)" specification is the default (no exceptions
>specification). This is very different situation than that in Java.

I think the default doesn't matter; see above. It seems to me that
what matters is that checking is viral regardless of the default. That
is: if you require static checking, you are requiring all code that
can be called from a checked function must state its throws (Java) or
noexcept (your proposal for C++) clause fully and correctly, right?

And even a default of "throws something" is useless for the purpose of
static checking because it defeats any benefit of static exceptions.
In particular "by default may throw" would mean "by default can't be
called from statically exception checked code."


>Programmers won't be forced to write exception specifications

But everyone will be forced to write them a lot of the time if they
get used. To take your cases:

>until they
>write static exception specification for their own function,

.... which they cannot do until one is already written on every
function they need to call, because it's viral down. Unless they want
to work around it by writing unnecessary try/catches which would add
code clutter and can add some overhead.

>or they
>pass a type for a template which has a static exception specification.

.... or more generally want their function to be callable from any code
that has a static exception specification, because it's viral up.

It seems to me that, to get any benefit from static checking, you'd be
forced to write the specifications broadly throughout the code from
the bottom up. The only way I can see this is significantly better
than Java is that when you just give up on wanting to get the benefit,
instead of writing "throws Exception" everywhere as in Java you would
get to just stop writing the specifications because the default is
"throws something" -- but that isn't an argument in favor of static
checking because it means punting and not using the feature.


>> As often as I hear a C++ programmer
>> wish their exception specifications had Java's static semantics, I
>> hear a Java programmer wish theirs had non-static semantics.
>
>Static checking with noexcept is very different with Java's static
>checking, in that is default or not, that is a type list or a binary.
>I think the problem should be reconsidered separately, shouldn't it?

The default doesn't matter (except when you punt and stop trying to
use the feature, as above) because it must still be written explicitly
to offer any benefit.

The type list vs. binary changes the problem only in degree but not in
kind which is viral by nature.

It could be that I'm missing something, and please let me know if I
am. I don't think static checking has worked out well yet, and the
fundamental issues here would still be the same as Java encountered.

Herb

Convener, SC22/WG21 (C++) (www.gotw.ca/iso)
Architect, Visual C++ (www.gotw.ca/microsoft)

--


[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use

mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>

Rani Sharoni

unread,
Apr 8, 2010, 2:37:27 PM4/8/10
to
On Apr 5, 9:36 am, Herb Sutter <herb.sut...@gmail.com> wrote:
> On Sun, 4 Apr 2010 12:04:30 CST, Kazutoshi Satoda<k_sat...@f2.dion.ne.jp>
wrote:

> >Like this:
>
> > template <class T, class Allocator = allocator<T> >
> > class vector {
> > ...
> > iterator erase(const_iterator position) noexcept(
> > has_nothrow_copy_constructor<T>::value &&
>
> This seems problematic for several reasons, mostly on the grounds of
> usability:
>
> - Usability: To me, this falls squarely into "the cure is worse than
> the disease" territory. A few library writers may do this to gain some
> potential performance (and they can do it whether we mandate static
> checking or not!), but C++ programmers in general are just not going
> to write this code (and mandating static checking would attempt to
> make them do so). If the goal is to allow C++ programmers in general
> to write "this doesn't throw" on a function in order to make it
> faster, which I suspect is the goal for many, I don't think this meets
> the bar.
>
> - Usability: Requiring static checking means you couldn't
> instantiate vector<T> and call erase with any type T that doesn't
> write noexcept on its user-written special functions, right?

Looks like a classic post, Herb.

There is also the run-time conditional no-throw code like push_back
into vector<int> with sufficient capacity (I often see such code in
which reserve is first used to assure no resize). such conditional no-
throw code can be safely called from noexcept function without try-
catch (dead-code). Another common example is map[key] lookup which is
no-throw is the item is already in the map.

Even regardless of conditional no-throw (that Java doesn't address)
there is the legacy code. tons of non-throwing code is out there (e.g.
on windows, COM using error codes) so noexcept better be polite not to
break such.

Static no-throw diagnostics actually do exist but they are matter of
QOI. For example, VC warns about code like void f() throw() { throw
1; } (proven throw) and there is also unreachable-code warning when
try-catch is used for (proven) non-throwing code (a bit noisy in
generic code).

Regrading noexcpt violations, I think that we all agree that such
violations are not a feature (used to terminate the program) but a bug
and traditionally in (non-safe language) C++ bug-mitigation is mater
of QOI (e.g. memory corruption handling).

FWIW, one of the intentions of noexcpt was to relax the mandatory
violation handling of current throw exception specifications in order
to allow optimizations. I recently heard that no-throw optimizations
might not be impacted by mandatory violation handling but it's still
debatable (so it seems we should yet again resort to QOI).

Rani

Herb Sutter

unread,
Apr 8, 2010, 8:20:25 PM4/8/10
to
Hi, quick answer:

Kazutoshi Satoda wrote:


> Herb Sutter wrote:
> > It's true that Yes/No is a much simpler subset of SetOfTypes/None. But
> > it's still the same principle. The question is whether the great
> > reduction of possibilities makes the problem tractable.
>

> After long thoughts on writing a reply to your post, I have realized a
> way how noexcept can reduce the overhead of throw().
>
> Relaxing the rule of stack unwinding before termination can reduce the
> number of stack unwinding path, which depends on the number of objects
> having non-trivial destructor in the case of throw(), into only one
> which goes to std::terminate(). Right?

Yes, but that's not one of the current motivations of noexcept. It's
not about the stack unwinding path so much, as about optimizing
callees aggressively. If we can assume they don't throw, we can
optimize more heavily (e.g., parallelizing loops, doing work out of
order) without worrying whether an exception will be thrown that has
to have all and only the code before the throw point already executed.

> My emphasis on static checking was all based on such idea that static
> checking is the only way to reduce the overhead of mandated runtime
> behavior to acceptable level. But after realizing the above, I
> understand that static checking for noexcept specification is not so
> important while having some difficulties.

Whether we required unwinding or not, it's sufficient to just put a
bit on the stack frame that is noexcept and checking it on the way out
-- if( bNoExcept && exception_is_active() ) terminate();.


> However, I'm still looking forward about some kind of static checking of
> binary noexcept. It may be, noexcept clause in a function; noexcept: ...
> or noexcept { ... } as we often write a comment on a few final lines of
> a function like "never throws here". But this is surely beyond the
> upcoming C++0x.
>
> The following includes some answers for your questions and also includes
> some questions about your assertions about static checking.


>
> > It seems to me that there are some fundamental things here:
> >
> > 1. Static checking inherently defeats writing naturally
> > exception-neutral code which should be the default, because the
> > specifications have to be written explicitly to be useful (and this is
> > true whether the default is "throws nothing" or "throws anything").
>

> What would be required to be written explicitly to make intermediate
> call-chains exception-neutral?
>
> void maythrow();
> void neverthrows() noexcept;
>
> void intermediate()
> {
> maythrow();
> neverthrows();
> }
>
> void catcher()
> {
> try
> {
> intermediate();
> }
> catch ...
> }
>
> Here, I believe intermediate() is exception-neutral without any noise;
> doesn't care about any exceptions and their circumstances to be thrown,
> and propagates them as they are.

The question was about this case:

void f() noexcept {
intermediate();
}

void intermediate() {
g();
}

void g() noexcept {
}

This will never throw, but if you enforce static checking then
intermediate() must also be decorated with noexcept -- it can't just
be exception-neutral and used in any code.


> > 2. Static checking is intrusive and viral from the bottom up and has
> > to be explicitly written to be useful (again, whether the default is
> > "throws nothing" or "throws anything").
>

> In the above code example again, I can't see any viral effect caused by
> the bottom function neverthrows() to callers.

Above, with static checking, if f wants to be noexcept, intermediate
and g must also successively be noexcept.


> I understand the viral effect of Java's exception specification is that
> if maythrow() have a "throw Exception" specification, intermediate() or
> catcher() or both are affected. I agree that this is untenable and one
> of the reason of unfortunate of Java's static checking, but static
> checking for noexcept won't cause such a viral effects.
>
> If you are saying about the strong demands on callees of neverthrows()
> to have noexcept, I agree that is a problem. Such strong demands may
> cause premature decision to specify noexcept, which can likely cause
> versioning problems later.


>
> > 3. Noexcept used "for correctness" is for only a very small set of
> > code, and its new use of "for performance" applies to general purpose
> > code but has to be very simple to write if it's to be used there.
>

> I agree on this.


>
> > In
> > particular, unlike today's exception specifications, including even
> > throw(), noexcept allows optimization of the noexcept function's
> > callees (functions called by the noexcept function, for example to
> > assume those must be noexcept as well if they are not called within a
> > try/catch), not just its callers.
>

> This part was the key of my realization about overhead reduction. Thank
> you very much.
>
> However, I think it was good to mention that the "callee" in effect are
> restricted to those which are inlined or local in the same compile unit
> in general. It was hard to imagine how the caller can affect to
> optimization of a callee which can be in another compile unit. Please
> let me know if I'm wrong here.

LTCG: http://msdn.microsoft.com/en-us/library/xbf3tbeh(VS.80).aspx

We can inline separately compiled code, and then it's fair game for
optimization.


> >> template <class T, class Allocator = allocator<T> >
> >> class vector {
> >> ...
> >> iterator erase(const_iterator position) noexcept(
> >> has_nothrow_copy_constructor<T>::value &&

> >> has_nothrow_move_constructor<T>::value &&
> >> has_nothrow_copy_assign<T>::value &&
> >> has_nothrow_move_assign<T>::value)
> >

> > This seems problematic for several reasons, mostly on the grounds of
> > usability:
> >
> > - Usability: To me, this falls squarely into "the cure is worse than
> > the disease" territory.
>

> Now I can agree this evaluation.


>
> > - Usability: Requiring static checking means you couldn't
> > instantiate vector<T> and call erase with any type T that doesn't
> > write noexcept on its user-written special functions, right?
>

> Right, if it is in a noexcept function.


>
> > - Usability: What about more general template functions that would
> > call named member functions, operators, etc. on the type T? Are we
> > going to have to correctly list every possible member function that
> > might be called? What about if it's an overloaded member function?
>

> The operator noexcept will allow such specification, like this:
>
> template<typename T>
> void f(T& x) noexcept(noexcept(x.foo(), x.foo(0), ++x));
>
> Listing of expressions are not more difficult than listing conditions at
> the "Throws:" clause in the documentation, as far as the condition can
> be written as a constant expression like noexcept expression. I found
> that operations on iostreams involves a runtime property,
> basic_ios::exceptions(), to determine it may throw or not.


>
> > - Generality/readiness: Has someone tried this system with complex
> > examples to see how it deals with issues like the above, such as
> > overloading?
>

> No.
>
> But I have a similar suspect on the current draft: Can noexcept solve
> the problem which happened on throw()? Will Boost adopt noexcept if it
> dropped support of C++2003 compilers?
>
> Boost concluded not to use throw() because it can cause pessimizations
> on a "dumb" compiler. I'm afraid of such compilers to continue causing
> pessimizations for noexcept, too.

It should be straightforward to hide it behind a macro that expands to
nothing on compilers that don't support noexcept:

#if /* noexcept is available */
#define BOOST_NOEXCEPT_TRUE noexcept
#define BOOST_NOEXCEPT_FALSE noexcept(false)
#define BOOST_NOEXCEPT(x) noexcept(x)
#elif /* throw() isn't a bad idea on this compiler */
#define BOOST_NOEXCEPT_TRUE throw()
#define BOOST_NOEXCEPT_FALSE
#define BOOST_NOEXCEPT(x)
#else
#define BOOST_NOEXCEPT_TRUE
#define BOOST_NOEXCEPT_FALSE
#define BOOST_NOEXCEPT(x)
#endif

void f BOOST_NOEXCEPT_TRUE {
..
}

That's just off the cuff, I haven't tried it. Wouldn't that work?


> > Also, for this specific example, I think you would want to include
> > requiring a nothrow destructor too, right? How easy would it really be
> > to write these specifications correctly?
>

> Although throwing destructor is prohibited as violation of Destructible
> requirement on value_type, it also can be specified with operator
> noexcept with explicit destructor call expression (x.~T()).


>
> > if you require static checking, you are requiring all code that
> > can be called from a checked function must state its throws (Java) or
> > noexcept (your proposal for C++) clause fully and correctly, right?
>

> Probably right, but it sounds a kind of begging the question.
>
> I thought that explicit try could be used as an escape. But, yes, it
> means defeating the check, of course.

Also even explicit try isn't enough. In your example above you use
"catch(...)" and so you could statically infer that calling any
intermediate() function is safe. But that's not a general solution,
because of the distance argument (if instead of calling intermediate()
directly you instead call some other function that in turn calls
intermediate() you can't check that statically to know it's safe to
allow it), and because catch blocks are usually supposed to catch
specific types of exceptions that they know how to handle (and then we
don't have enough information to check statically whether a call to
something like intermediate() is okay).


> >>Programmers won't be forced to write exception specifications

> (snip)


> >>until they
> >>write static exception specification for their own function,
> >
> > .... which they cannot do until one is already written on every
> > function they need to call, because it's viral down. Unless they want
> > to work around it by writing unnecessary try/catches which would add
> > code clutter and can add some overhead.
>

> I thought such explicit try might be a good sign of possibility of
> std::terminate() and inefficiency, which will be silently introduced.


>
> > The only way I can see this is significantly better
> > than Java is that when you just give up on wanting to get the benefit,
> > instead of writing "throws Exception" everywhere as in Java you would
> > get to just stop writing the specifications because the default is
> > "throws something" -- but that isn't an argument in favor of static
> > checking because it means punting and not using the feature.
>

> I still think this can be an argument to re-evaluate static checking on
> C++ separately, although the evaluation resulted in not taken for now.
>
> --
> k_satoda

I hope this helps. I still don't think it's workable unless the above
problems can be solved.

Herb

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]

[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]

Kazutoshi Satoda

unread,
Apr 8, 2010, 8:25:47 PM4/8/10
to
Herb Sutter wrote:
>
> It's true that Yes/No is a much simpler subset of SetOfTypes/None. But
> it's still the same principle. The question is whether the great
> reduction of possibilities makes the problem tractable.

After long thoughts on writing a reply to your post, I have realized a
way how noexcept can reduce the overhead of throw().

Relaxing the rule of stack unwinding before termination can reduce the
number of stack unwinding path, which depends on the number of objects
having non-trivial destructor in the case of throw(), into only one
which goes to std::terminate(). Right?

My emphasis on static checking was all based on such idea that static


checking is the only way to reduce the overhead of mandated runtime
behavior to acceptable level. But after realizing the above, I
understand that static checking for noexcept specification is not so
important while having some difficulties.

> 2. Static checking is intrusive and viral from the bottom up and has


> to be explicitly written to be useful (again, whether the default is
> "throws nothing" or "throws anything").

In the above code example again, I can't see any viral effect caused by
the bottom function neverthrows() to callers.

I understand the viral effect of Java's exception specification is that

I agree on this.

>> template <class T, class Allocator = allocator<T> >

No.

> Also, for this specific example, I think you would want to include


> requiring a nothrow destructor too, right? How easy would it really be
> to write these specifications correctly?

Although throwing destructor is prohibited as violation of Destructible
requirement on value_type, it also can be specified with operator
noexcept with explicit destructor call expression (x.~T()).

> if you require static checking, you are requiring all code that
> can be called from a checked function must state its throws (Java) or
> noexcept (your proposal for C++) clause fully and correctly, right?

Probably right, but it sounds a kind of begging the question.

I thought that explicit try could be used as an escape. But, yes, it
means defeating the check, of course.

>> Programmers won't be forced to write exception specifications

(snip)
>>
>> until they
>> write static exception specification for their own function,
>
> .... which they cannot do until one is already written on every
> function they need to call, because it's viral down. Unless they want
> to work around it by writing unnecessary try/catches which would add
> code clutter and can add some overhead.

I thought such explicit try might be a good sign of possibility of
std::terminate() and inefficiency, which will be silently introduced.

> The only way I can see this is significantly better
> than Java is that when you just give up on wanting to get the benefit,
> instead of writing "throws Exception" everywhere as in Java you would
> get to just stop writing the specifications because the default is
> "throws something" -- but that isn't an argument in favor of static
> checking because it means punting and not using the feature.

I still think this can be an argument to re-evaluate static checking on
C++ separately, although the evaluation resulted in not taken for now.

--
k_satoda

[ comp.std.c++ is moderated. To submit articles, try just posting with ]

Alexander Terekhov

unread,
Apr 9, 2010, 1:57:24 PM4/9/10
to

Herb Sutter wrote:

[... optimizations ...]

> Whether we required unwinding or not, it's sufficient to just put a
> bit on the stack frame that is noexcept and checking it on the way out
> -- if( bNoExcept && exception_is_active() ) terminate();.

Unwinding significantly reduces optimization opportunities. Allowing
unwinding for noexcept is EVIL!

regards,
alexander.

--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use

mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>

Alexander Terekhov

unread,
Apr 10, 2010, 3:15:27 PM4/10/10
to
Herb Sutter wrote:
[...]
> #define BOOST_NOEXCEPT_TRUE throw()

Sane noexcept shall not be just a relaxed version of throw()
(with unwinding allowed but not required). Sane noexcept
shall be opposite, not apposite, to throw() in the sense
that for noexcept unwinding shall be prohibited!

regards,
alexander.

Herb Sutter

unread,
Apr 10, 2010, 3:14:33 PM4/10/10
to
On Fri, 9 Apr 2010 11:57:24 CST, Alexander Terekhov <tere...@web.de>
wrote:
>Herb Sutter wrote:

BTW, note that I just dashed that reply off quickly intending it to be
private email. I didn't notice until later that he'd cc'd the csc++
submission address and my email appeared here. :)

>[... optimizations ...]
>
>> Whether we required unwinding or not, it's sufficient to just put a
>> bit on the stack frame that is noexcept and checking it on the way out
>> -- if( bNoExcept && exception_is_active() ) terminate();.
>
>Unwinding significantly reduces optimization opportunities. Allowing
>unwinding for noexcept is EVIL!

Sure, not requiring unwinding means you can optimize callees (as he
quoted me saying already).

But he seemed to be asking about the overhead imposed by noexecept
itself, that's what I thought I was responding to in this part.

Herb

Convener, SC22/WG21 (C++) (www.gotw.ca/iso)
Architect, Visual C++ (www.gotw.ca/microsoft)

--


[ comp.std.c++ is moderated. To submit articles, try just posting with ]

[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]

0 new messages