On Mon, 29 Mar 2010 13:01:03 CST, Steve Clamage
<stephen.clamage@sun.com> wrote:
>On Sat, 27 Mar 2010 12:40:58 CST, Alexander Terekhov <terekhov@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


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

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-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

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-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Herb Sutter wrote:

> On Mon, 29 Mar 2010 13:01:03 CST, Steve Clamage
> <stephen.clamage@sun.com> wrote:
>
>> On Sat, 27 Mar 2010 12:40:58 CST, Alexander Terekhov <terekhov@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-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"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.

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

On Wed, 31 Mar 2010 18:11:46 CST, Alexander Terekhov <terekhov@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


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

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-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On Wed, 31 Mar 2010 18:11:10 CST, "Martin B." <0xCDCDCDCD@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

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

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-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

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(); }

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

Herb Sutter wrote:
>
> On Wed, 31 Mar 2010 18:11:46 CST, Alexander Terekhov <terekhov@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-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

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


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

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

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

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)






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

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

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

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


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

"Marco" <prenom_nomus@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.

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

On Sun, 21 Mar 2010 11:58:53 CST, Marco <prenom_nomus@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)

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

Balog Pal wrote:
>
> "Marco" <prenom_nomus@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)

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

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.


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

On Sat, 27 Mar 2010 12:40:58 CST, Alexander Terekhov <terekhov@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/

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

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:
smeyers@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-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]