File: utility.htm

package info (click to toggle)
boost 1.27.0-3
  • links: PTS
  • area: main
  • in suites: woody
  • size: 19,908 kB
  • ctags: 26,546
  • sloc: cpp: 122,225; ansic: 10,956; python: 4,412; sh: 855; yacc: 803; makefile: 257; perl: 165; lex: 90; csh: 6
file content (150 lines) | stat: -rw-r--r-- 6,535 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
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Header boost/utility.hpp Documentation</title>
</head>

<body bgcolor="#FFFFFF" text="#000000">

<h1><img src="../../c++boost.gif" alt="c++boost.gif (8819 bytes)" align="center" WIDTH="277" HEIGHT="86">Header
<a href="../../boost/utility.hpp">boost/utility.hpp</a></h1>

<p>The entire contents of the header <code><a href="../../boost/utility.hpp">&lt;boost/utility.hpp&gt;</a></code>
 are in <code>namespace boost</code>.</p>

<h2>Contents</h2>

<ul>
  <li>Class templates supporting the <a href="base_from_member.html">base-from-member
    idiom</a></li>
  <li>Function templates <a href="#checked_delete">checked_delete() and
    checked_array_delete()</a></li>
  <li>Function templates <a href="#functions next">next() and prior()</a></li>
  <li>Class <a href="#Class noncopyable">noncopyable</a></li>
  <li>Function template <a href="tie.html">tie()</a> and supporting class tied.</li>
</ul>
<h2> Function templates <a name="checked_delete">checked_delete</a>() and
checked_array_delete()</h2>

<p>Deletion of a pointer to an incomplete type is an unsafe programming practice
because there is no way for the compiler to verify that the destructor is indeed
trivial.&nbsp; The checked_delete() and checked_array_delete() function
templates simply <b>delete</b> or <b>delete[]</b> their argument, but also
require that their argument be a complete type.&nbsp; They issue an appropriate
compiler error diagnostic if that requirement is not met.&nbsp; A typical
implementation is shown; other implementations may vary:</p>

<pre>    template&lt; typename T &gt;
    inline void checked_delete(T const volatile * x)
    {
        BOOST_STATIC_ASSERT( sizeof(T) ); // assert type complete at point
                                          // of instantiation
        delete x;
    }

    template&lt; typename T &gt;
    inline void checked_array_delete(T const volatile * x)
    {
        BOOST_STATIC_ASSERT( sizeof(T) ); // assert type complete at point
                                          // of instantiation
        delete [] x;
    }</pre>

<p>Contributed by Beman Dawes, based on a suggestion from Dave Abrahams,
generalizing an idea from Vladimir Prus, with comments from Rainer Deyke, John
Maddock, and others.</p>

<h3>Background</h3>

<p>The C++ Standard specifies that delete on a pointer to an incomplete types is
undefined behavior if the type has a non-trivial destructor in&nbsp; [expr.delete]
5.3.5 paragraph.&nbsp; No diagnostic is required.&nbsp; Some but not all
compilers issue warnings if the type is incomplete at point of deletion.</p>

<h2> <a name="functions next">Function</a> templates next() and prior()</h2>

<p>Certain data types, such as the C++ Standard Library's forward and
bidirectional iterators, do not provide addition and subtraction via operator+()
or operator-().&nbsp; This means that non-modifying computation of the next or
prior value requires a temporary, even though operator++() or operator--() is
provided.&nbsp; It also means that writing code like <code>itr+1</code> inside a
template restricts the iterator category to random access iterators.</p>

<p>The next() and prior() functions provide a simple way around these problems:</p>

<blockquote>

<pre>template &lt;class T&gt;
T next(T x) { return ++x; }

template &lt;class X&gt;
T prior(T x) { return --x; }</pre>

</blockquote>

<p>Usage is simple:</p>

<blockquote>

<pre>const std::list&lt;T&gt;::iterator p = get_some_iterator();
const std::list&lt;T&gt;::iterator prev = boost::prior(p);</pre>

</blockquote>

<p>Contributed by <a href="../../people/dave_abrahams.htm">Dave Abrahams</a>.</p>

<h2><a name="Class noncopyable">Class noncopyable</a></h2>

<p>Class <strong>noncopyable</strong> is a base class.&nbsp; Derive your own class from <strong>noncopyable</strong>
when you want to prohibit copy construction and copy assignment.</p>

<p>Some objects, particularly those which hold complex resources like files or
network connections, have no sensible copy semantics.&nbsp; Sometimes there are
possible copy semantics, but these would be of very limited usefulness and be
very difficult to implement correctly.&nbsp; Sometimes you're implementing a class that doesn't need to be copied
just yet and you don't want to take the time to write the appropriate functions.&nbsp;
Deriving from <b> noncopyable</b> will prevent the otherwise implicitly-generated
functions (which don't have the proper semantics) from becoming a trap for other programmers.</p>

<p>The traditional way to deal with these is to declare a private copy constructor and copy assignment, and then
document why this is done.&nbsp; But deriving from <b>noncopyable</b> is simpler
and clearer, and doesn't require additional documentation.</p>

<p>The program <a href="noncopyable_test.cpp">noncopyable_test.cpp</a> can be
used to verify class <b>noncopyable</b> works as expected. It has have been run successfully under
GCC 2.95, Metrowerks
CodeWarrior 5.0, and Microsoft Visual C++ 6.0 sp 3.</p>

<p>Contributed by <a href="../../people/dave_abrahams.htm">Dave Abrahams</a>.</p>

<h3>Example</h3>
<blockquote>
  <pre>// inside one of your own headers ...
#include &lt;boost/utility.hpp&gt;

class ResourceLadenFileSystem : boost::noncopyable {
...</pre>
</blockquote>

<h3>Rationale</h3>
<p>Class noncopyable has protected constructor and destructor members to
emphasize that it is to be used only as a base class.&nbsp; Dave Abrahams notes
concern about the effect on compiler optimization of adding (even trivial inline)
destructor declarations. He says &quot;Probably this concern is misplaced, because
noncopyable will be used mostly for classes which own resources and thus have non-trivial destruction semantics.&quot;</p>
<h2>Class templates for the Base-from-Member Idiom</h2>
<p>See <a href="base_from_member.html">separate documentation</a>.</p>
<h2>Function template tie()</h2>
<p>See <a href="tie.html">separate documentation</a>.</p>
<hr>
<p>Revised&nbsp; <!--webbot bot="Timestamp" S-Type="EDITED" S-Format="%d %B, %Y" startspan
-->10 September, 2001<!--webbot bot="Timestamp" endspan i-checksum="39328"
-->
</p>
<p> Copyright boost.org 1999. Permission to copy, use, modify, sell and
distribute this document is granted provided this copyright notice appears in
all copies. This document is provided &quot;as is&quot; without express or
implied warranty, and with no claim as to its suitability for any purpose.</p>
</body>
</html>