Boost-Commit :

Date view	Thread view	Subject view	Author view

Subject: [Boost-commit] svn:boost r60458 - sandbox/committee/exceptions
From: dgregor_at_[hidden]
Date: 2010-03-10 23:45:16

Next message: dgregor_at_[hidden]: "[Boost-commit] svn:boost r60459 - sandbox/committee/exceptions"
Previous message: dgregor_at_[hidden]: "[Boost-commit] svn:boost r60457 - sandbox/committee/exceptions"

Author: dgregor
Date: 2010-03-10 23:45:15 EST (Wed, 10 Mar 2010)
New Revision: 60458
URL: http://svn.boost.org/trac/boost/changeset/60458

Log:
Specify when and how special member functions get exception-specifications.

Specify how the exception specifications of virtual member function overrides relate to the virtual member functions that override.

Specify when function pointers with exception specifications can be assigned and initialized.

Text files modified:
   sandbox/committee/exceptions/d3051.html | 76 +++++++++++++++++++++++++++++++++++++-
   sandbox/committee/exceptions/deprecating-exception-specs.rst | 78 ++++++++++++++++++++++++++++++++++++---
   2 files changed, 145 insertions(+), 9 deletions(-)

Modified: sandbox/committee/exceptions/d3051.html
==============================================================================
--- sandbox/committee/exceptions/d3051.html (original)
+++ sandbox/committee/exceptions/d3051.html 2010-03-10 23:45:15 EST (Wed, 10 Mar 2010)
@@ -528,8 +528,6 @@
exception-specification shall not denote a pointer or reference to an
incomplete type, other than void*, const void*, volatile void*, or
const volatile void*.
-4 [FIXME: Figure out what to do with p4!]
-5 [FIXME: Figure out what to do with p5!]
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
@@ -620,9 +618,81 @@
A diagnostic is required only if the sets of type-ids are
differentexception-specifications
are not compatible within a single translation unit.
+4 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 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 An exception-specification is not considered part of a function's
type.
-13 [FIXME: Figure out what to do with p13!]
+13 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:
+<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>
+</ul>
+</blockquote>
+[ Example:
+<blockquote>
+<pre class="literal-block">
+struct A {
+ A();
+ A(const A&) throw();
+ ~A() throw(X);
+};
+
+struct B {
+ B() throw();
+ B(const B&) throw();
+ ~B() throw(Y);
+};
+
+struct D : public A, public B {
+ // Implicit declaration of D::D();
+ // Implicit declaration of D::D(const D&) throw();
+ // 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 [Moved to D.5p8] In a dynamic-exception-specification, a type-id followed by an ellipsis is a pack expansion (14.6.3).
15 [FIXME: Figure out what to do with p15! It's unfortunate
that we're describing noexcept in terms of throw()]

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-10 23:45:15 EST (Wed, 10 Mar 2010)
@@ -238,10 +238,6 @@
 incomplete type, other than void\*, const void\*, volatile void\*, or
 const volatile void\*.`

- 4 :ed:`[FIXME: Figure out what to do with p4!]`
-
- 5 :ed:`[FIXME: Figure out what to do with p5!]`
-
 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
@@ -339,11 +335,81 @@
 differentexception-specifications
 are not compatible` within a single translation unit.

+ 4 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* ]
+
+ 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`.
+
 12 An *exception-specification* is not considered part of a function's
 type.

- 13 :ed:`[FIXME: Figure out what to do with p13!]`
-
+ 13 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&) throw();
+ ~A() throw(X);
+ };
+
+ struct B {
+ B() throw();
+ B(const B&) throw();
+ ~B() throw(Y);
+ };
+
+ struct D : public A, public B {
+ // Implicit declaration of D::D();
+ // Implicit declaration of D::D(const D&) throw();
+ // 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* ]
+
 14 :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).`

 15 :ed:`[FIXME: Figure out what to do with p15! It's unfortunate

Next message: dgregor_at_[hidden]: "[Boost-commit] svn:boost r60459 - sandbox/committee/exceptions"
Previous message: dgregor_at_[hidden]: "[Boost-commit] svn:boost r60457 - sandbox/committee/exceptions"

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