[class.derived] - C++14 → C++17

Files changed (1) hide show

tmp/tmpzrojk6uw/{from.md → to.md} +280 -152

tmp/tmpzrojk6uw/{from.md → to.md} RENAMED Viewed

@@ -14,65 +14,70 @@ base-specifier-list:
     base-specifier-list ',' base-specifier '...'ₒₚₜ
 ```
 ``` bnf
 base-specifier:
-    attribute-specifier-seqₒₚₜ base-type-specifier
-    attribute-specifier-seqₒₚₜ 'virtual' access-specifierₒₚₜ base-type-specifier
-    attribute-specifier-seqₒₚₜ access-specifier 'virtual'ₒₚₜ base-type-specifier
 ```
 ``` bnf
 class-or-decltype:
     nested-name-specifierₒₚₜ class-name
     decltype-specifier
 ```
-``` bnf
-base-type-specifier:
-    class-or-decltype
-```
 ``` bnf
 access-specifier:
     'private'
     'protected'
     'public'
 ```
 The optional *attribute-specifier-seq* appertains to the
 *base-specifier*.
-The type denoted by a *base-type-specifier* shall be a class type that
-is not an incompletely defined class (Clause  [[class]]); this class is
-called a *direct base class* for the class being defined. During the
-lookup for a base class name, non-type names are ignored (
-[[basic.scope.hiding]]). If the name found is not a *class-name*, the
-program is ill-formed. A class `B` is a base class of a class `D` if it
-is a direct base class of `D` or a direct base class of one of `D`’s
-base classes. A class is an *indirect* base class of another if it is a
-base class but not a direct base class. A class is said to be (directly
-or indirectly) *derived* from its (direct or indirect) base classes. See
-Clause  [[class.access]] for the meaning of *access-specifier*. Unless
-redeclared in the derived class, members of a base class are also
-considered to be members of the derived class. The base class members
-are said to be *inherited* by the derived class. Inherited members can
-be referred to in expressions in the same manner as other members of the
-derived class, unless their names are hidden or ambiguous (
-[[class.member.lookup]]). The scope resolution operator `::` (
-[[expr.prim]]) can be used to refer to a direct or indirect base member
-explicitly. This allows access to a name that has been redeclared in the
-derived class. A derived class can itself serve as a base class subject
-to access control; see  [[class.access.base]]. A pointer to a derived
-class can be implicitly converted to a pointer to an accessible
-unambiguous base class ([[conv.ptr]]). An lvalue of a derived class
-type can be bound to a reference to an accessible unambiguous base
-class ([[dcl.init.ref]]).
 The *base-specifier-list* specifies the type of the *base class
 subobjects* contained in an object of the derived class type.
 ``` cpp
 struct Base {
   int a, b, c;
 };
 ```
@@ -90,88 +95,109 @@ struct Derived2 : Derived {
 ```
 Here, an object of class `Derived2` will have a subobject of class
 `Derived` which in turn will have a subobject of class `Base`.
 A *base-specifier* followed by an ellipsis is a pack expansion (
 [[temp.variadic]]).
 The order in which the base class subobjects are allocated in the most
-derived object ([[intro.object]]) is unspecified. a derived class and
-its base class subobjects can be represented by a directed acyclic graph
-(DAG) where an arrow means “directly derived from.” A DAG of subobjects
-is often referred to as a “subobject lattice.”
 <a id="fig:dag"></a>
 ![Directed acyclic graph \[fig:dag\]](images/figdag.svg)
-The arrows need not have a physical representation in memory.
-Initialization of objects representing base classes can be specified in
-constructors; see  [[class.base.init]].
-A base class subobject might have a layout ([[basic.stc]]) different
-from the layout of a most derived object of the same type. A base class
-subobject might have a polymorphic behavior ([[class.cdtor]]) different
-from the polymorphic behavior of a most derived object of the same type.
-A base class subobject may be of zero size (Clause  [[class]]); however,
-two subobjects that have the same class type and that belong to the same
-most derived object must not be allocated at the same address (
-[[expr.eq]]).
 ## Multiple base classes <a id="class.mi">[[class.mi]]</a>
-A class can be derived from any number of base classes. The use of more
-than one direct base class is often called multiple inheritance.
 ``` cpp
-class A { /* ... */ };
-class B { /* ... */ };
-class C { /* ... */ };
-class D : public A, public B, public C { /* ... */ };
 ```
-The order of derivation is not significant except as specified by the
-semantics of initialization by constructor ([[class.base.init]]),
-cleanup ([[class.dtor]]), and storage layout ([[class.mem]],
-[[class.access.spec]]).
 A class shall not be specified as a direct base class of a derived class
-more than once. A class can be an indirect base class more than once and
-can be a direct and an indirect base class. There are limited things
-that can be done with such a class. The non-static data members and
-member functions of the direct base class cannot be referred to in the
-scope of the derived class. However, the static members, enumerations
-and types can be unambiguously referred to.
 ``` cpp
-class X { /* ... */ };
-class Y : public X, public X { /* ... */ };             // ill-formed
 ```
 ``` cpp
-class L { public: int next;  /* ... */ };
-class A : public L { /* ... */ };
-class B : public L { /* ... */ };
-class C : public A, public B { void f(); /* ... */ };   // well-formed
-class D : public A, public L { void f(); /* ... */ };   // well-formed
 ```
-A base class specifier that does not contain the keyword `virtual`,
-specifies a *non-virtual* base class. A base class specifier that
-contains the keyword `virtual`, specifies a *virtual* base class. For
 each distinct occurrence of a non-virtual base class in the class
 lattice of the most derived class, the most derived object (
 [[intro.object]]) shall contain a corresponding distinct base class
 subobject of that type. For each distinct base class that is specified
 virtual, the most derived object shall contain a single base class
-subobject of that type. for an object of class type `C`, each distinct
-occurrence of a (non-virtual) base class `L` in the class lattice of `C`
-corresponds one-to-one with a distinct `L` subobject within the object
-of type `C`. Given the class `C` defined above, an object of class `C`
-will have two subobjects of class `L` as shown below.
 <a id="fig:nonvirt"></a>
 ![Non-virtual base \[fig:nonvirt\]](images/fignonvirt.svg)
@@ -184,51 +210,63 @@ void C::f() { A::next = B::next; }      // well-formed
 ```
 Without the `A::` or `B::` qualifiers, the definition of `C::f` above
 would be ill-formed because of ambiguity ([[class.member.lookup]]).
-For another example,
 ``` cpp
-class V { /* ... */ };
-class A : virtual public V { /* ... */ };
-class B : virtual public V { /* ... */ };
-class C : public A, public B { /* ... */ };
 ```
-for an object `c` of class type `C`, a single subobject of type `V` is
-shared by every base subobject of `c` that has a `virtual` base class of
-type `V`. Given the class `C` defined above, an object of class `C` will
-have one subobject of class `V`, as shown below.
 <a id="fig:virt"></a>
 ![Virtual base \[fig:virt\]](images/figvirt.svg)
 A class can have both virtual and non-virtual base classes of a given
 type.
 ``` cpp
-class B { /* ... */ };
-class X : virtual public B { /* ... */ };
-class Y : virtual public B { /* ... */ };
-class Z : public B { /* ... */ };
-class AA : public X, public Y, public Z { /* ... */ };
 ```
 For an object of class `AA`, all `virtual` occurrences of base class `B`
 in the class lattice of `AA` correspond to a single `B` subobject within
 the object of type `AA`, and every other occurrence of a (non-virtual)
 base class `B` in the class lattice of `AA` corresponds one-to-one with
 a distinct `B` subobject within the object of type `AA`. Given the class
 `AA` defined above, class `AA` has two subobjects of class `B`: `Z`’s
-`B` and the virtual `B` shared by `X` and `Y`, as shown below.
 <a id="fig:virtnonvirt"></a>
 ![Virtual and non-virtual base \[fig:virtnonvirt\]](images/figvirtnonvirt.svg)
 ## Member name lookup <a id="class.member.lookup">[[class.member.lookup]]</a>
 Member name lookup determines the meaning of a name (*id-expression*) in
 a class scope ([[basic.scope.class]]). Name lookup can result in an
 *ambiguity*, in which case the program is ill-formed. For an
@@ -251,20 +289,22 @@ injected-class-names) are replaced by the types they designate. S(f,C)
 is calculated as follows:
 If `C` contains a declaration of the name `f`, the declaration set
 contains every declaration of `f` declared in `C` that satisfies the
 requirements of the language construct in which the lookup occurs.
-Looking up a name in an *elaborated-type-specifier* (
 [[basic.lookup.elab]]) or *base-specifier* (Clause  [[class.derived]]),
 for instance, ignores all non-type declarations, while looking up a name
 in a *nested-name-specifier* ([[basic.lookup.qual]]) ignores function,
 variable, and enumerator declarations. As another example, looking up a
 name in a *using-declaration* ([[namespace.udecl]]) includes the
 declaration of a class or enumeration that would ordinarily be hidden by
-another declaration of that name in the same scope. If the resulting
-declaration set is not empty, the subobject set contains `C` itself, and
-calculation is complete.
 Otherwise (i.e., `C` does not contain a declaration of `f` or the
 resulting declaration set is empty), S(f,C) is initially empty. If `C`
 has base classes, calculate the lookup set for `f` in each direct base
 class subobject Bᵢ, and merge each such lookup set S(f,Bᵢ) in turn into
@@ -288,10 +328,12 @@ the intermediate S(f,C):
   declarations and the union of the subobject sets.
 The result of name lookup for `f` in `C` is the declaration set of
 S(f,C). If it is an invalid set, the program is ill-formed.
 ``` cpp
 struct A { int x; };                    // S(x,A) = { { A::x }, { A } }
 struct B { float x; };                  // S(x,B) = { { B::x }, { B } }
 struct C: public A, public B { };       // S(x,C) = { invalid, { A in C, B in C } }
 struct D: public virtual C { };         // S(x,D) = S(x,C)
@@ -301,18 +343,22 @@ int main() {
   F f;
   f.x = 0;                              // OK, lookup finds E::x
 }
 ```
-S(x,F) is unambiguous because the `A` and `B` base subobjects of `D` are
-also base subobjects of `E`, so S(x,D) is discarded in the first merge
-step.
-If the name of an overloaded function is unambiguously found,
-overloading resolution ([[over.match]]) also takes place before access
-control. Ambiguities can often be resolved by qualifying a name with its
-class name.
 ``` cpp
 struct A {
   int f();
 };
@@ -328,14 +374,19 @@ struct B {
 struct C : A, B {
   int f() { return A::f() + B::f(); }
 };
 ```
-A static member, a nested type or an enumerator defined in a base class
-`T` can unambiguously be found even if an object has more than one base
-class subobject of type `T`. Two base class subobjects share the
-non-static member subobjects of their common virtual base classes.
 ``` cpp
 struct V {
   int v;
 };
@@ -354,15 +405,20 @@ void f(D* pd) {
   int i = pd->e;    // OK: only one e (enumerator)
   pd->a++;          // error, ambiguous: two a{s} in D
 }
 ```
-When virtual base classes are used, a hidden declaration can be reached
-along a path through the subobject lattice that does not pass through
-the hiding declaration. This is not an ambiguity. The identical use with
-non-virtual base classes is an ambiguity; in that case there is no
-unique instance of the name that hides all the others.
 ``` cpp
 struct V { int f();  int x; };
 struct W { int g();  int y; };
 struct B : virtual V, W {
@@ -389,15 +445,19 @@ void D::glorp() {
   y++;              // error: B::y and C's W::y
   g();              // error: B::g() and C's W::g()
 }
 ```
 An explicit or implicit conversion from a pointer to or an expression
 designating an object of a derived class to a pointer or reference to
 one of its base classes shall unambiguously refer to a unique object
 representing the base class.
 ``` cpp
 struct V { };
 struct A { };
 struct B : A, virtual V { };
 struct C : A, virtual V { };
@@ -409,13 +469,17 @@ void g() {
   A* pa = &d;       // error, ambiguous: C's A or B's A?
   V* pv = &d;       // OK: only one V subobject
 }
 ```
-Even if the result of name lookup is unambiguous, use of a name found in
-multiple subobjects might still be ambiguous ([[conv.mem]],
-[[expr.ref]], [[class.access.base]]).
 ``` cpp
 struct B1 {
   void f();
   static void f(int);
@@ -438,15 +502,19 @@ struct D: I1, I2, B2 {
     int D::* mpD = &D::i;       // Ambiguous conversion
   }
 };
 ```
 ## Virtual functions <a id="class.virtual">[[class.virtual]]</a>
-Virtual functions support dynamic binding and object-oriented
-programming. A class that declares or inherits a virtual function is
-called a *polymorphic class*.
 If a virtual member function `vf` is declared in a class `Base` and in a
 class `Derived`, derived directly or indirectly from `Base`, a member
 function `vf` with the same name, parameter-type-list ([[dcl.fct]]),
 cv-qualification, and ref-qualifier (or absence of same) as `Base::vf`
@@ -457,10 +525,12 @@ of a class object `S` is a *final overrider* unless the most derived
 class ([[intro.object]]) of which `S` is a base class subobject (if
 any) declares or inherits another member function that overrides `vf`.
 In a derived class, if a virtual member function of a base class
 subobject has more than one final overrider the program is ill-formed.
 ``` cpp
 struct A {
   virtual void f();
 };
 struct B : virtual A {
@@ -475,18 +545,26 @@ void foo() {
   c.f();              // calls B::f, the final overrider
   c.C::f();           // calls A::f because of the using-declaration
 }
 ```
 ``` cpp
 struct A { virtual void f(); };
 struct B : A { };
 struct C : A { void f(); };
 struct D : B, C { };  // OK: A::f and C::f are the final overriders
                       // for the B and C subobjects, respectively
 ```
 A virtual member function does not have to be visible to be overridden,
 for example,
 ``` cpp
 struct B {
@@ -504,28 +582,36 @@ the function `f(int)` in class `D` hides the virtual function `f()` in
 its base class `B`; `D::f(int)` is not a virtual function. However,
 `f()` declared in class `D2` has the same name and the same parameter
 list as `B::f()`, and therefore is a virtual function that overrides the
 function `B::f()` even though `B::f()` is not visible in class `D2`.
 If a virtual function `f` in some class `B` is marked with the
 *virt-specifier* `final` and in a class `D` derived from `B` a function
 `D::f` overrides `B::f`, the program is ill-formed.
 ``` cpp
 struct B {
   virtual void f() const final;
 };
 struct D : B {
   void f() const;     // error: D::f attempts to override final B::f
 };
 ```
 If a virtual function is marked with the *virt-specifier* `override` and
 does not override a member function of a base class, the program is
 ill-formed.
 ``` cpp
 struct B {
   virtual void f(int);
 };
@@ -533,10 +619,12 @@ struct D : B {
   virtual void f(long) override;  // error: wrong signature overriding B::f
   virtual void f(int) override;   // OK
 };
 ```
 Even though destructors are not inherited, a destructor in a derived
 class overrides a base class destructor declared virtual; see
 [[class.dtor]] and  [[class.free]].
 The return type of an overriding function shall be either identical to
@@ -561,10 +649,12 @@ that of `B::f`, the class type in the return type of `D::f` shall be
 complete at the point of declaration of `D::f` or shall be the class
 type `D`. When the overriding function is called as the final overrider
 of the overridden function, its result is converted to the type returned
 by the (statically chosen) overridden function ([[expr.call]]).
 ``` cpp
 class B { };
 class D : private B { friend class Derived; };
 struct Base {
   virtual void vf1();
@@ -603,27 +693,32 @@ void g() {
                                 // convert the result to B*
   dp->vf2();                    // ill-formed: argument mismatch
 }
 ```
-The interpretation of the call of a virtual function depends on the type
-of the object for which it is called (the dynamic type), whereas the
-interpretation of a call of a non-virtual member function depends only
-on the type of the pointer or reference denoting that object (the static
-type) ([[expr.call]]).
-The `virtual` specifier implies membership, so a virtual function cannot
-be a nonmember ([[dcl.fct.spec]]) function. Nor can a virtual function
-be a static member, since a virtual function call relies on a specific
-object for determining which function to invoke. A virtual function
-declared in one class can be declared a `friend` in another class.
 A virtual function declared in a class shall be defined, or declared
-pure ([[class.abstract]]) in that class, or both; but no diagnostic is
 required ([[basic.def.odr]]).
-here are some uses of virtual functions with multiple base classes:
 ``` cpp
 struct A {
   virtual void f();
 };
@@ -653,10 +748,14 @@ void foo() {
 In class `D` above there are two occurrences of class `A` and hence two
 occurrences of the virtual member function `A::f`. The final overrider
 of `B1::A::f` is `B1::f` and the final overrider of `B2::A::f` is
 `B2::f`.
 The following example shows a function that does not have a unique final
 overrider:
 ``` cpp
 struct A {
@@ -682,10 +781,14 @@ struct Okay : VB1, VB2 {
 Both `VB1::f` and `VB2::f` override `A::f` but there is no overrider of
 both of them in class `Error`. This example is therefore ill-formed.
 Class `Okay` is well formed, however, because `Okay::f` is a final
 overrider.
 The following example uses the well-formed classes from above.
 ``` cpp
 struct VB1a : virtual A {       // does not declare f
 };
@@ -697,82 +800,105 @@ void foe() {
   VB1a*  vb1ap = new Da;
   vb1ap->f();                   // calls VB2::f
 }
 ```
 Explicit qualification with the scope operator ([[expr.prim]])
 suppresses the virtual call mechanism.
 ``` cpp
 class B { public: virtual void f(); };
 class D : public B { public: void f(); };
-void D::f() { /* ... */ B::f(); }
 ```
 Here, the function call in `D::f` really does call `B::f` and not
 `D::f`.
 A function with a deleted definition ([[dcl.fct.def]]) shall not
 override a function that does not have a deleted definition. Likewise, a
 function that does not have a deleted definition shall not override a
 function with a deleted definition.
 ## Abstract classes <a id="class.abstract">[[class.abstract]]</a>
-The abstract class mechanism supports the notion of a general concept,
-such as a `shape`, of which only more concrete variants, such as
-`circle` and `square`, can actually be used. An abstract class can also
-be used to define an interface for which derived classes provide a
-variety of implementations.
 An *abstract class* is a class that can be used only as a base class of
 some other class; no objects of an abstract class can be created except
 as subobjects of a class derived from it. A class is abstract if it has
-at least one *pure virtual function*. Such a function might be
-inherited: see below. A virtual function is specified *pure* by using a
-*pure-specifier* ([[class.mem]]) in the function declaration in the
-class definition. A pure virtual function need be defined only if called
-with, or as if with ([[class.dtor]]), the *qualified-id* syntax (
-[[expr.prim]]).
 ``` cpp
-class point { /* ... */ };
 class shape {                   // abstract class
   point center;
 public:
   point where() { return center; }
   void move(point p) { center=p; draw(); }
   virtual void rotate(int) = 0; // pure virtual
   virtual void draw() = 0;      // pure virtual
 };
 ```
-A function declaration cannot provide both a *pure-specifier* and a
-definition
 ``` cpp
 struct C {
   virtual void f() = 0 { };     // ill-formed
 };
 ```
 An abstract class shall not be used as a parameter type, as a function
 return type, or as the type of an explicit conversion. Pointers and
 references to an abstract class can be declared.
 ``` cpp
 shape x;                        // error: object of abstract class
 shape* p;                       // OK
 shape f();                      // error
 void g(shape);                  // error
 shape& h(shape&);               // OK
 ```
 A class is abstract if it contains or inherits at least one pure virtual
 function for which the final overrider is pure virtual.
 ``` cpp
 class ab_circle : public shape {
   int radius;
 public:
   void rotate(int) { }
@@ -790,16 +916,18 @@ public:
   void rotate(int) { }
   void draw();                  // a definition is required somewhere
 };
 ```
-would make class `circle` nonabstract and a definition of
 `circle::draw()` must be provided.
-An abstract class can be derived from a class that is not abstract, and
-a pure virtual function may override a virtual function which is not
-pure.
 Member functions can be called from a constructor (or destructor) of an
 abstract class; the effect of making a virtual call ([[class.virtual]])
 to a pure virtual function directly or indirectly for the object being
 created (or destroyed) from such a constructor (or destructor) is

     base-specifier-list ',' base-specifier '...'ₒₚₜ
 ```
 ``` bnf
 base-specifier:
+    attribute-specifier-seqₒₚₜ class-or-decltype
+    attribute-specifier-seqₒₚₜ 'virtual' access-specifierₒₚₜ class-or-decltype
+    attribute-specifier-seqₒₚₜ access-specifier 'virtual'ₒₚₜ class-or-decltype
 ```
 ``` bnf
 class-or-decltype:
     nested-name-specifierₒₚₜ class-name
+    nested-name-specifier 'template' simple-template-id
     decltype-specifier
 ```
 ``` bnf
 access-specifier:
     'private'
     'protected'
     'public'
 ```
 The optional *attribute-specifier-seq* appertains to the
 *base-specifier*.
+A *class-or-decltype* shall denote a class type that is not an
+incompletely defined class (Clause  [[class]]). The class denoted by the
+*class-or-decltype* of a *base-specifier* is called a *direct base
+class* for the class being defined. During the lookup for a base class
+name, non-type names are ignored ([[basic.scope.hiding]]). If the name
+found is not a *class-name*, the program is ill-formed. A class `B` is a
+base class of a class `D` if it is a direct base class of `D` or a
+direct base class of one of `D`’s base classes. A class is an *indirect*
+base class of another if it is a base class but not a direct base class.
+A class is said to be (directly or indirectly) *derived* from its
+(direct or indirect) base classes.
+[*Note 1*: See Clause  [[class.access]] for the meaning of
+*access-specifier*. — *end note*]
+Unless redeclared in the derived class, members of a base class are also
+considered to be members of the derived class. Members of a base class
+other than constructors are said to be *inherited* by the derived class.
+Constructors of a base class can also be inherited as described in
+[[namespace.udecl]]. Inherited members can be referred to in expressions
+in the same manner as other members of the derived class, unless their
+names are hidden or ambiguous ([[class.member.lookup]]).
+[*Note 2*: The scope resolution operator `::` ([[expr.prim]]) can be
+used to refer to a direct or indirect base member explicitly. This
+allows access to a name that has been redeclared in the derived class. A
+derived class can itself serve as a base class subject to access
+control; see  [[class.access.base]]. A pointer to a derived class can be
+implicitly converted to a pointer to an accessible unambiguous base
+class ([[conv.ptr]]). An lvalue of a derived class type can be bound to
+a reference to an accessible unambiguous base class (
+[[dcl.init.ref]]). — *end note*]
 The *base-specifier-list* specifies the type of the *base class
 subobjects* contained in an object of the derived class type.
+[*Example 1*:
 ``` cpp
 struct Base {
   int a, b, c;
 };
 ```
 ```
 Here, an object of class `Derived2` will have a subobject of class
 `Derived` which in turn will have a subobject of class `Base`.
+— *end example*]
 A *base-specifier* followed by an ellipsis is a pack expansion (
 [[temp.variadic]]).
 The order in which the base class subobjects are allocated in the most
+derived object ([[intro.object]]) is unspecified.
+[*Note 3*:  A derived class and its base class subobjects can be
+represented by a directed acyclic graph (DAG) where an arrow means
+“directly derived from”. An arrow need not have a physical
+representation in memory. A DAG of subobjects is often referred to as a
+“subobject lattice”.
 <a id="fig:dag"></a>
 ![Directed acyclic graph \[fig:dag\]](images/figdag.svg)
+ — *end note*]
+[*Note 4*: Initialization of objects representing base classes can be
+specified in constructors; see  [[class.base.init]]. — *end note*]
+[*Note 5*: A base class subobject might have a layout ([[basic.stc]])
+different from the layout of a most derived object of the same type. A
+base class subobject might have a polymorphic behavior (
+[[class.cdtor]]) different from the polymorphic behavior of a most
+derived object of the same type. A base class subobject may be of zero
+size (Clause  [[class]]); however, two subobjects that have the same
+class type and that belong to the same most derived object must not be
+allocated at the same address ([[expr.eq]]). — *end note*]
 ## Multiple base classes <a id="class.mi">[[class.mi]]</a>
+A class can be derived from any number of base classes.
+[*Note 1*: The use of more than one direct base class is often called
+multiple inheritance. — *end note*]
+[*Example 1*:
 ``` cpp
+class A { ... };
+class B { ... };
+class C { ... };
+class D : public A, public B, public C { ... };
 ```
+— *end example*]
+[*Note 2*: The order of derivation is not significant except as
+specified by the semantics of initialization by constructor (
+[[class.base.init]]), cleanup ([[class.dtor]]), and storage layout (
+[[class.mem]],  [[class.access.spec]]). — *end note*]
 A class shall not be specified as a direct base class of a derived class
+more than once.
+[*Note 3*: A class can be an indirect base class more than once and can
+be a direct and an indirect base class. There are limited things that
+can be done with such a class. The non-static data members and member
+functions of the direct base class cannot be referred to in the scope of
+the derived class. However, the static members, enumerations and types
+can be unambiguously referred to. — *end note*]
+[*Example 2*:
 ``` cpp
+class X { ... };
+class Y : public X, public X { ... };             // ill-formed
 ```
 ``` cpp
+class L { public: int next;  ... };
+class A : public L { ... };
+class B : public L { ... };
+class C : public A, public B { void f(); ... };   // well-formed
+class D : public A, public L { void f(); ... };   // well-formed
 ```
+— *end example*]
+A base class specifier that does not contain the keyword `virtual`
+specifies a *non-virtual base class*. A base class specifier that
+contains the keyword `virtual` specifies a *virtual base class*. For
 each distinct occurrence of a non-virtual base class in the class
 lattice of the most derived class, the most derived object (
 [[intro.object]]) shall contain a corresponding distinct base class
 subobject of that type. For each distinct base class that is specified
 virtual, the most derived object shall contain a single base class
+subobject of that type.
+[*Note 4*:
+For an object of class type `C`, each distinct occurrence of a
+(non-virtual) base class `L` in the class lattice of `C` corresponds
+one-to-one with a distinct `L` subobject within the object of type `C`.
+Given the class `C` defined above, an object of class `C` will have two
+subobjects of class `L` as shown in Figure  [[fig:nonvirt]].
 <a id="fig:nonvirt"></a>
 ![Non-virtual base \[fig:nonvirt\]](images/fignonvirt.svg)
 ```
 Without the `A::` or `B::` qualifiers, the definition of `C::f` above
 would be ill-formed because of ambiguity ([[class.member.lookup]]).
+— *end note*]
+[*Note 5*:
+In contrast, consider the case with a virtual base class:
 ``` cpp
+class V { ... };
+class A : virtual public V { ... };
+class B : virtual public V { ... };
+class C : public A, public B { ... };
 ```
 <a id="fig:virt"></a>
 ![Virtual base \[fig:virt\]](images/figvirt.svg)
+For an object `c` of class type `C`, a single subobject of type `V` is
+shared by every base class subobject of `c` that has a `virtual` base
+class of type `V`. Given the class `C` defined above, an object of class
+`C` will have one subobject of class `V`, as shown in Figure
+[[fig:virt]].
+— *end note*]
+[*Note 6*:
 A class can have both virtual and non-virtual base classes of a given
 type.
 ``` cpp
+class B { ... };
+class X : virtual public B { ... };
+class Y : virtual public B { ... };
+class Z : public B { ... };
+class AA : public X, public Y, public Z { ... };
 ```
 For an object of class `AA`, all `virtual` occurrences of base class `B`
 in the class lattice of `AA` correspond to a single `B` subobject within
 the object of type `AA`, and every other occurrence of a (non-virtual)
 base class `B` in the class lattice of `AA` corresponds one-to-one with
 a distinct `B` subobject within the object of type `AA`. Given the class
 `AA` defined above, class `AA` has two subobjects of class `B`: `Z`’s
+`B` and the virtual `B` shared by `X` and `Y`, as shown in Figure
+[[fig:virtnonvirt]].
 <a id="fig:virtnonvirt"></a>
 ![Virtual and non-virtual base \[fig:virtnonvirt\]](images/figvirtnonvirt.svg)
+— *end note*]
 ## Member name lookup <a id="class.member.lookup">[[class.member.lookup]]</a>
 Member name lookup determines the meaning of a name (*id-expression*) in
 a class scope ([[basic.scope.class]]). Name lookup can result in an
 *ambiguity*, in which case the program is ill-formed. For an
 is calculated as follows:
 If `C` contains a declaration of the name `f`, the declaration set
 contains every declaration of `f` declared in `C` that satisfies the
 requirements of the language construct in which the lookup occurs.
+[*Note 1*: Looking up a name in an *elaborated-type-specifier* (
 [[basic.lookup.elab]]) or *base-specifier* (Clause  [[class.derived]]),
 for instance, ignores all non-type declarations, while looking up a name
 in a *nested-name-specifier* ([[basic.lookup.qual]]) ignores function,
 variable, and enumerator declarations. As another example, looking up a
 name in a *using-declaration* ([[namespace.udecl]]) includes the
 declaration of a class or enumeration that would ordinarily be hidden by
+another declaration of that name in the same scope. — *end note*]
+If the resulting declaration set is not empty, the subobject set
+contains `C` itself, and calculation is complete.
 Otherwise (i.e., `C` does not contain a declaration of `f` or the
 resulting declaration set is empty), S(f,C) is initially empty. If `C`
 has base classes, calculate the lookup set for `f` in each direct base
 class subobject Bᵢ, and merge each such lookup set S(f,Bᵢ) in turn into
   declarations and the union of the subobject sets.
 The result of name lookup for `f` in `C` is the declaration set of
 S(f,C). If it is an invalid set, the program is ill-formed.
+[*Example 1*:
 ``` cpp
 struct A { int x; };                    // S(x,A) = { { A::x }, { A } }
 struct B { float x; };                  // S(x,B) = { { B::x }, { B } }
 struct C: public A, public B { };       // S(x,C) = { invalid, { A in C, B in C } }
 struct D: public virtual C { };         // S(x,D) = S(x,C)
   F f;
   f.x = 0;                              // OK, lookup finds E::x
 }
 ```
+S(x,F) is unambiguous because the `A` and `B` base class subobjects of
+`D` are also base class subobjects of `E`, so S(x,D) is discarded in the
+first merge step.
+— *end example*]
+If the name of an overloaded function is unambiguously found, overload
+resolution ([[over.match]]) also takes place before access control.
+Ambiguities can often be resolved by qualifying a name with its class
+name.
+[*Example 2*:
 ``` cpp
 struct A {
   int f();
 };
 struct C : A, B {
   int f() { return A::f() + B::f(); }
 };
 ```
+— *end example*]
+[*Note 2*: A static member, a nested type or an enumerator defined in a
+base class `T` can unambiguously be found even if an object has more
+than one base class subobject of type `T`. Two base class subobjects
+share the non-static member subobjects of their common virtual base
+classes. — *end note*]
+[*Example 3*:
 ``` cpp
 struct V {
   int v;
 };
   int i = pd->e;    // OK: only one e (enumerator)
   pd->a++;          // error, ambiguous: two a{s} in D
 }
 ```
+— *end example*]
+[*Note 3*:  When virtual base classes are used, a hidden declaration
+can be reached along a path through the subobject lattice that does not
+pass through the hiding declaration. This is not an ambiguity. The
+identical use with non-virtual base classes is an ambiguity; in that
+case there is no unique instance of the name that hides all the
+others. — *end note*]
+[*Example 4*:
 ``` cpp
 struct V { int f();  int x; };
 struct W { int g();  int y; };
 struct B : virtual V, W {
   y++;              // error: B::y and C's W::y
   g();              // error: B::g() and C's W::g()
 }
 ```
+— *end example*]
 An explicit or implicit conversion from a pointer to or an expression
 designating an object of a derived class to a pointer or reference to
 one of its base classes shall unambiguously refer to a unique object
 representing the base class.
+[*Example 5*:
 ``` cpp
 struct V { };
 struct A { };
 struct B : A, virtual V { };
 struct C : A, virtual V { };
   A* pa = &d;       // error, ambiguous: C's A or B's A?
   V* pv = &d;       // OK: only one V subobject
 }
 ```
+— *end example*]
+[*Note 4*: Even if the result of name lookup is unambiguous, use of a
+name found in multiple subobjects might still be ambiguous (
+[[conv.mem]],  [[expr.ref]], [[class.access.base]]). — *end note*]
+[*Example 6*:
 ``` cpp
 struct B1 {
   void f();
   static void f(int);
     int D::* mpD = &D::i;       // Ambiguous conversion
   }
 };
 ```
+— *end example*]
 ## Virtual functions <a id="class.virtual">[[class.virtual]]</a>
+[*Note 1*: Virtual functions support dynamic binding and
+object-oriented programming. — *end note*]
+A class that declares or inherits a virtual function is called a
+*polymorphic class*.
 If a virtual member function `vf` is declared in a class `Base` and in a
 class `Derived`, derived directly or indirectly from `Base`, a member
 function `vf` with the same name, parameter-type-list ([[dcl.fct]]),
 cv-qualification, and ref-qualifier (or absence of same) as `Base::vf`
 class ([[intro.object]]) of which `S` is a base class subobject (if
 any) declares or inherits another member function that overrides `vf`.
 In a derived class, if a virtual member function of a base class
 subobject has more than one final overrider the program is ill-formed.
+[*Example 1*:
 ``` cpp
 struct A {
   virtual void f();
 };
 struct B : virtual A {
   c.f();              // calls B::f, the final overrider
   c.C::f();           // calls A::f because of the using-declaration
 }
 ```
+— *end example*]
+[*Example 2*:
 ``` cpp
 struct A { virtual void f(); };
 struct B : A { };
 struct C : A { void f(); };
 struct D : B, C { };  // OK: A::f and C::f are the final overriders
                       // for the B and C subobjects, respectively
 ```
+— *end example*]
+[*Note 2*:
 A virtual member function does not have to be visible to be overridden,
 for example,
 ``` cpp
 struct B {
 its base class `B`; `D::f(int)` is not a virtual function. However,
 `f()` declared in class `D2` has the same name and the same parameter
 list as `B::f()`, and therefore is a virtual function that overrides the
 function `B::f()` even though `B::f()` is not visible in class `D2`.
+— *end note*]
 If a virtual function `f` in some class `B` is marked with the
 *virt-specifier* `final` and in a class `D` derived from `B` a function
 `D::f` overrides `B::f`, the program is ill-formed.
+[*Example 3*:
 ``` cpp
 struct B {
   virtual void f() const final;
 };
 struct D : B {
   void f() const;     // error: D::f attempts to override final B::f
 };
 ```
+— *end example*]
 If a virtual function is marked with the *virt-specifier* `override` and
 does not override a member function of a base class, the program is
 ill-formed.
+[*Example 4*:
 ``` cpp
 struct B {
   virtual void f(int);
 };
   virtual void f(long) override;  // error: wrong signature overriding B::f
   virtual void f(int) override;   // OK
 };
 ```
+— *end example*]
 Even though destructors are not inherited, a destructor in a derived
 class overrides a base class destructor declared virtual; see
 [[class.dtor]] and  [[class.free]].
 The return type of an overriding function shall be either identical to
 complete at the point of declaration of `D::f` or shall be the class
 type `D`. When the overriding function is called as the final overrider
 of the overridden function, its result is converted to the type returned
 by the (statically chosen) overridden function ([[expr.call]]).
+[*Example 5*:
 ``` cpp
 class B { };
 class D : private B { friend class Derived; };
 struct Base {
   virtual void vf1();
                                 // convert the result to B*
   dp->vf2();                    // ill-formed: argument mismatch
 }
 ```
+— *end example*]
+[*Note 3*: The interpretation of the call of a virtual function depends
+on the type of the object for which it is called (the dynamic type),
+whereas the interpretation of a call of a non-virtual member function
+depends only on the type of the pointer or reference denoting that
+object (the static type) ([[expr.call]]). — *end note*]
+[*Note 4*: The `virtual` specifier implies membership, so a virtual
+function cannot be a non-member ([[dcl.fct.spec]]) function. Nor can a
+virtual function be a static member, since a virtual function call
+relies on a specific object for determining which function to invoke. A
+virtual function declared in one class can be declared a `friend` in
+another class. — *end note*]
 A virtual function declared in a class shall be defined, or declared
+pure ([[class.abstract]]) in that class, or both; no diagnostic is
 required ([[basic.def.odr]]).
+[*Example 6*:
+Here are some uses of virtual functions with multiple base classes:
 ``` cpp
 struct A {
   virtual void f();
 };
 In class `D` above there are two occurrences of class `A` and hence two
 occurrences of the virtual member function `A::f`. The final overrider
 of `B1::A::f` is `B1::f` and the final overrider of `B2::A::f` is
 `B2::f`.
+— *end example*]
+[*Example 7*:
 The following example shows a function that does not have a unique final
 overrider:
 ``` cpp
 struct A {
 Both `VB1::f` and `VB2::f` override `A::f` but there is no overrider of
 both of them in class `Error`. This example is therefore ill-formed.
 Class `Okay` is well formed, however, because `Okay::f` is a final
 overrider.
+— *end example*]
+[*Example 8*:
 The following example uses the well-formed classes from above.
 ``` cpp
 struct VB1a : virtual A {       // does not declare f
 };
   VB1a*  vb1ap = new Da;
   vb1ap->f();                   // calls VB2::f
 }
 ```
+— *end example*]
 Explicit qualification with the scope operator ([[expr.prim]])
 suppresses the virtual call mechanism.
+[*Example 9*:
 ``` cpp
 class B { public: virtual void f(); };
 class D : public B { public: void f(); };
+void D::f() { ... B::f(); }
 ```
 Here, the function call in `D::f` really does call `B::f` and not
 `D::f`.
+— *end example*]
 A function with a deleted definition ([[dcl.fct.def]]) shall not
 override a function that does not have a deleted definition. Likewise, a
 function that does not have a deleted definition shall not override a
 function with a deleted definition.
 ## Abstract classes <a id="class.abstract">[[class.abstract]]</a>
+[*Note 1*: The abstract class mechanism supports the notion of a
+general concept, such as a `shape`, of which only more concrete
+variants, such as `circle` and `square`, can actually be used. An
+abstract class can also be used to define an interface for which derived
+classes provide a variety of implementations. — *end note*]
 An *abstract class* is a class that can be used only as a base class of
 some other class; no objects of an abstract class can be created except
 as subobjects of a class derived from it. A class is abstract if it has
+at least one *pure virtual function*.
+[*Note 2*: Such a function might be inherited: see
+below. — *end note*]
+A virtual function is specified *pure* by using a *pure-specifier* (
+[[class.mem]]) in the function declaration in the class definition. A
+pure virtual function need be defined only if called with, or as if
+with ([[class.dtor]]), the *qualified-id* syntax ([[expr.prim]]).
+[*Example 1*:
 ``` cpp
+class point { ... };
 class shape {                   // abstract class
   point center;
 public:
   point where() { return center; }
   void move(point p) { center=p; draw(); }
   virtual void rotate(int) = 0; // pure virtual
   virtual void draw() = 0;      // pure virtual
 };
 ```
+— *end example*]
+[*Note 3*: A function declaration cannot provide both a
+*pure-specifier* and a definition — *end note*]
+[*Example 2*:
 ``` cpp
 struct C {
   virtual void f() = 0 { };     // ill-formed
 };
 ```
+— *end example*]
 An abstract class shall not be used as a parameter type, as a function
 return type, or as the type of an explicit conversion. Pointers and
 references to an abstract class can be declared.
+[*Example 3*:
 ``` cpp
 shape x;                        // error: object of abstract class
 shape* p;                       // OK
 shape f();                      // error
 void g(shape);                  // error
 shape& h(shape&);               // OK
 ```
+— *end example*]
 A class is abstract if it contains or inherits at least one pure virtual
 function for which the final overrider is pure virtual.
+[*Example 4*:
 ``` cpp
 class ab_circle : public shape {
   int radius;
 public:
   void rotate(int) { }
   void rotate(int) { }
   void draw();                  // a definition is required somewhere
 };
 ```
+would make class `circle` non-abstract and a definition of
 `circle::draw()` must be provided.
+— *end example*]
+[*Note 4*: An abstract class can be derived from a class that is not
+abstract, and a pure virtual function may override a virtual function
+which is not pure. — *end note*]
 Member functions can be called from a constructor (or destructor) of an
 abstract class; the effect of making a virtual call ([[class.virtual]])
 to a pure virtual function directly or indirectly for the object being
 created (or destroyed) from such a constructor (or destructor) is

Diff to HTML by rtfpessoa