1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
|
When a class is nested within a class template, it automatically becomes a
class template itself.
hi(class template: nested)
The nested class may use the template parameters of the surrounding
class, as shown by the following skeleton program. Within a class
tt(PtrVector), a class tt(iterator) is defined. The nested class receives its
information from its surrounding class, a tt(PtrVector<Type>) class. Since
this surrounding class should be the only class constructing its iterators,
tt(iterator)'s constructor is made i(private) and the surrounding class is
given access to the private members of tt(iterator) using a
emi(bound friend) declaration.
Here is the initial section of tt(PtrVector)'s class interface:
verbinclude(//HEAD examples/nesting1.cc)
This shows that the tt(std::vector) base class stores pointers to tt(Type)
values, rather than the values themselves. Of course, a destructor is now
required as the (externally allocated) memory for the tt(Type) objects must
eventually be freed. Alternatively, the allocation might be part of
tt(PtrVector)'s tasks, when it stores new elements. Here it is assumed that
tt(PtrVector)'s clients do the required allocations and that the destructor is
implemented later on.
The nested class defines its constructor as a private member, and allows
tt(PtrVector<Type>) objects access to its private members. Therefore only
objects of the surrounding tt(PtrVector<Type>) class type are allowed to
construct their tt(iterator) objects. However, tt(PtrVector<Type>)'s clients
may construct em(copies) of the tt(PtrVector<Type>::iterator) objects they
use.
Here is the nested class tt(iterator), using a (required) tt(friend)
declaration. Note the use of the tt(typename) keyword: since
tt(std::vector<Type *>::iterator) depends on a template parameter, it is not
yet an instantiated class. Therefore tt(iterator) becomes an implicit
typename. The compiler issues a warning if tt(typename) has been
omitted. Here is the class interface:
verbinclude(//ITER examples/nesting1.cc)
The implementation of the members shows that the base class's tt(begin)
member is called to initialize tt(d_begin). tt(PtrVector<Type>::begin)'s
return type must again be preceded by tt(typename):
verbinclude(//ITERIMP examples/nesting1.cc)
The remainder of the class is simple. Omitting all other functions that
might be implemented, the function tt(begin) returns a newly constructed
tt(PtrVector<Type>::iterator) object. It may call the constructor since the
class tt(iterator) declared its surrounding class as its friend:
verbinclude(//BEGIN examples/nesting1.cc)
Here is a simple skeleton program, showing how the nested class
tt(iterator) might be used:
verbinclude(//MAIN examples/nesting1.cc)
Nested hi(enumeration: nested) enumerations and hi(typedefs: nested)
hi(using: nested) nested typedefs and using declarations can also be defined
by class templates. The class tt(Table), mentioned before (section
ref(TFROMC)) inherited the enumeration tt(TableType::FillDirection). Had
tt(Table) been implemented as a full class template, then this enumeration
would have been defined in tt(Table) itself as:
verb( template <typename Iterator>
class Table: public TableType
{
public:
enum FillDirection
{
HORIZONTAL,
VERTICAL
};
...
};)
In this case, the actual value of the template type parameter must be
specified when referring to a tt(FillDirection) value or to its type. For
example (assuming tt(iter) and tt(nCols) are defined as in section
ref(TFROMC)):
verb( Table<istream_iterator<string> >::FillDirection direction =
argc == 2 ?
Table<istream_iterator<string> >::VERTICAL
:
Table<istream_iterator<string> >::HORIZONTAL;
Table<istream_iterator<string> >
table(iter, istream_iterator<string>(), nCols, direction);)
|
