File: classtemplates.yo

package info (click to toggle)
c%2B%2B-annotations 13.02.02-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 13,576 kB
  • sloc: cpp: 25,297; makefile: 1,523; ansic: 165; sh: 126; perl: 90; fortran: 27
file content (53 lines) | stat: -rw-r--r-- 3,179 bytes parent folder | download | duplicates (2)
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
In the previous section a function template was defined in a module interface
unit. This section covers the definition of a class template. The class
template tt(SortMap) offers the facilities of an tt(unordered_map), but also
has two tt(sort) members. Both return a vector with pointers to the elements
of the unordered map. One member returns pointers to the elements sorted by
their key values, the other member receives a functor, returning a vector of
pointers to the elements which are sorted according to the functor's
decisions.

The module interface unit defines the tt(SortMap) module. It declares the
class template tt(SortMap). The module, like any module, can be imported in
other source files, like a source file tt(main.cc). The tt(main) function
inserts its arguments into tt(SortMap) and then shows the inserted values:
first ordered by the map's keys, then ordered by the map's values:
    verbinsert(-as4 examples/classtemplate/main.cc)
    When calling tt(a.out one two three four five six) it outputs
 verb(    a.out 0; five 5; four 4; one 1; six 6; three 3; two 2
    a.out 0; one 1; two 2; three 3; four 4; five 5; six 6
 )

All members of class templates are templates, and as with header files
containing class templates there's only one source file defining the module
interface unit: it contains the class template's interface and also the
implementations of its members. There is, however, an escape route: it's
covered in section ref(PARTITIONS). But in this section the standard way to 
implement class templates is covered. 

When using a single file there's maybe one drawback: the module interface
unit, as it must contain the full implementation of the class template, may
quickly grow to a very large file, which is hard to maintain. To simplify
maintenance it is advised to adopt here the em(one function, one file) design
principle also: the module interface unit itself exports the class interface,
and then uses an tt(#include) preprocessor directive to add the class members'
implementations:
    verbinsert(-as4 examples/classtemplate/sortmap/modsortmap.cc)
    The design of the tt(class SortMap) itself is standard. At the top of the
module interface unit the tt(SortMap) module name is defined followed by
importing some module compiled system header files. Since tt(algorithm) is
only used internally by the member functions it's not exported. But imported
components em(must) be specified at the top of module source files, and so
tt(algorithm) cannot be imported by, e.g., tt(sortmap.f). 

The file tt(sortmap.f) itself merely includes the files implementing the two
tt(sort) members, keeping the module interface unit as clean as possible. Here
is tt(sortmap.f):
    verbinsert(-as4 examples/classtemplate/sortmap/sortmap.f)

Each of its included files contain the definition of one member
function. A comment in the class's interface indicates which function is
defined in which file. Here's the first tt(sort) member (tt(sort1.f)):
    verbinsert(-as4 examples/classtemplate/sortmap/sort1.f)
    And here's the second tt(sort) member, accepting a functor (tt(sort2.f))
    verbinsert(-as4 examples/classtemplate/sortmap/sort2.f)