%!TEX root = std.tex
\rSec0[class.derived]{Derived classes}%
\indextext{derived~class|(}

%gram: \rSec1[gram.derived]{Derived classes}
%gram:

\indextext{base~class~virtual|see{virtual~base~class}}
\indextext{function, virtual|see{virtual~function}}
\indextext{dynamic binding|see{virtual~function}}

\pnum
\indextext{base~class}%
\indextext{inheritance}%
\indextext{multiple~inheritance}%
A list of base classes can be specified in a class definition using
the notation:

\begin{bnf}
\nontermdef{base-clause}\br
    \terminal{:} base-specifier-list
\end{bnf}


\begin{bnf}
\nontermdef{base-specifier-list}\br
    base-specifier \terminal{...}\opt\br
    base-specifier-list \terminal{,} base-specifier \terminal{...}\opt
\end{bnf}

\begin{bnf}
\nontermdef{base-specifier}\br
    attribute-specifier-seq\opt base-type-specifier\br
    attribute-specifier-seq\opt \terminal{virtual} access-specifier\opt base-type-specifier\br
    attribute-specifier-seq\opt access-specifier \terminal{virtual}\opt base-type-specifier
\end{bnf}

\begin{bnf}
\nontermdef{class-or-decltype}\br
    nested-name-specifier\opt class-name\br
    decltype-specifier
\end{bnf}

\begin{bnf}
\nontermdef{base-type-specifier}\br
    class-or-decltype
\end{bnf}

\indextext{specifier~access|see{access~specifier}}%
%
\begin{bnf}
\nontermdef{access-specifier}\br
    \terminal{private}\br
    \terminal{protected}\br
    \terminal{public}
\end{bnf}

The optional \grammarterm{attribute-specifier-seq} appertains to the \grammarterm{base-specifier}.

\pnum
\indextext{type!incomplete}%
The type denoted by a \grammarterm{base-type-specifier} shall be
a class type that is not
an
incompletely defined class (Clause~\ref{class}); this class is called a
\indextext{base~class!direct}%
\term{direct base class}
for the class being defined.
\indextext{base~class}%
\indextext{derivation|see{inheritance}}%
During the lookup for a base class name, non-type names are
ignored~(\ref{basic.scope.hiding}). If the name found is not a
\grammarterm{class-name}, the program is ill-formed. A class \tcode{B} is a
base class of a class \tcode{D} if it is a direct base class of
\tcode{D} or a direct base class of one of \tcode{D}'s base classes.
\indextext{base~class!indirect}%
A class is an \term{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) \term{derived} from its (direct or indirect) base
classes.
\enternote
See Clause~\ref{class.access} for the meaning of
\grammarterm{access-specifier}.
\exitnote
\indextext{access control!base~class member}%
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
\indextext{inheritance}%
\term{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~(\ref{class.member.lookup}).
\indextext{operator!scope~resolution}%
\enternote
The scope resolution operator \tcode{::}~(\ref{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~\ref{class.access.base}. A pointer to a derived class can be
implicitly converted to a pointer to an accessible unambiguous base
class~(\ref{conv.ptr}). An lvalue of a derived class type can be bound
to a reference to an accessible unambiguous base
class~(\ref{dcl.init.ref}).
\exitnote

\pnum
The \grammarterm{base-specifier-list} specifies the type of the
\term{base class subobjects} contained in an
object of the derived class type.
\enterexample
\indextext{example!derived~class}%
\begin{codeblock}
struct Base {
  int a, b, c;
};
\end{codeblock}

\begin{codeblock}
struct Derived : Base {
  int b;
};
\end{codeblock}

\begin{codeblock}
struct Derived2 : Derived {
  int c;
};
\end{codeblock}

Here, an object of class \tcode{Derived2} will have a subobject of class
\tcode{Derived} which in turn will have a subobject of class
\tcode{Base}.
\exitexample

\pnum
A \grammarterm{base-specifier} followed by an ellipsis is a pack
expansion~(\ref{temp.variadic}).

\pnum
The order in which the base class subobjects are allocated in the most
derived object~(\ref{intro.object}) is unspecified.
\enternote
\indextext{directed~acyclic~graph|see{DAG}}%
\indextext{lattice|see{DAG, subobject}}%
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.''

\begin{importgraphic}
{Directed acyclic graph}
{fig:dag}
{figdag.pdf}
\end{importgraphic}

\pnum
The arrows need not have a physical representation in memory.
\exitnote

\pnum
\enternote
Initialization of objects representing base classes can be specified in
constructors; see~\ref{class.base.init}.
\exitnote

\pnum
\enternote
A base class subobject might have a layout~(\ref{basic.stc}) different
from the layout of a most derived object of the same type. A base class
subobject might have a polymorphic behavior~(\ref{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~\ref{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~(\ref{expr.eq}).
\exitnote

\rSec1[class.mi]{Multiple base classes}
\indextext{multiple~inheritance}%
\indextext{base~class}%

\pnum
A class can be derived from any number of base classes.
\enternote
The use of more than one direct base class is often called multiple inheritance.
\exitnote
\enterexample
\begin{codeblock}
class A { /* ... */ };
class B { /* ... */ };
class C { /* ... */ };
class D : public A, public B, public C { /* ... */ };
\end{codeblock}
\exitexample

\pnum
\indextext{layout!class~object}%
\indextext{initialization!order~of}%
\enternote
The order of derivation is not significant except as specified by the
semantics of initialization by constructor~(\ref{class.base.init}),
cleanup~(\ref{class.dtor}), and storage
layout~(\ref{class.mem},~\ref{class.access.spec}).
\exitnote

\pnum
A class shall not be specified as a direct base class of a derived class
more than once.
\enternote
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.
\exitnote
\enterexample
\begin{codeblock}
class X { /* ... */ };
class Y : public X, public X { /* ... */ };             // ill-formed

\end{codeblock}
\begin{codeblock}
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{codeblock}
\exitexample

\pnum
\indextext{virtual~base~class}%
A base class specifier that does not contain the keyword
\tcode{virtual}, specifies a \grammarterm{non-virtual} base class. A base
class specifier that contains the keyword \tcode{virtual}, specifies a
\term{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~(\ref{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.
\enterexample
for an object of class type \tcode{C}, each distinct occurrence of a
(non-virtual) base class \tcode{L} in the class lattice of \tcode{C}
corresponds one-to-one with a distinct \tcode{L} subobject within the
object of type \tcode{C}. Given the class \tcode{C} defined above, an
object of class \tcode{C} will have two subobjects of class \tcode{L} as
shown below.

\begin{importgraphic}
{Non-virtual base}
{fig:nonvirt}
{fignonvirt.pdf}
\end{importgraphic}

\pnum
In such lattices, explicit qualification can be used to specify which
subobject is meant. The body of function \tcode{C::f} could refer to the
member \tcode{next} of each \tcode{L} subobject:
\begin{codeblock}
void C::f() { A::next = B::next; }      // well-formed
\end{codeblock}
Without the \tcode{A::} or \tcode{B::} qualifiers, the definition of
\tcode{C::f} above would be ill-formed because of
ambiguity~(\ref{class.member.lookup}).

\pnum
For another example,
\begin{codeblock}
class V { /* ... */ };
class A : virtual public V { /* ... */ };
class B : virtual public V { /* ... */ };
class C : public A, public B { /* ... */ };
\end{codeblock}
for an object \tcode{c} of class type \tcode{C}, a single subobject of
type \tcode{V} is shared by every base subobject of \tcode{c} that has a
\tcode{virtual} base class of type \tcode{V}. Given the class \tcode{C}
defined above, an object of class \tcode{C} will have one subobject of
class \tcode{V}, as shown below.

\indextext{DAG!multiple~inheritance}%
\indextext{DAG!virtual~base~class}%
\begin{importgraphic}
{Virtual base}
{fig:virt}
{figvirt.pdf}
\end{importgraphic}


\pnum
A class can have both virtual and non-virtual base classes of a given
type.
\begin{codeblock}
class B { /* ... */ };
class X : virtual public B { /* ... */ };
class Y : virtual public B { /* ... */ };
class Z : public B { /* ... */ };
class AA : public X, public Y, public Z { /* ... */ };
\end{codeblock}
For an object of class \tcode{AA}, all \tcode{virtual} occurrences of
base class \tcode{B} in the class lattice of \tcode{AA} correspond to a
single \tcode{B} subobject within the object of type \tcode{AA}, and
every other occurrence of a (non-virtual) base class \tcode{B} in the
class lattice of \tcode{AA} corresponds one-to-one with a distinct
\tcode{B} subobject within the object of type \tcode{AA}. Given the
class \tcode{AA} defined above, class \tcode{AA} has two subobjects of
class \tcode{B}: \tcode{Z}'s \tcode{B} and the virtual \tcode{B} shared
by \tcode{X} and \tcode{Y}, as shown below.

\indextext{DAG!virtual~base~class}%
\indextext{DAG!non-virtual~base~class}%
\indextext{DAG!multiple~inheritance}%
\begin{importgraphic}
{Virtual and non-virtual base}
{fig:virtnonvirt}
{figvirtnonvirt.pdf}
\end{importgraphic}

\exitexample

\rSec1[class.member.lookup]{Member name lookup}%
\indextext{lookup!member name}%
\indextext{ambiguity!base~class~member}%
\indextext{ambiguity!member access}

\pnum
Member name lookup determines the meaning of a name
(\grammarterm{id-expression}) in a class scope~(\ref{basic.scope.class}).
Name lookup can result in an \term{ambiguity}, in which case the
program is ill-formed. For an \grammarterm{id-expression}, name lookup
begins in the class scope of \tcode{this}; for a
\grammarterm{qualified-id}, name lookup begins in the scope of the
\grammarterm{nested-name-specifier}. Name lookup takes place before access
control~(\ref{basic.lookup}, Clause~\ref{class.access}).

\pnum
The following steps define the result of name lookup for a member name
\tcode{f} in a class scope \tcode{C}.

\pnum
The \term{lookup set} for \tcode{f} in \tcode{C}, called $S(f,C)$,
consists of two component sets: the \term{declaration set}, a set of
members named \tcode{f}; and the \term{subobject set}, a set of
subobjects where declarations of these members (possibly including
\grammarterm{using-declaration}{s}) were found. In the declaration set,
\grammarterm{using-declaration}{s} are replaced by the
set of designated members that are not hidden or overridden by members of the
derived class~(\ref{namespace.udecl}),
and type declarations (including injected-class-names) are
replaced by the types they designate. $S(f,C)$ is calculated as follows:

\pnum
If \tcode{C} contains a declaration of the name \tcode{f}, the
declaration set contains every declaration of \tcode{f} declared in
\tcode{C} that satisfies the requirements of the language construct in
which the lookup occurs.
\enternote
Looking up a name in an
\grammarterm{elaborated-type-specifier}~(\ref{basic.lookup.elab}) or
\grammarterm{base-specifier} (Clause~\ref{class.derived}), for instance,
ignores all non-type declarations, while looking up a name in a
\grammarterm{nested-name-specifier}~(\ref{basic.lookup.qual}) ignores
function, variable, and enumerator declarations. As another example,
looking up a name in a
\grammarterm{using-declaration}~(\ref{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.
\exitnote
If the resulting declaration set is not empty, the subobject set
contains \tcode{C} itself, and calculation is complete.

\pnum
Otherwise (i.e., \tcode{C} does not contain a declaration of \tcode{f}
or the resulting declaration set is empty), $S(f,C)$ is initially empty.
If \tcode{C} has base classes, calculate the lookup set for \tcode{f} in
each direct base class subobject $B_i$, and merge each such lookup set
$S(f,B_i)$ in turn into $S(f,C)$.

\pnum
The following steps define the result of merging lookup set $S(f,B_i)$
into the intermediate $S(f,C)$:

\begin{itemize}
\item If each of the subobject members of $S(f,B_i)$ is a base class
subobject of at least one of the subobject members of $S(f,C)$, or if
$S(f,B_i)$ is empty, $S(f,C)$ is unchanged and the merge is complete.
Conversely, if each of the subobject members of $S(f,C)$ is a base class
subobject of at least one of the subobject members of $S(f,B_i)$, or if
$S(f,C)$ is empty, the new $S(f,C)$ is a copy of $S(f,B_i)$.

\item Otherwise, if the declaration sets of $S(f,B_i)$ and $S(f,C)$
differ, the merge is ambiguous: the new $S(f,C)$ is a lookup set with an
invalid declaration set and the union of the subobject sets. In
subsequent merges, an invalid declaration set is considered different
from any other.

\item Otherwise, the new $S(f,C)$ is a lookup set with the shared set of
declarations and the union of the subobject sets.
\end{itemize}

\pnum
The result of name lookup for \tcode{f} in \tcode{C} is the declaration
set of $S(f,C)$. If it is an invalid set, the program is ill-formed.
\enterexample
\begin{codeblock}
struct A { int x; };                    // S(x,A) = \{ \{ \tcode{A::x} \}, \{ \tcode{A} \} \}
struct B { float x; };                  // S(x,B) = \{ \{ \tcode{B::x} \}, \{ \tcode{B} \} \}
struct C: public A, public B { };       // S(x,C) = \{ invalid, \{ \tcode{A} in \tcode{C}, \tcode{B} in \tcode{C} \} \}
struct D: public virtual C { };         // S(x,D) = S(x,C)
struct E: public virtual C { char x; }; // S(x,E) = \{ \{ \tcode{E::x} \}, \{ \tcode{E} \} \}
struct F: public D, public E { };       // S(x,F) = S(x,E)
int main() {
  F f;
  f.x = 0;                              // OK, lookup finds \tcode{E::x}
}
\end{codeblock}

$S(x,F)$ is unambiguous because the \tcode{A} and \tcode{B} base
subobjects of \tcode{D} are also base subobjects of \tcode{E}, so
$S(x,D)$ is discarded in the first merge step.
\exitexample

\pnum
\indextext{access~control!overloading~resolution~and}%
If the name of an overloaded function is unambiguously found,
overloading resolution~(\ref{over.match}) also takes place before access
control.
\indextext{example!scope~resolution operator}%
\indextext{example!explicit~qualification}%
\indextext{overloading!resolution!scoping ambiguity}%
Ambiguities can often be resolved by qualifying a name with its class name.
\enterexample
\begin{codeblock}
struct A {
  int f();
};

\end{codeblock}
\begin{codeblock}
struct B {
  int f();
};

\end{codeblock}
\begin{codeblock}
struct C : A, B {
  int f() { return A::f() + B::f(); }
};
\end{codeblock}
\exitexample

\pnum
\enternote
A static member, a nested type or an enumerator defined in a base class
\tcode{T} can unambiguously be found even if an object has more than one
base class subobject of type \tcode{T}. Two base class subobjects share
the non-static member subobjects of their common virtual base classes.
\exitnote
\enterexample
\begin{codeblock}
struct V {
  int v;
};
struct A {
  int a;
  static int   s;
  enum { e };
};
struct B : A, virtual V { };
struct C : A, virtual V { };
struct D : B, C { };

void f(D* pd) {
  pd->v++;          // OK: only one \tcode{v} (virtual)
  pd->s++;          // OK: only one \tcode{s} (static)
  int i = pd->e;    // OK: only one \tcode{e} (enumerator)
  pd->a++;          // error, ambiguous: two \tcode{a}{s} in \tcode{D}
}
\end{codeblock}
\exitexample

\pnum
\enternote
\indextext{dominance!virtual~base~class}%
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.
\exitnote
\enterexample
\begin{codeblock}
struct V { int f();  int x; };
struct W { int g();  int y; };
struct B : virtual V, W {
  int f();  int x;
  int g();  int y;
};
struct C : virtual V, W { };

struct D : B, C { void glorp(); };
\end{codeblock}

\begin{importgraphic}
{Name lookup}
{fig:name}
{figname.pdf}
\end{importgraphic}

\pnum
\enternote
The names declared in \tcode{V} and the left-hand instance of \tcode{W}
are hidden by those in \tcode{B}, but the names declared in the
right-hand instance of \tcode{W} are not hidden at all.
\exitnote
\begin{codeblock}
void D::glorp() {
  x++;              // OK: \tcode{B::x} hides \tcode{V::x}
  f();              // OK: \tcode{B::f()} hides \tcode{V::f()}
  y++;              // error: \tcode{B::y} and \tcode{C}'s \tcode{W::y}
  g();              // error: \tcode{B::g()} and \tcode{C}'s \tcode{W::g()}
}
\end{codeblock}
\exitexample
\indextext{ambiguity!class conversion}%

\pnum
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.
\enterexample
\begin{codeblock}
struct V { };
struct A { };
struct B : A, virtual V { };
struct C : A, virtual V { };
struct D : B, C { };

void g() {
  D d;
  B* pb = &d;
  A* pa = &d;       // error, ambiguous: \tcode{C}'s \tcode{A} or \tcode{B}'s \tcode{A}?
  V* pv = &d;       // OK: only one \tcode{V} subobject
}
\end{codeblock}
\exitexample

\pnum
\enternote
Even if the result of name lookup is unambiguous, use of a name found in
multiple subobjects might still be
ambiguous~(\ref{conv.mem},~\ref{expr.ref}, \ref{class.access.base}).\exitnote
\enterexample
\begin{codeblock}
struct B1 {
  void f();
  static void f(int);
  int i;
};
struct B2 {
  void f(double);
};
struct I1: B1 { };
struct I2: B1 { };

struct D: I1, I2, B2 {
  using B1::f;
  using B2::f;
  void g() {
    f();                        // Ambiguous conversion of \tcode{this}
    f(0);                       // Unambiguous (static)
    f(0.0);                     // Unambiguous (only one \tcode{B2})
    int B1::* mpB1 = &D::i;     // Unambiguous
    int D::* mpD = &D::i;       // Ambiguous conversion
  }
};
\end{codeblock}\exitexample

\rSec1[class.virtual]{Virtual functions}%
\indextext{virtual~function|(}%
\indextext{type!polymorphic}%
\indextext{class!polymorphic}

\pnum
Virtual functions support dynamic binding and object-oriented
programming. A class that declares or inherits a virtual function is
called a \term{polymorphic class}.

\pnum
If a virtual member function \tcode{vf} is declared in a class
\tcode{Base} and in a class \tcode{Derived}, derived directly or
indirectly from \tcode{Base}, a member function \tcode{vf} with the same
name, parameter-type-list~(\ref{dcl.fct}), cv-qualification, and ref-qualifier
(or absence of same) as
\tcode{Base::vf} is declared, then \tcode{Derived::vf} is also virtual
(whether or not it is so declared) and it \term{overrides}\footnote{A function with the same name but a different parameter list
(Clause~\ref{over}) as a virtual function is not necessarily virtual and
does not override. The use of the \tcode{virtual} specifier in the
declaration of an overriding function is legal but redundant (has empty
semantics). Access control (Clause~\ref{class.access}) is not considered in
determining overriding.}
\tcode{Base::vf}. For convenience we say that any virtual function
overrides itself.
\indextext{overrider!final}%
A virtual member function \tcode{C::vf} of a class object \tcode{S} is a \defn{final
overrider} unless the most derived class~(\ref{intro.object}) of which \tcode{S} is a
base class subobject (if any) declares or inherits another member function that overrides
\tcode{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.
\enterexample
\begin{codeblock}
struct A {
  virtual void f();
};
struct B : virtual A {
  virtual void f();
};
struct C : B , virtual A {
  using A::f;
};

void foo() {
  C c;
  c.f();              // calls \tcode{B::f}, the final overrider
  c.C::f();           // calls \tcode{A::f} because of the using-declaration
}
\end{codeblock}
\exitexample

\enterexample
\begin{codeblock}
struct A { virtual void f(); };
struct B : A { };
struct C : A { void f(); };
struct D : B, C { };  // OK: \tcode{A::f} and \tcode{C::f} are the final overriders
                      // for the \tcode{B} and \tcode{C} subobjects, respectively
\end{codeblock}
\exitexample

\pnum
\enternote
A virtual member function does not have to be visible to be overridden,
for example,
\begin{codeblock}
struct B {
  virtual void f();
};
struct D : B {
  void f(int);
};
struct D2 : D {
  void f();
};
\end{codeblock}
the function \tcode{f(int)} in class \tcode{D} hides the virtual
function \tcode{f()} in its base class \tcode{B}; \tcode{D::f(int)} is
not a virtual function. However, \tcode{f()} declared in class
\tcode{D2} has the same name and the same parameter list as
\tcode{B::f()}, and therefore is a virtual function that overrides the
function \tcode{B::f()} even though \tcode{B::f()} is not visible in
class \tcode{D2}.
\exitnote

\pnum
If a virtual function \tcode{f} in some class \tcode{B} is marked with the
\grammarterm{virt-specifier} \tcode{final} and in a class \tcode{D} derived from \tcode{B}
a function \tcode{D::f} overrides \tcode{B::f}, the program is ill-formed. \enterexample
\begin{codeblock}
struct B {
  virtual void f() const final;
};

struct D : B {
  void f() const;     // error: \tcode{D::f} attempts to override \tcode{final} \tcode{B::f}
};
\end{codeblock}
\exitexample

\pnum
If a virtual function is marked with the \grammarterm{virt-specifier} \tcode{override} and
does not override a member function of a base class, the program is ill-formed. \enterexample
\begin{codeblock}
struct B {
  virtual void f(int);
};

struct D : B {
  virtual void f(long) override;  // error: wrong signature overriding \tcode{B::f}
  virtual void f(int) override;   // OK
};
\end{codeblock}
\exitexample

\pnum
Even though destructors are not inherited, a destructor in a derived
class overrides a base class destructor declared virtual;
see~\ref{class.dtor} and~\ref{class.free}.

\pnum
The return type of an overriding function shall be either identical to
the return type of the overridden function or \term{covariant} with
the classes of the functions. If a function \tcode{D::f} overrides a
function \tcode{B::f}, the return types of the functions are covariant
if they satisfy the following criteria:
\begin{itemize}
\item both are pointers to classes, both are lvalue references to
classes, or both are rvalue references to classes\footnote{Multi-level pointers to classes or references to multi-level pointers to
classes are not allowed.% 
}

\item the class in the return type of \tcode{B::f} is the same class as
the class in the return type of \tcode{D::f}, or is an unambiguous and
accessible direct or indirect base class of the class in the return type
of \tcode{D::f}

\item both pointers or references have the same cv-qualification and the
class type in the return type of \tcode{D::f} has the same
cv-qualification as or less cv-qualification than the class type in the
return type of \tcode{B::f}.
\end{itemize}

\pnum
If the class type in the covariant return type of \tcode{D::f} differs from that of
\tcode{B::f}, the class type in the return type of \tcode{D::f} shall be
complete at the point of declaration of \tcode{D::f} or shall be the
class type \tcode{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~(\ref{expr.call}).
\enterexample
\indextext{example!virtual~function}%
\begin{codeblock}
class B { };
class D : private B { friend class Derived; };
struct Base {
  virtual void vf1();
  virtual void vf2();
  virtual void vf3();
  virtual B*   vf4();
  virtual B*   vf5();
  void f();
};

struct No_good : public Base {
  D*  vf4();        // error: \tcode{B} (base class of \tcode{D}) inaccessible
};

class A;
struct Derived : public Base {
    void vf1();     // virtual and overrides \tcode{Base::vf1()}
    void vf2(int);  // not virtual, hides \tcode{Base::vf2()}
    char vf3();     // error: invalid difference in return type only
    D*  vf4();      // OK: returns pointer to derived class
    A*  vf5();      // error: returns pointer to incomplete class
    void f();
};

void g() {
  Derived d;
  Base* bp = &d;                // standard conversion:
                                // \tcode{Derived*} to \tcode{Base*}
  bp->vf1();                    // calls \tcode{Derived::vf1()}
  bp->vf2();                    // calls \tcode{Base::vf2()}
  bp->f();                      // calls \tcode{Base::f()} (not virtual)
  B*  p = bp->vf4();            // calls \tcode{Derived::pf()} and converts the
                                // result to \tcode{B*}
  Derived*  dp = &d;
  D*  q = dp->vf4();            // calls \tcode{Derived::pf()} and does not
                                // convert the result to \tcode{B*}
  dp->vf2();                    // ill-formed: argument mismatch
}
\end{codeblock}
\exitexample

\pnum
\enternote
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)~(\ref{expr.call}).
\exitnote

\pnum
\enternote
The \tcode{virtual} specifier implies membership, so a virtual function
cannot be a nonmember~(\ref{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 \tcode{friend} in
another class.
\exitnote

\pnum
\indextext{definition!virtual~function}%
A virtual function declared in a class shall be defined, or declared
pure~(\ref{class.abstract}) in that class, or both; but no diagnostic is
required~(\ref{basic.def.odr}).
\indextext{friend!\tcode{virtual}~and}%

\pnum
\indextext{multiple~inheritance!\tcode{virtual}~and}%
\enterexample
here are some uses of virtual functions with multiple base classes:
\indextext{example!virtual~function}%
\begin{codeblock}
struct A {
  virtual void f();
};

struct B1 : A {                 // note non-virtual derivation
  void f();
};

struct B2 : A {
  void f();
};

struct D : B1, B2 {             // \tcode{D} has two separate \tcode{A} subobjects
};

void foo() {
  D   d;
//\tcode{   A*  ap = \&d;}                  // would be ill-formed: ambiguous
  B1*  b1p = &d;
  A*   ap = b1p;
  D*   dp = &d;
  ap->f();                      // calls \tcode{D::B1::f}
  dp->f();                      // ill-formed: ambiguous
}
\end{codeblock}
In class \tcode{D} above there are two occurrences of class \tcode{A}
and hence two occurrences of the virtual member function \tcode{A::f}.
The final overrider of \tcode{B1::A::f} is \tcode{B1::f} and the final
overrider of \tcode{B2::A::f} is \tcode{B2::f}.

\pnum
The following example shows a function that does not have a unique final
overrider:
\begin{codeblock}
struct A {
  virtual void f();
};

struct VB1 : virtual A {        // note virtual derivation
  void f();
};

struct VB2 : virtual A {
  void f();
};

struct Error : VB1, VB2 {       // ill-formed
};

struct Okay : VB1, VB2 {
  void f();
};
\end{codeblock}
Both \tcode{VB1::f} and \tcode{VB2::f} override \tcode{A::f} but there
is no overrider of both of them in class \tcode{Error}. This example is
therefore ill-formed. Class \tcode{Okay} is well formed, however,
because \tcode{Okay::f} is a final overrider.

\pnum
The following example uses the well-formed classes from above.
\begin{codeblock}
struct VB1a : virtual A {       // does not declare \tcode{f}
};

struct Da : VB1a, VB2 {
};

void foe() {
  VB1a*  vb1ap = new Da;
  vb1ap->f();                   // calls \tcode{VB2::f}
}
\end{codeblock}
\exitexample

\pnum
\indextext{operator!scope~resolution}%
\indextext{virtual~function~call}%
Explicit qualification with the scope operator~(\ref{expr.prim})
suppresses the virtual call mechanism.
\enterexample
\begin{codeblock}
class B { public: virtual void f(); };
class D : public B { public: void f(); };

void D::f() { /* ... */ B::f(); }
\end{codeblock}

Here, the function call in
\tcode{D::f}
really does call
\tcode{B::f}
and not
\tcode{D::f}.
\exitexample

\pnum
A function with a deleted definition~(\ref{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.%
\indextext{virtual~function|)}

\rSec1[class.abstract]{Abstract classes}%
\indextext{class!abstract}

\pnum
The abstract class mechanism supports the notion of a general concept,
such as a \tcode{shape}, of which only more concrete variants, such as
\tcode{circle} and \tcode{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.

\pnum
An \term{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 \term{pure virtual function}.
\enternote
Such a function might be inherited: see below.
\exitnote
\indextext{virtual~function!pure}%
A virtual function is specified \term{pure} by using a
\grammarterm{pure-specifier}~(\ref{class.mem}) in the function declaration
in the class definition.
\indextext{definition!pure virtual~function}%
A pure virtual function need be defined only if called with, or as if
with~(\ref{class.dtor}), the \grammarterm{qualified-id}
syntax~(\ref{expr.prim}).
\enterexample
\indextext{example!pure virtual~function}%
\begin{codeblock}
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{codeblock}
\exitexample
\enternote
A function declaration cannot provide both a \grammarterm{pure-specifier}
and a definition
\exitnote
\enterexample
\begin{codeblock}
struct C {
  virtual void f() = 0 { };     // ill-formed
};
\end{codeblock}
\exitexample

\pnum
\indextext{class!pointer~to abstract}%
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.
\enterexample
\begin{codeblock}
shape x;                        // error: object of abstract class
shape* p;                       // OK
shape f();                      // error
void g(shape);                  // error
shape& h(shape&);               // OK
\end{codeblock}
\exitexample

\pnum
\indextext{virtual~function!pure}%
A class is abstract if it contains or inherits at least one pure virtual
function for which the final overrider is pure virtual.
\enterexample
\begin{codeblock}
class ab_circle : public shape {
  int radius;
public:
  void rotate(int) { }
  // \tcode{ab_circle::draw()} is a pure virtual
};
\end{codeblock}

Since \tcode{shape::draw()} is a pure virtual function
\tcode{ab_circle::draw()} is a pure virtual by default. The alternative
declaration,
\begin{codeblock}
class circle : public shape {
  int radius;
public:
  void rotate(int) { }
  void draw();                  // a definition is required somewhere
};
\end{codeblock}
would make class \tcode{circle} nonabstract and a definition of
\tcode{circle::draw()} must be provided.
\exitexample

\pnum
\enternote
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.
\exitnote

\pnum
\indextext{class!constructor~and abstract}%
Member functions can be called from a constructor (or destructor) of an
abstract class;
\indextext{virtual~function~call!undefined pure}%
the effect of making a virtual call~(\ref{class.virtual}) to a pure
virtual function directly or indirectly for the object being created (or
destroyed) from such a constructor (or destructor) is undefined.%
\indextext{derived~class|)}
