File: style.html

package info (click to toggle)
boost 1.32.0-6
  • links: PTS
  • area: main
  • in suites: sarge
  • size: 93,952 kB
  • ctags: 128,458
  • sloc: cpp: 492,477; xml: 52,125; python: 13,519; ansic: 13,013; sh: 1,773; yacc: 853; makefile: 526; perl: 418; lex: 110; csh: 6
file content (126 lines) | stat: -rw-r--r-- 4,757 bytes parent folder | download
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
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
    <title>Boost.Range Terminology and Style Guidelines </title>
    <link rel="stylesheet" href="style.css" type="text/css">
</head>

    <body>

    <table border="0" >
        <tr>
            <td ><img src="../../../boost.png" border="0" ></td>
            <td ><h1 align="center">Boost.Range </h1></td>
        </tr>
    </table>

    <h2>Terminology and style guidelines </h2>

    <p>
    The use of a consistent terminology is as important for <a href="range.html#range">Range</a>s 
    and range-based algorithms as it is for iterators and iterator-based algorithms. 
    If a conventional set of names are adopted, we can avoid misunderstandings and 
    write generic function prototypes that are <i>self-documenting</i>.
    </p>

    <p>
    Since ranges are characterized by a specific underlying iterator type, we get a 
    type of range for each type of iterator. Hence we can speak of the following 
    types of ranges:
    <ul>
        <li>
            <i>Value access</i> category:
            <ul>
                <li>
                    Readable Range
                <li>
                    Writeable Range
                <li>
                    Swappable Range
                <li>
                    Lvalue Range
            </ul>
        <li>
            <i>Traversal</i> category:
            <ul>
                <li>
                    <a href="range.html#single_pass_range">Single Pass Range</a>
                <li>
                    <a href="range.html#forward_range">Forward Range</a>
                <li>
                    <a href="range.html#bidirectional_range">Bidirectional Range</a> <li>
                    <a href="range.html#random_access_range">Random Access Range</a> </ul>
    </ul>
    Notice how we have used the categories from the <a href=../../iterator/doc/new-iter-concepts.html>new 
    style iterators</a>.

    <p>
    Notice that an iterator (and therefore an range) has one <i>traversal</i> 
    property and one or more properties from the <i>value access</i> category. So in 
    reality we will mostly talk about mixtures such as
    <ul>
        <li>
            Random Access Readable Writeable Range
        <li>
            Forward Lvalue Range
    </ul>
    By convention, we should always specify the <i>traversal</i> property first as 
    done above. This seems reasonable since there will only be one <i>traversal</i> 
    property, but perhaps many <i>value access</i> properties.
    </p>

    <p>
    It might, however, be reasonable to specify only one category if the other 
    category does not matter. For example, the <a
   href="utility_class.html#iter_range">iterator_range</a> can be constructed from 
   a Forward Range. This means that we do not care about what <i>value access</i> 
   properties the Range has. Similarly, a Readable Range will be one that has the 
   lowest possible <i>traversal</i> property (Single Pass).
    </p>

    <p>
    As another example, consider how we specify the interface of <code>std::sort()</code>. 
    Algorithms are usually more cumbersome to specify the interface of since both <i>traversal</i> 
    and <i>value access</i> properties must be exactly defined. The iterator-based 
        version looks like this:

    <pre>
   <span class=keyword>template</span><span class=special>&lt; </span><span class=keyword>class </span><span class=identifier>RandomAccessTraversalReadableWritableIterator </span><span class=special>&gt;
   </span><span class=keyword>void </span><span class=identifier>sort</span><span class=special>( </span><span class=identifier>RandomAccessTraversalReadableWritableIterator </span><span class=identifier>first</span><span class=special>,
              </span><span class=identifier>RandomAccessTraversalReadableWritableIterator </span><span class=identifier>last </span><span class=special>);</span>
   </pre>
    For ranges the interface becomes

    <pre>
   <span class=keyword>template</span><span class=special>&lt; </span><span class=keyword>class </span><span class=identifier>RandomAccessReadableWritableRange </span><span class=special>&gt;
   </span><span class=keyword>void </span><span class=identifier>sort</span><span class=special>( </span><span class=identifier>RandomAccessReadableWritableRange</span><span class=special>&amp; </span><span class=identifier>r </span><span class=special>);</span>
   </pre>
    </p>
    <p>

    </p>

    <hr>
    <p>
    (C) Copyright Thorsten Ottosen 2003-2004
    </p>

    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>
    <br>


    </body>
</html>