Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r60524 - sandbox/committee/exceptions
From: dgregor_at_[hidden]
Date: 2010-03-12 11:39:22

Next message: john_at_[hidden]: "[Boost-commit] svn:boost r60525 - trunk/boost/type_traits"
Previous message: dgregor_at_[hidden]: "[Boost-commit] svn:boost r60523 - sandbox/committee/rvalue_ref"

Author: dgregor
Date: 2010-03-12 11:39:22 EST (Fri, 12 Mar 2010)
New Revision: 60524
URL: http://svn.boost.org/trac/boost/changeset/60524

Log:
Final pre-N version
Text files modified:
   sandbox/committee/exceptions/d3051.html | 489 ++------------------------------------
   sandbox/committee/exceptions/deprecating-exception-specs.rst | 501 +--------------------------------------
   2 files changed, 50 insertions(+), 940 deletions(-)

Modified: sandbox/committee/exceptions/d3051.html
==============================================================================
--- sandbox/committee/exceptions/d3051.html (original)
+++ sandbox/committee/exceptions/d3051.html 2010-03-12 11:39:22 EST (Fri, 12 Mar 2010)
@@ -331,27 +331,17 @@
<div class="contents topic" id="index">
index
<ul class="simple">
-<li><a class="reference internal" href="#introduction" id="id6">Introduction</a></li>
-<li><a class="reference internal" href="#approach" id="id7">Approach</a></li>
-<li><a class="reference internal" href="#proposed-changes-to-standard-wording" id="id8">Proposed Changes to Standard Wording</a><ul>
-<li><a class="reference internal" href="#dynamic-storage-duration-basic-stc-dynamic" id="id9">3.7.4 Dynamic storage duration [basic.stc.dynamic]</a></li>
-<li><a class="reference internal" href="#exception-specifications-except-spec" id="id10">15.4 Exception specifications [except.spec]</a></li>
-<li><a class="reference internal" href="#special-functions-except-special" id="id11">15.5 Special functions [except.special]</a></li>
-<li><a class="reference internal" href="#the-std-unexpected-function-except-unexpected" id="id12">15.5.2 The <tt class="docutils literal">std::unexpected()</tt> function [except.unexpected]</a></li>
-<li><a class="reference internal" href="#restrictions-on-exception-handling-res-on-exception-handling" id="id13">17.6.4.11 Restrictions on exception handling [res.on.exception.handling]</a></li>
-<li><a class="reference internal" href="#dynamic-memory-management-support-dynamic" id="id14">18.6 Dynamic memory management [support.dynamic]</a></li>
-<li><a class="reference internal" href="#single-object-forms-new-delete-single" id="id15">18.6.1.1 Single-object forms [new.delete.single]</a></li>
-<li><a class="reference internal" href="#array-forms-new-delete-array" id="id16">18.6.1.2 Array forms [new.delete.array]</a></li>
-<li><a class="reference internal" href="#placement-forms-new-delete-placement" id="id17">18.6.1.3 Placement forms [new.delete.placement]</a></li>
-<li><a class="reference internal" href="#exception-handling-support-exception" id="id18">18.8 Exception handling [support.exception]</a></li>
-<li><a class="reference internal" href="#violating-exception-specifications-exception-unexpected" id="id19">18.8.2 Violating exception-specifications [exception.unexpected]</a></li>
-<li><a class="reference internal" href="#d-5-dynamic-exception-specifications-depr-except-spec-dynamic" id="id20">D.5 Dynamic exception specifications [depr.except.spec.dynamic]</a></li>
+<li><a class="reference internal" href="#introduction" id="id4">Introduction</a></li>
+<li><a class="reference internal" href="#approach" id="id5">Approach</a></li>
+<li><a class="reference internal" href="#proposed-changes-to-standard-wording" id="id6">Proposed Changes to Standard Wording</a><ul>
+<li><a class="reference internal" href="#exception-specifications-except-spec" id="id7">15.4 Exception specifications [except.spec]</a></li>
+<li><a class="reference internal" href="#d-5-dynamic-exception-specifications-depr-except-spec" id="id8">D.5 Dynamic exception specifications [depr.except.spec]</a></li>
</ul>
</li>
</ul>
</div>
<div class="section" id="introduction">
-<h1><a class="toc-backref" href="#id6">Introduction</a></h1>
+<h1><a class="toc-backref" href="#id4">Introduction</a></h1>
<dl class="docutils">
<dt>UK-136</dt>
<dd>Exception specifications have proven close to worthless in practice, while adding a measurable overhead to programs. The feature should be deprecated. The one exception to the rule is the empty throw specification which could serve a legitimate optimizing role if the requirement to call the runtime unexpected mechanism was relaxed in this case.</dd>
@@ -383,9 +373,7 @@
<tt class="docutils literal">throw()</tt>, <tt class="docutils literal">noexcept</tt> does not require the compiler to introduce
code to check whether an exception is thrown. Rather, if a function
specified as <tt class="docutils literal">noexcept</tt> is exited via an exception, the result is
-undefined behavior, which permits compilers to optimize based on the
-knowledge that a <tt class="docutils literal">noexcept</tt> function will not propagate an
-exception.
+a call to <tt class="docutils literal">std::terminate()</tt>.
With the introduction of <tt class="docutils literal">noexcept</tt>, programmers can now express the
two kinds of exception guarantees that are useful in practice, without
additional overhead. This paper therefore proposes to deprecate
@@ -393,15 +381,7 @@
<code>throw(</code>type-id-listopt<code>)</code>.
</div>
<div class="section" id="approach">
-<h1><a class="toc-backref" href="#id7">Approach</a></h1>
-The general approach taken by this paper is to separate the wording
-required for dynamic exception specifications (those using <tt class="docutils literal">throw</tt>)
-into a new, deprecated section D.5, while maintaining the description
-of <tt class="docutils literal">noexcept</tt> and the general behavior of exception
-specifications in 15.4. The intent of the revised 15.4 (and core
-language in general) is to minimize the number of dependencies on
-the deprecated section D.5, and to mark each of those with a
-cross-reference.
+<h1><a class="toc-backref" href="#id5">Approach</a></h1>
To aid in the transition from dynamic exception specifications to
<tt class="docutils literal">noexcept</tt>, the wording provides somewhat loose compatibility rules
for redeclarations of functions that have exception
@@ -439,184 +419,25 @@
These compatibility rules allow a gradual migration from dynamic
exception specifications to <tt class="docutils literal">noexcept</tt>, since a declaration of a
function can choose to use the new or old syntax independently in the
-declaration and in the definition. This is particularly important with
-the implicit declarations of <tt class="docutils literal">operator new</tt>, <tt class="docutils literal">operator new[]</tt>,
-<tt class="docutils literal">operator delete</tt>, and <tt class="docutils literal">operator delete[]</tt>, which this document
-changes to use <tt class="docutils literal">noexcept</tt>.
+declaration and in the definition.
</div>
<div class="section" id="proposed-changes-to-standard-wording">
-<h1><a class="toc-backref" href="#id8">Proposed Changes to Standard Wording</a></h1>
+<h1><a class="toc-backref" href="#id6">Proposed Changes to Standard Wording</a></h1>
The wording in this paper is based on the current working paper
(N3035) as amended by N3050.
-<div class="section" id="dynamic-storage-duration-basic-stc-dynamic">
-<h2><a class="toc-backref" href="#id9">3.7.4 Dynamic storage duration [basic.stc.dynamic]</a></h2>
-Modify paragraph 2 as follows:
-<blockquote>
-2 The library provides default definitions for the global allocation
-and deallocation functions. Some global allocation and deallocation
-functions are replaceable (18.6.1). A C++ program shall provide at
-most one definition of a replaceable allocation or deallocation
-function. Any such function definition replaces the default version
-provided in the library (17.6.3.6). The following allocation and
-deallocation functions (18.6) are implicitly declared in global
-scope in each translation unit of a program.
-<pre class="literal-block">
-void* operator new(std::size_t) throw(std::bad_alloc) noexcept(false);
-void* operator new[](std::size_t) throw(std::bad_alloc) noexcept(false);
-void operator delete(void*) throw() noexcept;
-void operator delete[](void*) throw() noexcept;
-</pre>
-These implicit declarations introduce only the function names
-<tt class="docutils literal">operator new</tt>, <tt class="docutils literal">operator new[]</tt>, <tt class="docutils literal">operator delete</tt>,
-<tt class="docutils literal">operator delete[]</tt> [Note: the implicit declarations do not
-introduce the names <tt class="docutils literal">std</tt> , std::bad_alloc, and
-<tt class="docutils literal">std::size_t</tt>, or any other names that the
-library uses to declare these names. Thus, a new-expression,
-delete-expression or function call that refers to one of these
-functions without including the header <tt class="docutils literal"><new></tt> is
-well-formed. However, referring to <tt class="docutils literal">std</tt> , std::bad_alloc, and
-<tt class="docutils literal">std::size_t</tt> is ill-formed unless the name has been declared by
-including the appropriate header. -- end note] Allocation and/or
-deallocation functions can also be declared and defined for any
-class (12.5).
-</blockquote>
-</div>
<div class="section" id="exception-specifications-except-spec">
-<h2><a class="toc-backref" href="#id10">15.4 Exception specifications [except.spec]</a></h2>
-Modify the paragraphs in this section as follows. Note that every
-paragraph in this section is accounted for (even those that have not
-changed), to ease review. Editorial notes are [Yellow] and will
-describe, e.g., when specific paragraphs have been moved. The
-paragraphs are numbered with old and new numbers (old/new), where the
-old numbers refer to the current working paper and the new numbers
-refer to the desired paragraph numbers after this paper is applied to
-the working paper.
-<blockquote>
-1/1 A function declaration lists exceptions that its function might
-directly or indirectly throw by using an exception-specification
-as a suffix of its declarator.
-A function is said to allow an
-exception of type <code>E</code> if such an exception will propagate
-from the outermost block of that function out of the function.
-<pre class="literal-block">
-exception-specification:
- dynamic-exception-specification
- noexcept-specification
-
-[Moved to D.5p1] dynamic-exception-specification:
- <code>throw (</code> type-id-listopt <code>)</code>
-
-[Moved to D.5p1] type-id-list:
- type-id <code>...</code>opt
- type-id-list <code>,</code> type-id <code>...</code>opt
-
-noexcept-specification:
- <tt class="docutils literal">noexcept (</tt> constant-expression <tt class="docutils literal">)</tt>
- <tt class="docutils literal">noexcept</tt>
-</pre>
-2 In a noexcept-specification, the constant-expression, if supplied,
-shall be a constant expression ([expr.const]) that is contextually
-converted to <tt class="docutils literal">bool</tt> ([conv] Clause 4). A noexcept-specification
-<tt class="docutils literal">noexcept</tt> is equivalent to <tt class="docutils literal">noexcept(true)</tt>.
-2/3 An exception-specification shall appear only on a function
-declarator for a function type, pointer to function type, reference
-to function type, or pointer to member function type that is the
-top-level type of a declaration or definition, or on such a type
-appearing as a parameter or return type in a function declarator. An
-exception-specification shall not appear in a typedef declaration
-or alias-declaration. [ Example :
-<pre class="literal-block">
-void f() throw(int)noexcept; // OK
-void (*fp)() throw (int)noexcept; // OK
-void g(void pfa() throw(int))noexcept; // OK
-typedef int (*pf)() throw(int)noexcept; // ill-formed
-</pre>
-<ul class="simple">
-<li>end example ]</li>
-</ul>
-[Moved to D.5p2] A type denoted in an exception-specification shall not
-denote an incomplete type. A type denoted in an
-exception-specification shall not denote a pointer or reference to an
-incomplete type, other than void*, const void*, volatile void*, or
-const volatile void*.
-6 [Moved to D.5p3] An
-exception-specification can include the same type more than
-once and can include classes that are related by inheritance, even
-though doing so is redundant. [ Note: An
-exception-specification can also include the class
-<code>std::bad_exception</code> (18.8.2.1). - end note
-]
-7 [Moved to D.5p4] A function is
-said to allow an exception of type <code>E</code> if its
-dynamic-exception-specification contains a type
-<code>T</code> for which a handler of type <code>T</code> would be a
-match (15.3) for an exception of type <code>E</code>.
-8 [Moved to D.5p5] Whenever an
-exception is thrown and the search for a handler (15.3) encounters
-the outermost block of a function with an exception-specification,
-the function <code>std::unexpected()</code> is called (15.5.2) if
-the exception-specification does not allow the exception. [
-Example:
-<pre class="literal-block">
-class X { };
-class Y { };
-class Z: public X { };
-class W { };
-
-void f() throw (X, Y) {
- int n = 0;
- if (n) throw X(); // OK
- if (n) throw Z(); // also OK
- throw W(); // will call std::unexpected()
-}
-</pre>
--- end example]
-9 [Moved to D.5p6] The function
-<code>std::unexpected()</code> may throw an exception that will
-satisfy the dynamic-exception-specification for which it
-was invoked, and in this case the search for another handler will
-continue at the call of the function with this
-dynamic-exception-specification (see 15.5.2), or it may call
-<code>std::terminate()</code>.
-10 [Moved to D.5p7] An implementation shall not reject an expression merely because when executed it throws or might throw an exception that the containing function does not allow. [ Example:
-<blockquote>
-<pre class="literal-block">
-extern void f() throw(X, Y);
-void g() throw(X) {
- f(); // OK
-}
-</pre>
-</blockquote>
-the call to <code>f</code> is well-formed even though when called, <code>f</code> might throw exception <code>Y</code> that <code>g</code> does not allow. - end example ]
-11/4 A function with no exception-specification, or with an
-exception-specification of the form <tt class="docutils literal">noexcept(</tt>
-constant-expression <tt class="docutils literal">)</tt> where the constant-expression yields
-<tt class="docutils literal">false</tt>, allows all exceptions. An exception-specification is
-non-throwing if it is of the form throw(), <tt class="docutils literal">noexcept</tt>,
-or <tt class="docutils literal">noexcept(</tt> constant-expression <tt class="docutils literal">)</tt> where the
-constant-expression yields <tt class="docutils literal">true</tt>
-, or <code>throw()</code> (D.5)
-. A function with a
-non-throwing exception-specification does not allow any
-exceptions.
-5 Two
-exception-specifications are compatible if:
+<h2><a class="toc-backref" href="#id7">15.4 Exception specifications [except.spec]</a></h2>
+Modify the paragraphs in this section as follows.
<blockquote>
-<ul class="simple">
-<li>both are non-throwing (regardless of their form), </li>
-<li>both have the form <code>noexcept(constant-expression)</code> and the constant-expressions are equivalent,</li>
-<li>one exception-specification is of the form <code>noexcept(false)</code> and the other is of the form <code>throw(type-id-list)</code> (D.5), or</li>
-<li>both are dynamic-exception-specifications (D.5) that have the same set of type-ids.</li>
-</ul>
-</blockquote>
-3/6 If any declaration of a function has an exception-specification,
+3 If any declaration of a function has an exception-specification
+that is not a noexcept-specification allowing all exceptions,
all declarations, including the definition and an explicit
-specialization, of that function shall have an an compatible exception-specification
with the same set of type-ids. If
any declaration of a pointer to function, reference to function, or
-pointer to member function has an exception-specification, all
-occurrences of that declaration shall have an exception-specification,
+all occurrences of that declaration shall have an compatible exception-specification
with the same set of type-ids. In an
explicit instantiation an exception-specification may be
@@ -624,281 +445,29 @@
specified in an explicit instantiation directive, it shall
have the
same set of type-ids asbe compatible
-to the exception-specifications of other declarations
+with the exception-specifications of other declarations
of that function.
A diagnostic is required only if the sets of type-ids are
differentexception-specifications
are not compatible within a single translation unit.
-4/7 If a virtual function has an exception-specification, all declarations, including the definition, of any function that overrides that virtual function in any derived class shall only allow exceptions that are allowed by the exception-specification of the base class virtual function. [ Example:
-<blockquote>
-<pre class="literal-block">
-struct B {
- virtual void f() throw (int, double);
- virtual void g();
- virtual void h() noexcept;
- virtual void i() noexcept(false);
-};
-
-struct D: B {
- void f(); // ill-formed
- void g() throw (int); // OK
- void h() noexcept(false); // ill-formed
- void i() noexcept; // OK
-};
-</pre>
-</blockquote>
-The declaration of <tt class="docutils literal">D::f</tt> is ill-formed because it allows all exceptions, whereas <tt class="docutils literal">B::f</tt> allows only <tt class="docutils literal">int</tt> and`` double``. Similarly, the declaration of <code>D::h</code> is ill-formed because it allows all exceptions, whereas <code>B::h</code> does not allow any exceptions. - end example] A similar restriction applies to assignment to and initialization of pointers to functions, pointers to member functions, and references to functions: the target entity shall allow at least the exceptions allowed by the source value in the assignment or initialization. [ Example:
-<blockquote>
-<pre class="literal-block">
-class A { /*...*/ };
-void (*pf1)(); // no exception specification
-void (*pf2)() throw(A);
-void (*pf3)() noexcept;
-void f() {
- pf1 = pf2; // OK: pf1 is less restrictive
- pf1 = pf3; // OK: pf1 is less restrictive
- pf2 = pf1; // error: pf2 is more restrictive
- pf3 = pf1; // error: pf3 is more restrictive
- pf3 = pf2; // error: pf3 is more restrictive
-}
-</pre>
-</blockquote>
-<ul class="simple">
-<li>end example ]</li>
-</ul>
-5/8 In such an assignment or initialization, exception-specifications on return types and parameter types shall match exactly be compatible. In other assignments or initializations, exception-specifications shall match exactly be compatible.
-12/9 An exception-specification is not considered part of a function's
-type.
-13/10 An implicitly declared special member function (Clause 12)
-shall may have an exception-specification. If
-Let <tt class="docutils literal">f</tt> is be an implicitly declared default
-constructor, copy constructor, destructor, or copy assignment
-operator, then:
+[Insert a new paragraph before paragraph 5] Two
+exception-specifications are compatible if:
<blockquote>
<ul class="simple">
-<li><tt class="docutils literal">f</tt> shall allow all exceptions if any function it directly invokes allows all exceptions ,</li>
-<li><tt class="docutils literal">f</tt> shall allow no exceptions have the implicit exception-specification <code>noexcept</code> if every function it directly invokes allows no exceptions , otherwise</li>
-<li>its implicit exception-specification is a dynamic-exception-specification (D.5) that specifies the type-id <tt class="docutils literal">T</tt> if and only if <tt class="docutils literal">T</tt> is allowed by the exception-specification of a function directly invoked by <tt class="docutils literal">f</tt>'s implicit definition.</li>
+<li>both are non-throwing (regardless of their form), </li>
+<li>both have the form <code>noexcept(constant-expression)</code> and the constant-expressions are equivalent,</li>
+<li>one exception-specification is a noexcept-specification allowing all exceptions and the other is of the form <code>throw(type-id-list)</code>, or</li>
+<li>both are dynamic-exception-specifications that have the same set of type-ids.</li>
</ul>
</blockquote>
-[ Example:
-<blockquote>
-<pre class="literal-block">
-struct A {
- A();
- A(const A&) throw()noexcept;
- ~A() throw(X);
-};
-
-struct B {
- B() throw()noexcept;
- B(const B&) throw()noexcept;
- ~B() throw(Y);
-};
-
-struct D : public A, public B {
- // Implicit declaration of D::D();
- // Implicit declaration of D::D(const D&) throw()noexcept;
- // Implicit declaration of D::~D() throw(X,Y);
-};
-</pre>
-</blockquote>
-Furthermore, if <tt class="docutils literal">A::~A()</tt> or <tt class="docutils literal">B::~B()</tt> were virtual, <tt class="docutils literal">D::~D()</tt> would not be as restrictive as that of <tt class="docutils literal">A::~A</tt>, and the program would be ill-formed since a function that overrides a virtual function from a base class shall have an exception-specification at least as restrictive as that in the base class. - end example ]
-14/11 [Moved to D.5p8] In a dynamic-exception-specification, a type-id followed by an ellipsis is a pack expansion (14.6.3).
-15/12 If a function with a noexcept-specification whose
-constant-expression yields <tt class="docutils literal">true</tt> throws an exception, the
-behavior is undefined. [Note: A noexcept-specification
-whose constant-expression yields <code>true</code> is in all
-other respects equivalent to the dynamic-exception-specification
-<code>throw()</code> (D.5). - end note] A noexcept-specification
-whose constant-expression yields <tt class="docutils literal">false</tt> is equivalent to omitting the
-exception-specification altogether.
-</blockquote>
-</div>
-<div class="section" id="special-functions-except-special">
-<h2><a class="toc-backref" href="#id11">15.5 Special functions [except.special]</a></h2>
-<blockquote>
-1 The functions <code>std::terminate()</code> (15.5.1) and <code>std::unexpected()</code> (15.5.2) areis used by the exception handling mechanism for coping with errors related to the exception handling mechanism itself. The function <tt class="docutils literal">std::current_exception()</tt> (18.8.5) and the class <tt class="docutils literal">std::nested_exception</tt> (18.8.6) can be used by a program to capture the currently handled exception.</blockquote>
-</div>
-<div class="section" id="the-std-unexpected-function-except-unexpected">
-<h2><a class="toc-backref" href="#id12">15.5.2 The <tt class="docutils literal">std::unexpected()</tt> function [except.unexpected]</a></h2>
-Move this section to D.5 to become D.5.1
-[depr.except.unexpected]. Then modify the following paragraphs as
-follows:
-<blockquote>
-1 If a function with an a dynamic-exception-specification throws an exception that is not listed in the dynamic-exception-specification, the function <code>std::unexpected()</code> is called (18.8.2) immediately after completing the stack unwinding for the former function.
-3 The <tt class="docutils literal">std::unexpected()</tt> function shall not return, but it can throw (or re-throw) an exception. If it throws a new exception which is allowed by the exception specification which previously was violated, then the search for another handler will continue at the call of the function whose exception specification was violated. If it throws or rethrows an exception that the exception-specification does not allow then the following happens: If the dynamic-exception-specification does not include the class <code>std::bad_exception</code> (18.8.2.1) then the function <code>std::terminate()</code> is called, otherwise the thrown exception is replaced by an implementation-defined object of the type <code>std::bad_exception</code> and the search for another handler will continue at the call of the function whose dynamic-exception-specification was violated.</spa
n>
-4 Thus, an a dynamic-exception-specification guarantees that only the listed exceptions will be thrown. If the dynamic-exception-specification includes the type <code>std::bad_exception</code> then any exception not on the list may be replaced by <code>std::bad_exception</code> within the function <code>std::unexpected()</code>.
-</blockquote>
-</div>
-<div class="section" id="restrictions-on-exception-handling-res-on-exception-handling">
-<h2><a class="toc-backref" href="#id13">17.6.4.11 Restrictions on exception handling [res.on.exception.handling]</a></h2>
-Modify the paragaphs shown as follows:
-<blockquote>
-1 Any of the functions defined in the C++ standard library can
-report a failure by throwing an exception of a type described in its
-Throws: paragraph or its exception-specification (15.4). An
-implementation may strengthen the exception-specification for a
-non-virtual function by removing listed exceptions or replacing an empty dynamic-exception-specification (D.5 [depr.except.spec.dynamic]) <code>throw()</code> with a compatible <code>noexcept</code> specification (15.4).
-3 Functions from the C standard library shall not throw exceptions<a class="footnote-reference" href="#id5" id="id4">191</a> except when such a function calls a program-supplied function that throws an exception.
-</blockquote>
-<table class="docutils footnote" frame="void" id="id5" rules="none">
-<colgroup><col class="label" /><col /></colgroup>
-<tbody valign="top">
-<tr><td class="label"><a class="fn-backref" href="#id4">[191]</a></td><td>That is, the C library functions can all be treated as if they have a throw() non-throwing exception-specification. This allows implementations to make performance optimizations based on the absence of exceptions at runtime.</td></tr>
-</tbody>
-</table>
-</div>
-<div class="section" id="dynamic-memory-management-support-dynamic">
-<h2><a class="toc-backref" href="#id14">18.6 Dynamic memory management [support.dynamic]</a></h2>
-Modify the header <tt class="docutils literal"><new></tt> synopsis as follows.
-<pre class="literal-block">
-void* operator new(std::size_t size) throw(std::bad_alloc)noexcept(false);
-void* operator new(std::size_t size, const std::nothrow_t&) throw()`noexcept;
-void operator delete(void* ptr) throw()`noexcept;
-void operator delete(void* ptr, const std::nothrow_t&) throw()`noexcept;
-void* operator new[](std::size_t size) throw(std::bad_alloc)`noexcept(false);
-void* operator new[](std::size_t size, const std::nothrow_t&) throw()`noexcept;
-void operator delete[](void* ptr) throw()`noexcept;
-void operator delete[](void* ptr, const std::nothrow_t&) throw()`noexcept;
-void* operator new (std::size_t size, void* ptr) throw()`noexcept;
-void* operator new[](std::size_t size, void* ptr) throw()`noexcept;
-void operator delete (void* ptr, void*) throw()`noexcept;
-void operator delete[](void* ptr, void*) throw()`noexcept;
-</pre>
-</div>
-<div class="section" id="single-object-forms-new-delete-single">
-<h2><a class="toc-backref" href="#id15">18.6.1.1 Single-object forms [new.delete.single]</a></h2>
-Update the signatures of <tt class="docutils literal">operator new</tt> and <tt class="docutils literal">operator delete</tt> in this section to reflect the changes to the synopsis.
-</div>
-<div class="section" id="array-forms-new-delete-array">
-<h2><a class="toc-backref" href="#id16">18.6.1.2 Array forms [new.delete.array]</a></h2>
-Update the signatures of <tt class="docutils literal">operator new[]</tt> and <tt class="docutils literal">operator delete[]</tt> in this section to reflect the changes to the synopsis.
-</div>
-<div class="section" id="placement-forms-new-delete-placement">
-<h2><a class="toc-backref" href="#id17">18.6.1.3 Placement forms [new.delete.placement]</a></h2>
-Update the signatures of <tt class="docutils literal">operator new</tt>, <tt class="docutils literal">operator delete</tt>, <tt class="docutils literal">operator new[]</tt>, and <tt class="docutils literal">operator delete[]</tt> in this section to reflect the changes to the synopsis.
-</div>
-<div class="section" id="exception-handling-support-exception">
-<h2><a class="toc-backref" href="#id18">18.8 Exception handling [support.exception]</a></h2>
-Modify paragraph 1 as follows:
-<blockquote>
-1 The header <tt class="docutils literal"><exception></tt> defines several types and functions related to the handling of exceptions in a C++ program.
-Header <tt class="docutils literal"><exception></tt> synopsis
-<pre class="literal-block">
-namespace std {
- class exception;
- class bad_exception;
- class nested_exception;
-
- // D.5.2, violating exception-specifications (deprecated):
- class bad_exception;
- typedef void (*unexpected_handler)();
- unexpected_handler set_unexpected(unexpected_handler f) throw();
- void unexpected [[noreturn]] ();
-
- typedef void (*terminate_handler)();
- terminate_handler set_terminate(terminate_handler f) throw();
- void terminate [[noreturn]] ();
-
- bool uncaught_exception() throw();
-
- typedef unspecified exception_ptr;
-
- exception_ptr current_exception();
- void rethrow_exception [[noreturn]] (exception_ptr p);
- template<class E> exception_ptr copy_exception(E e);
- template <class T> void throw_with_nested [[noreturn]] (T&& t);
- template <class E> void rethrow_if_nested(const E& e);
-}
-</pre>
-SEE ALSO: 15.5 , D.5.1 [depr.except.unexpected].
+5 In such an assignment or initialization, exception-specifications on return types and parameter types shall match exactly be compatible. In other assignments or initializations, exception-specifications shall match exactly be compatible.
+[Insert a new paragraph at the end of 15.4] [ Note: The use of dynamic-exception-specifications is deprecated (see annex D). - end note ]
</blockquote>
</div>
-<div class="section" id="violating-exception-specifications-exception-unexpected">
-<h2><a class="toc-backref" href="#id19">18.8.2 Violating exception-specifications [exception.unexpected]</a></h2>
-Move this section to D.5 to become D.5.2
-[depr.exception.unexpected].
-</div>
-<div class="section" id="d-5-dynamic-exception-specifications-depr-except-spec-dynamic">
-<h2><a class="toc-backref" href="#id20">D.5 Dynamic exception specifications [depr.except.spec.dynamic]</a></h2>
-Insert this new section. Green underlined text is used to
-indicate new wording, while normal text is used whenever text was
-moved from another section (15.4, 15.5).
+<div class="section" id="d-5-dynamic-exception-specifications-depr-except-spec">
+<h2><a class="toc-backref" href="#id8">D.5 Dynamic exception specifications [depr.except.spec]</a></h2>
<blockquote>
-1 A dynamic exception specification lists exceptions that its function
-might directly or indirectly throw.
-<pre class="literal-block">
-[Moved from 15.4p1] dynamic-exception-specification:
- <code>throw (</code> type-id-listopt <code>)</code>
-
-[Moved from 15.4p1] type-id-list:
- type-id <code>...</code>opt
- type-id-list <code>,</code> type-id <code>...</code>opt
-</pre>
-2 [Moved from 15.4p2] A type denoted in a
-dynamic-exception-specification shall not denote an
-incomplete type. A type denoted in a
-dynamic-exception-specification shall not denote a pointer or
-reference to an incomplete type, other than <code>void*</code>,
-<code>const void*</code>, <code>volatile void*</code>, or
-<code>const volatile void*</code>.
-3 [Moved from 15.4p6] A
-dynamic-exception-specification can include the same type more than
-once and can include classes that are related by inheritance, even
-though doing so is redundant. [ Note: A
-dynamic-exception-specification can also include the class
-<code>std::bad_exception</code> (18.8.2.1). - end note
-]
-4 [Moved from 15.4p7] A function is
-said to allowallows an exception of type <code>E</code> if its
-dynamic-exception-specification contains a type
-<code>T</code> for which a handler of type <code>T</code> would be a
-match (15.3) for an exception of type <code>E</code>.
-5 [Moved from 15.4p8] Whenever an
-exception is thrown and the search for a handler (15.3) encounters
-the outermost block of a function with an
-dynamic-exception-specification, the function
-<code>std::unexpected()</code> is called (15.5.2) if the
-dynamic-exception-specification does not allow the exception. [
-Example:
-<pre class="literal-block">
-class X { };
-class Y { };
-class Z: public X { };
-class W { };
-
-void f() throw (X, Y) {
- int n = 0;
- if (n) throw X(); // OK
- if (n) throw Z(); // also OK
- throw W(); // will call std::unexpected()
-}
-</pre>
--- end example]
-6 [Moved from 15.4p9] The function
-<code>std::unexpected()</code> may throw an exception that will
-satisfy the dynamic-exception-specification for which it
-was invoked, and in this case the search for another handler will
-continue at the call of the function with this
-dynamic-exception-specification (see 15.5.2), or it may call
-<code>std::terminate()</code>.
-7 [Moved from 15.4p10] An implementation shall not reject an expression merely because when executed it throws or might throw an exception that the containing function whose exception-specification is a dynamic-exception-specification does not allow. [Example:
-<blockquote>
-<pre class="literal-block">
-extern void f() throw(X, Y);
-void g() throw(X) {
- f(); // OK
-}
-</pre>
-</blockquote>
-the call to <code>f</code> is well-formed even though when called, <code>f</code> might throw exception <code>Y</code> that <code>g</code> does not allow. - end example]
-8 [Moved from 15.4p14] In a dynamic-exception-specification, a type-id followed by an ellipsis is a pack expansion (14.6.3).
-</blockquote>
+1 The use of dynamic-exception-specifications is deprecated.</blockquote>
<hr class="docutils" />
<table class="docutils citation" frame="void" id="sutter02" rules="none">
<colgroup><col class="label" /><col /></colgroup>

Modified: sandbox/committee/exceptions/deprecating-exception-specs.rst
==============================================================================
--- sandbox/committee/exceptions/deprecating-exception-specs.rst (original)
+++ sandbox/committee/exceptions/deprecating-exception-specs.rst 2010-03-12 11:39:22 EST (Fri, 12 Mar 2010)
@@ -67,9 +67,7 @@
``throw()``, ``noexcept`` does not require the compiler to introduce
code to check whether an exception is thrown. Rather, if a function
specified as ``noexcept`` is exited via an exception, the result is
-undefined behavior, which permits compilers to optimize based on the
-knowledge that a ``noexcept`` function will not propagate an
-exception.
+a call to ``std::terminate()``.

With the introduction of ``noexcept``, programmers can now express the
two kinds of exception guarantees that are useful in practice, without
@@ -80,15 +78,6 @@
Approach
********

-The general approach taken by this paper is to separate the wording
-required for dynamic exception specifications (those using ``throw``)
-into a new, deprecated section D.5, while maintaining the description
-of ``noexcept`` and the general behavior of exception
-specifications in 15.4. The intent of the revised 15.4 (and core
-language in general) is to minimize the number of dependencies on
-the deprecated section D.5, and to mark each of those with a
-cross-reference.
-
To aid in the transition from dynamic exception specifications to
``noexcept``, the wording provides somewhat loose compatibility rules
for redeclarations of functions that have exception
@@ -130,10 +119,7 @@
These compatibility rules allow a gradual migration from dynamic
exception specifications to ``noexcept``, since a declaration of a
function can choose to use the new or old syntax independently in the
-declaration and in the definition. This is particularly important with
-the implicit declarations of ``operator new``, ``operator new[]``,
-``operator delete``, and ``operator delete[]``, which this document
-changes to use ``noexcept``.
+declaration and in the definition.

Proposed Changes to Standard Wording
************************************
@@ -141,189 +127,20 @@
The wording in this paper is based on the current working paper
(N3035) as amended by N3050.

-3.7.4 Dynamic storage duration [basic.stc.dynamic]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Modify paragraph 2 as follows:
-
- 2 The library provides default definitions for the global allocation
- and deallocation functions. Some global allocation and deallocation
- functions are replaceable (18.6.1). A C++ program shall provide at
- most one definition of a replaceable allocation or deallocation
- function. Any such function definition replaces the default version
- provided in the library (17.6.3.6). The following allocation and
- deallocation functions (18.6) are implicitly declared in global
- scope in each translation unit of a program.
-
- .. parsed-literal::
-
- void* operator new(std::size_t) :del:`throw(std::bad_alloc)` :ins:`noexcept(false)`;
- void* operator new[](std::size_t) :del:`throw(std::bad_alloc)` :ins:`noexcept(false)`;
- void operator delete(void*) :del:`throw()` :ins:`noexcept`;
- void operator delete[](void*) :del:`throw()` :ins:`noexcept`;
-
- These implicit declarations introduce only the function names
- ``operator new``, ``operator new[]``, ``operator delete``,
- ``operator delete[]`` [*Note*: the implicit declarations do not
- introduce the names ``std`` :del:`, std::bad_alloc,` and
- ``std::size_t``, or any other names that the
- library uses to declare these names. Thus, a *new-expression*,
- *delete-expression* or function call that refers to one of these
- functions without including the header ``<new>`` is
- well-formed. However, referring to ``std`` :del:`, std::bad_alloc,` and
- ``std::size_t`` is ill-formed unless the name has been declared by
- including the appropriate header. -- *end note*] Allocation and/or
- deallocation functions can also be declared and defined for any
- class (12.5).
-
15.4 Exception specifications [except.spec]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-Modify the paragraphs in this section as follows. Note that every
-paragraph in this section is accounted for (even those that have not
-changed), to ease review. Editorial notes are :ed:`[Yellow]` and will
-describe, e.g., when specific paragraphs have been moved. The
-paragraphs are numbered with old and new numbers (old/new), where the
-old numbers refer to the current working paper and the new numbers
-refer to the desired paragraph numbers after this paper is applied to
-the working paper.
-
- :del:`1`/:ins:`1` A function declaration lists exceptions that its function might
- directly or indirectly throw by using an *exception-specification*
- as a suffix of its declarator.
- :raw-html:`A function is said to allow an
- exception of type <code>E</code> if such an exception will propagate
- from the outermost block of that function out of the function.`
-
- .. parsed-literal::
-
- *exception-specification*:
- *dynamic-exception-specification*
- *noexcept-specification*
-
- :ed:`[Moved to D.5p1]` :raw-html:`dynamic-exception-specification:`
- :raw-html:`<code>throw (</code> type-id-listopt <code>)</code>`
-
- :ed:`[Moved to D.5p1]` :raw-html:`type-id-list:`
- :raw-html:`type-id <code>...</code>opt`
- :raw-html:`type-id-list <code>,</code> type-id <code>...</code>opt`
-
- *noexcept-specification*:
- ``noexcept (`` *constant-expression* ``)``
- ``noexcept``
-
- :ins:`2` In a *noexcept-specification*, the *constant-expression*, if supplied,
- shall be a constant expression ([expr.const]) that is contextually
- converted to ``bool`` ([conv] Clause 4). A *noexcept-specification*
- ``noexcept`` is equivalent to ``noexcept(true)``.
-
- :del:`2`/:ins:`3` An *exception-specification* shall appear only on a function
- declarator for a function type, pointer to function type, reference
- to function type, or pointer to member function type that is the
- top-level type of a declaration or definition, or on such a type
- appearing as a parameter or return type in a function declarator. An
- *exception-specification* shall not appear in a typedef declaration
- or *alias-declaration*. [ *Example* :
-
- .. parsed-literal::
-
- void f() :del:`throw(int)`:ins:`noexcept`; // OK
- void (\*fp)() :del:`throw (int)`:ins:`noexcept`; // OK
- void g(void pfa() :del:`throw(int))`:ins:`noexcept`; // OK
- typedef int (\*pf)() :del:`throw(int)`:ins:`noexcept`; // ill-formed
-
- - *end example* ]
-
- :ed:`[Moved to D.5p2]` :del:`A type denoted in an exception-specification shall not
- denote an incomplete type. A type denoted in an
- exception-specification shall not denote a pointer or reference to an
- incomplete type, other than void\*, const void\*, volatile void\*, or
- const volatile void\*.`
-
- 6 :ed:`[Moved to D.5p3]` :raw-html:`An
- exception-specification can include the same type more than
- once and can include classes that are related by inheritance, even
- though doing so is redundant. [ Note: An
- exception-specification can also include the class
- <code>std::bad_exception</code> (18.8.2.1). - end note
- ]`
-
- 7 :ed:`[Moved to D.5p4]` :raw-html:`A function is
- said to allow an exception of type <code>E</code> if its
- dynamic-exception-specification contains a type
- <code>T</code> for which a handler of type <code>T</code> would be a
- match (15.3) for an exception of type <code>E</code>.`
-
- 8 :ed:`[Moved to D.5p5]` :raw-html:`Whenever an
- exception is thrown and the search for a handler (15.3) encounters
- the outermost block of a function with an exception-specification,
- the function <code>std::unexpected()</code> is called (15.5.2) if
- the exception-specification does not allow the exception. [
- Example:`
-
- .. parsed-literal::
-
- :del:`class X { };`
- :del:`class Y { };`
- :del:`class Z: public X { };`
- :del:`class W { };`
-
- :del:`void f() throw (X, Y) {`
- :del:`int n = 0;`
- :del:`if (n) throw X(); // OK`
- :del:`if (n) throw Z(); // also OK`
- :del:`throw W(); // will call std::unexpected()`
- :del:`}`
-
- :raw-html:`-- end example]`
-
- 9 :ed:`[Moved to D.5p6]` :raw-html:`The function
- <code>std::unexpected()</code> may throw an exception that will
- satisfy the dynamic-exception-specification for which it
- was invoked, and in this case the search for another handler will
- continue at the call of the function with this
- dynamic-exception-specification (see 15.5.2), or it may call
- <code>std::terminate()</code>.`
-
- 10 :ed:`[Moved to D.5p7]` :raw-html:`An implementation shall not reject an expression merely because when executed it throws or might throw an exception that the containing function does not allow. [ Example:`
-
- .. parsed-literal::
-
- :del:`extern void f() throw(X, Y);`
- :del:`void g() throw(X) {`
- :del:`f(); // OK`
- :del:`}`
-
- :raw-html:`the call to <code>f</code> is well-formed even though when called, <code>f</code> might throw exception <code>Y</code> that <code>g</code> does not allow. - end example ]`
-
- :del:`11`/:ins:`4` A function with no *exception-specification*, or with an
- *exception-specification* of the form ``noexcept(``
- *constant-expression* ``)`` where the *constant-expression* yields
- ``false``, allows all exceptions. An *exception-specification* is
- non-throwing if it is of the form :del:`throw(),` ``noexcept``,
- :del:`or` ``noexcept(`` *constant-expression* ``)`` where the
- *constant-expression* yields ``true``
- :raw-html:`, or <code>throw()</code> (D.5)`
- . A function with a
- non-throwing *exception-specification* does not allow any
- exceptions.
-
- :ins:`5` :raw-html:`Two
- exception-specifications are compatible if:`
-
- * :raw-html:`both are non-throwing (regardless of their form), `
- * :raw-html:`both have the form <code>noexcept(constant-expression)</code> and the constant-expressions are equivalent,`
- * :raw-html:`one exception-specification is of the form <code>noexcept(false)</code> and the other is of the form <code>throw(type-id-list)</code> (D.5), or`
- * :raw-html:`both are dynamic-exception-specifications (D.5) that have the same set of type-ids.`
+Modify the paragraphs in this section as follows.

- :del:`3`/:ins:`6` If any declaration of a function has an *exception-specification*,
+ 3 If any declaration of a function has an *exception-specification*
+ :raw-html:`that is not a noexcept-specification allowing all exceptions`,
 all declarations, including the definition and an explicit
- specialization, of that function shall have an :raw-html:`n compatible exception-specification
 with the same set of type-ids.` If
 any declaration of a pointer to function, reference to function, or
- pointer to member function has an *exception-specification*, all
- occurrences of that declaration shall have an :raw-html:`n compatible exception-specification
 with the same set of type-ids.` In an
 explicit instantiation an *exception-specification* may be
@@ -331,304 +148,28 @@
 specified in an explicit instantiation directive, it shall
 :raw-html:`have the
 same set of type-ids asbe compatible
- to the exception-specifications of` other declarations
+ with the exception-specifications of` other declarations
 of that function.
 A diagnostic is required only if the :raw-html:`sets of type-ids are
 differentexception-specifications
 are not compatible` within a single translation unit.

- :del:`4`/:ins:`7` If a virtual function has an *exception-specification*, all declarations, including the definition, of any function that overrides that virtual function in any derived class shall only allow exceptions that are allowed by the *exception-specification* of the base class virtual function. [ *Example*:
-
- .. parsed-literal::
-
- struct B {
- virtual void f() throw (int, double);
- virtual void g();
- :ins:`virtual void h() noexcept;`
- :ins:`virtual void i() noexcept(false);`
- };
-
- struct D: B {
- void f(); // ill-formed
- void g() throw (int); // OK
- :ins:`void h() noexcept(false); // ill-formed`
- :ins:`void i() noexcept; // OK`
- };
-
- The declaration of ``D::f`` is ill-formed because it allows all exceptions, whereas ``B::f`` allows only ``int`` and`` double``. :raw-html:`Similarly, the declaration of <code>D::h</code> is ill-formed because it allows all exceptions, whereas <code>B::h</code> does not allow any exceptions.` - *end example*] A similar restriction applies to assignment to and initialization of pointers to functions, pointers to member functions, and references to functions: the target entity shall allow at least the exceptions allowed by the source value in the assignment or initialization. [ *Example*:
-
- .. parsed-literal::
-
- class A { /\*...\*/ };
- void (\*pf1)(); // no exception specification
- void (\*pf2)() throw(A);
- :ins:`void (\*pf3)() noexcept;`
- void f() {
- pf1 = pf2; // OK: pf1 is less restrictive
- :ins:`pf1 = pf3; // OK: pf1 is less restrictive`
- pf2 = pf1; // error: pf2 is more restrictive
- :ins:`pf3 = pf1; // error: pf3 is more restrictive`
- :ins:`pf3 = pf2; // error: pf3 is more restrictive`
- }
-
- - *end example* ]
-
- :del:`5`/:ins:`8` In such an assignment or initialization, *exception-specifications* on return types and parameter types shall :del:`match exactly` :ins:`be compatible`. In other assignments or initializations, *exception-specifications* shall :del:`match exactly` :ins:`be compatible`.
-
- :del:`12`/:ins:`9` An *exception-specification* is not considered part of a function's
- type.
-
- :del:`13`/:ins:`10` An implicitly declared special member function (Clause 12)
- :del:`shall` :ins:`may` have an *exception-specification*. :del:`If`
- :ins:`Let` ``f`` :del:`is` :ins:`be` an implicitly declared default
- constructor, copy constructor, destructor, or copy assignment
- operator, :ins:`then:`
-
- * ``f`` shall allow all exceptions if any function it directly invokes allows all exceptions :ins:`,`
- * ``f`` shall :del:`allow no exceptions` :raw-html:`have the implicit exception-specification <code>noexcept</code>` if every function it directly invokes allows no exceptions :ins:`, otherwise`
- * its implicit *exception-specification* :raw-html:`is a dynamic-exception-specification (D.5) that ` specifies the *type-id* ``T`` if and only if ``T`` is allowed by the *exception-specification* of a function directly invoked by ``f``'s implicit definition.
-
- [ *Example*:
-
- .. parsed-literal::
-
- struct A {
- A();
- A(const A&) :del:`throw()`:ins:`noexcept`;
- ~A() throw(X);
- };
-
- struct B {
- B() :del:`throw()`:ins:`noexcept`;
- B(const B&) :del:`throw()`:ins:`noexcept`;
- ~B() throw(Y);
- };
-
- struct D : public A, public B {
- // Implicit declaration of D::D();
- // Implicit declaration of D::D(const D&) :del:`throw()`:ins:`noexcept`;
- // Implicit declaration of D::~D() throw(X,Y);
- };
-
- Furthermore, if ``A::~A()`` or ``B::~B()`` were virtual, ``D::~D()`` would not be as restrictive as that of ``A::~A``, and the program would be ill-formed since a function that overrides a virtual function from a base class shall have an exception-specification at least as restrictive as that in the base class. - *end example* ]
-
- :del:`14`/:ins:`11` :ed:`[Moved to D.5p8]` :raw-html:`In a dynamic-exception-specification, a type-id followed by an ellipsis is a pack expansion (14.6.3).`
-
- :del:`15`/:ins:`12` If a function with a *noexcept-specification* whose
- *constant-expression* yields ``true`` throws an exception, the
- behavior is undefined. :raw-html:`[Note: A noexcept-specification
- whose constant-expression yields <code>true</code> is in all
- other respects equivalent to the dynamic-exception-specification
- <code>throw()</code> (D.5). - end note]` A *noexcept-specification*
- whose *constant-expression* yields ``false`` is equivalent to omitting the
- *exception-specification* altogether.
-
-15.5 Special functions [except.special]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
- 1 The :raw-html:`functions <code>std::terminate()</code> (15.5.1) and <code>std::unexpected()</code> (15.5.2) areis` used by the exception handling mechanism for coping with errors related to the exception handling mechanism itself. The function ``std::current_exception()`` (18.8.5) and the class ``std::nested_exception`` (18.8.6) can be used by a program to capture the currently handled exception.
-
-15.5.2 The ``std::unexpected()`` function [except.unexpected]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Move this section to D.5 to become D.5.1
-[depr.except.unexpected]. Then modify the following paragraphs as
-follows:
-
- 1 If a function with :del:`an` :ins:`a` :raw-html:`dynamic-exception-specification throws an exception that is not listed in the dynamic-exception-specification, the function <code>std::unexpected()</code> is called (18.8.2) immediately after completing the stack unwinding for the former function.`
-
- 3 The ``std::unexpected()`` function shall not return, but it can throw (or re-throw) an exception. If it throws a new exception which is allowed by the exception specification which previously was violated, then the search for another handler will continue at the call of the function whose exception specification was violated. If it throws or rethrows an exception that the *exception-specification* does not allow then the following happens: If the :raw-html:`dynamic-exception-specification does not include the class <code>std::bad_exception</code> (18.8.2.1) then the function <code>std::terminate()</code> is called, otherwise the thrown exception is replaced by an implementation-defined object of the type <code>std::bad_exception</code> and the search for another handler will continue at the call of the function whose dynamic-exception-specification was violated.`
-
- 4 Thus, :del:`an` :ins:`a` :raw-html:`dynamic-exception-specification guarantees that only the listed exceptions will be thrown. If the dynamic-exception-specification includes the type <code>std::bad_exception</code> then any exception not on the list may be replaced by <code>std::bad_exception</code> within the function <code>std::unexpected()</code>.`
-
-17.6.4.11 Restrictions on exception handling [res.on.exception.handling]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Modify the paragaphs shown as follows:
-
- 1 Any of the functions defined in the C++ standard library can
- report a failure by throwing an exception of a type described in its
- **Throws**: paragraph or its *exception-specification* (15.4). An
- implementation may strengthen the *exception-specification* for a
- non-virtual function by removing listed exceptions :raw-html:`or replacing an empty dynamic-exception-specification (D.5 [depr.except.spec.dynamic]) <code>throw()</code> with a compatible <code>noexcept</code> specification (15.4)`.
-
- 3 Functions from the C standard library shall not throw exceptions [191]_ except when such a function calls a program-supplied function that throws an exception.
-
-.. [191] That is, the C library functions can all be treated as if they have a :del:`throw()` :ins:`non-throwing` *exception-specification*. This allows implementations to make performance optimizations based on the absence of exceptions at runtime.
-
-18.6 Dynamic memory management [support.dynamic]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Modify the header ``<new>`` synopsis as follows.
-
-.. parsed-literal::
-
- void* operator new(std::size_t size) :del:`throw(std::bad_alloc)`:ins:`noexcept(false)`;
- void* operator new(std::size_t size, const std::nothrow_t&) :del:`throw()``:ins:`noexcept`;
- void operator delete(void* ptr) :del:`throw()``:ins:`noexcept`;
- void operator delete(void* ptr, const std::nothrow_t&) :del:`throw()``:ins:`noexcept`;
- void* operator new[](std::size_t size) :del:`throw(std::bad_alloc)``:ins:`noexcept(false)`;
- void* operator new[](std::size_t size, const std::nothrow_t&) :del:`throw()``:ins:`noexcept`;
- void operator delete[](void* ptr) :del:`throw()``:ins:`noexcept`;
- void operator delete[](void* ptr, const std::nothrow_t&) :del:`throw()``:ins:`noexcept`;
- void* operator new (std::size_t size, void* ptr) :del:`throw()``:ins:`noexcept`;
- void* operator new[](std::size_t size, void* ptr) :del:`throw()``:ins:`noexcept`;
- void operator delete (void* ptr, void*) :del:`throw()``:ins:`noexcept`;
- void operator delete[](void* ptr, void*) :del:`throw()``:ins:`noexcept`;
-
-18.6.1.1 Single-object forms [new.delete.single]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Update the signatures of ``operator new`` and ``operator delete`` in this section to reflect the changes to the synopsis.
-
-18.6.1.2 Array forms [new.delete.array]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Update the signatures of ``operator new[]`` and ``operator delete[]`` in this section to reflect the changes to the synopsis.
-
-18.6.1.3 Placement forms [new.delete.placement]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Update the signatures of ``operator new``, ``operator delete``, ``operator new[]``, and ``operator delete[]`` in this section to reflect the changes to the synopsis.
-
-18.8 Exception handling [support.exception]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Modify paragraph 1 as follows:
-
- 1 The header ``<exception>`` defines several types and functions related to the handling of exceptions in a C++ program.
-
- Header ``<exception>`` synopsis
-
- .. parsed-literal::
-
- namespace std {
- class exception;
- :del:`class bad_exception;`
- class nested_exception;
-
- :ins:`// D.5.2, violating exception-specifications (deprecated):`
- :ins:`class bad_exception;`
- typedef void (\*unexpected_handler)();
- unexpected_handler set_unexpected(unexpected_handler f) throw();
- void unexpected [[noreturn]] ();
-
- typedef void (\*terminate_handler)();
- terminate_handler set_terminate(terminate_handler f) throw();
- void terminate [[noreturn]] ();
-
- bool uncaught_exception() throw();
-
- typedef *unspecified* exception_ptr;
-
- exception_ptr current_exception();
- void rethrow_exception [[noreturn]] (exception_ptr p);
- template<class E> exception_ptr copy_exception(E e);
- template <class T> void throw_with_nested [[noreturn]] (T&& t);
- template <class E> void rethrow_if_nested(const E& e);
- }
-
- SEE ALSO: 15.5 :ins:`, D.5.1 [depr.except.unexpected]`.
-
-
-
-
-18.8.2 Violating exception-specifications [exception.unexpected]
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Move this section to D.5 to become D.5.2
-[depr.exception.unexpected].
-
-:ins:`D.5 Dynamic exception specifications [depr.except.spec.dynamic]`
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Insert this new section. :ins:`Green underlined text` is used to
-indicate new wording, while normal text is used whenever text was
-moved from another section (15.4, 15.5).
-
- 1 :ins:`A dynamic exception specification lists exceptions that its function
- might directly or indirectly throw.`
-
- .. parsed-literal::
-
- :ed:`[Moved from 15.4p1]` :raw-html:`dynamic-exception-specification:`
- :raw-html:`<code>throw (</code> type-id-listopt <code>)</code>`
-
- :ed:`[Moved from 15.4p1]` :raw-html:`type-id-list:`
- :raw-html:`type-id <code>...</code>opt`
- :raw-html:`type-id-list <code>,</code> type-id <code>...</code>opt`
-
- 2 :ed:`[Moved from 15.4p2]` :raw-html:`A type denoted in a
- dynamic-exception-specification shall not denote an
- incomplete type. A type denoted in a
- dynamic-exception-specification shall not denote a pointer or
- reference to an incomplete type, other than <code>void*</code>,
- <code>const void*</code>, <code>volatile void*</code>, or
- <code>const volatile void*</code>.`
-
- 3 :ed:`[Moved from 15.4p6]` :raw-html:`A
- dynamic-exception-specification can include the same type more than
- once and can include classes that are related by inheritance, even
- though doing so is redundant. [ Note: A
- dynamic-exception-specification can also include the class
- <code>std::bad_exception</code> (18.8.2.1). - end note
- ]`
-
- 4 :ed:`[Moved from 15.4p7]` :raw-html:`A function is
- said to allowallows an exception of type <code>E</code> if its
- dynamic-exception-specification contains a type
- <code>T</code> for which a handler of type <code>T</code> would be a
- match (15.3) for an exception of type <code>E</code>.`
-
- 5 :ed:`[Moved from 15.4p8]` :raw-html:`Whenever an
- exception is thrown and the search for a handler (15.3) encounters
- the outermost block of a function with an
- dynamic-exception-specification, the function
- <code>std::unexpected()</code> is called (15.5.2) if the
- dynamic-exception-specification does not allow the exception. [
- Example:`
-
- .. parsed-literal::
-
- class X { };
- class Y { };
- class Z: public X { };
- class W { };
-
- void f() throw (X, Y) {
- int n = 0;
- if (n) throw X(); // OK
- if (n) throw Z(); // also OK
- throw W(); // will call std::unexpected()
- }
-
- :raw-html:`-- end example]`
-
- 6 :ed:`[Moved from 15.4p9]` :raw-html:`The function
- <code>std::unexpected()</code> may throw an exception that will
- satisfy the dynamic-exception-specification for which it
- was invoked, and in this case the search for another handler will
- continue at the call of the function with this
- dynamic-exception-specification (see 15.5.2), or it may call
- <code>std::terminate()</code>.`
-
- 7 :ed:`[Moved from 15.4p10]` :raw-html:`An implementation shall not reject an expression merely because when executed it throws or might throw an exception that the containing function whose exception-specification is a dynamic-exception-specification does not allow. [Example:`
-
- .. parsed-literal::
+ :ed:`[Insert a new paragraph before paragraph 5]` :raw-html:`Two
+ exception-specifications are compatible if:`

- extern void f() throw(X, Y);
- void g() throw(X) {
- f(); // OK
- }
+ * :raw-html:`both are non-throwing (regardless of their form), `
+ * :raw-html:`both have the form <code>noexcept(constant-expression)</code> and the constant-expressions are equivalent,`
+ * :raw-html:`one exception-specification is a noexcept-specification allowing all exceptions and the other is of the form <code>throw(type-id-list)</code>, or`
+ * :raw-html:`both are dynamic-exception-specifications that have the same set of type-ids.`

- :raw-html:`the call to <code>f</code> is well-formed even though when called, <code>f</code> might throw exception <code>Y</code> that <code>g</code> does not allow. - end example]`
+ 5 In such an assignment or initialization, *exception-specifications* on return types and parameter types shall :del:`match exactly` :ins:`be compatible`. In other assignments or initializations, *exception-specifications* shall :del:`match exactly` :ins:`be compatible`.

- 8 :ed:`[Moved from 15.4p14]` :raw-html:`In a dynamic-exception-specification, a type-id followed by an ellipsis is a pack expansion (14.6.3).`
+ :ed:`[Insert a new paragraph at the end of 15.4]` :raw-html:`[ Note: The use of dynamic-exception-specifications is deprecated (see annex D). - end note ]`
+
+:ins:`D.5 Dynamic exception specifications [depr.except.spec]`
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ :ins:`1` :raw-html:`The use of dynamic-exception-specifications is deprecated.`

------

Next message: john_at_[hidden]: "[Boost-commit] svn:boost r60525 - trunk/boost/type_traits"
Previous message: dgregor_at_[hidden]: "[Boost-commit] svn:boost r60523 - sandbox/committee/rvalue_ref"

Date view	Thread view	Subject view	Author view

Boost-Commit list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk