\rSec0[class.derived]{Derived classes}%

\indextext{derived~class|(}

\indextext{base~class~virtual|see{virtual~base~class}}

\indextext{function, virtual|see{virtual~function}}

\indextext{dynamic binding|see{virtual~function}}

\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}.

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

See Clause~\ref{class.access} for the meaning of

\grammarterm{access-specifier}.

\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}%

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}).

The \grammarterm{base-specifier-list} specifies the type of the

\term{base class subobjects} contained in an

object of the derived class type.

\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}.

A \grammarterm{base-specifier} followed by an ellipsis is a pack

expansion~(\ref{temp.variadic}).

The order in which the base class subobjects are allocated in the most

derived object~(\ref{intro.object}) is unspecified.

\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

\begin{importgraphic}

{Directed acyclic graph}

{fig:dag}

{figdag.pdf}

\end{importgraphic}

The arrows need not have a physical representation in memory.

Initialization of objects representing base classes can be specified in

constructors; see~\ref{class.base.init}.

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}).

\rSec1[class.mi]{Multiple base classes}

\indextext{multiple~inheritance}%

\indextext{base~class}%

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.

\begin{codeblock}

class A { /* ... */ };

class B { /* ... */ };

class C { /* ... */ };

class D : public A, public B, public C { /* ... */ };

\end{codeblock}

\indextext{layout!class~object}%

\indextext{initialization!order~of}%

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}).

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.

\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}

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

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}

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}).

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}

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}

\rSec1[class.member.lookup]{Member name lookup}%

\indextext{lookup!member name}%

\indextext{ambiguity!base~class~member}%

\indextext{ambiguity!member access}

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}).

The following steps define the result of name lookup for a member name

\tcode{f} in a class scope \tcode{C}.

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:

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.

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.

If the resulting declaration set is not empty, the subobject set

contains \tcode{C} itself, and calculation is complete.

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)$.

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}

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.

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

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

\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}

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.

\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}

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

\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}

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.

\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}

\indextext{ambiguity!class conversion}%

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.

\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}

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

\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}

Virtual functions support dynamic binding and object-oriented

programming. A class that declares or inherits a virtual function is

called a \term{polymorphic class}.

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.

\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}

\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}

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

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}

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}

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

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}

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}).

\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}

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}).

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.

\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}%

\indextext{multiple~inheritance!\tcode{virtual}~and}%

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

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.

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}

\indextext{operator!scope~resolution}%

\indextext{virtual~function~call}%

Explicit qualification with the scope operator~(\ref{expr.prim})

suppresses the virtual call mechanism.

\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}.

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}

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.

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

Such a function might be inherited: see below.

\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}).

\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}

A function declaration cannot provide both a \grammarterm{pure-specifier}

and a definition

\begin{codeblock}

struct C {

virtual void f() = 0 { }; // ill-formed

};

\end{codeblock}

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

\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}

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

\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: