1<html> 2<head> 3<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII"> 4<title>Development</title> 5<link rel="stylesheet" href="../../../../../doc/src/boostbook.css" type="text/css"> 6<meta name="generator" content="DocBook XSL Stylesheets V1.78.1"> 7<link rel="home" href="../index.html" title="Chapter 1. Boost.Optional"> 8<link rel="up" href="../index.html" title="Chapter 1. Boost.Optional"> 9<link rel="prev" href="tutorial.html" title="Tutorial"> 10<link rel="next" href="synopsis.html" title="Synopsis"> 11</head> 12<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"> 13<table cellpadding="2" width="100%"><tr> 14<td valign="top"><img alt="Boost C++ Libraries" width="277" height="86" src="../../../../../boost.png"></td> 15<td align="center"><a href="../../../../../index.html">Home</a></td> 16<td align="center"><a href="../../../../../libs/libraries.htm">Libraries</a></td> 17<td align="center"><a href="http://www.boost.org/users/people.html">People</a></td> 18<td align="center"><a href="http://www.boost.org/users/faq.html">FAQ</a></td> 19<td align="center"><a href="../../../../../more/index.htm">More</a></td> 20</tr></table> 21<hr> 22<div class="spirit-nav"> 23<a accesskey="p" href="tutorial.html"><img src="../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../index.html"><img src="../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="synopsis.html"><img src="../../../../../doc/src/images/next.png" alt="Next"></a> 24</div> 25<div class="section"> 26<div class="titlepage"><div><div><h2 class="title" style="clear: both"> 27<a name="boost_optional.development"></a><a class="link" href="development.html" title="Development">Development</a> 28</h2></div></div></div> 29<div class="toc"><dl class="toc"> 30<dt><span class="section"><a href="development.html#boost_optional.development.the_models">The models</a></span></dt> 31<dt><span class="section"><a href="development.html#boost_optional.development.the_semantics">The semantics</a></span></dt> 32<dt><span class="section"><a href="development.html#boost_optional.development.the_interface">The Interface</a></span></dt> 33</dl></div> 34<div class="section"> 35<div class="titlepage"><div><div><h3 class="title"> 36<a name="boost_optional.development.the_models"></a><a class="link" href="development.html#boost_optional.development.the_models" title="The models">The models</a> 37</h3></div></div></div> 38<p> 39 In C++, we can <span class="emphasis"><em>declare</em></span> an object (a variable) of type 40 <code class="computeroutput"><span class="identifier">T</span></code>, and we can give this variable 41 an <span class="emphasis"><em>initial value</em></span> (through an <span class="emphasis"><em>initializer</em></span>. 42 (cf. 8.5)). When a declaration includes a non-empty initializer (an initial 43 value is given), it is said that the object has been initialized. If the 44 declaration uses an empty initializer (no initial value is given), and neither 45 default nor value initialization applies, it is said that the object is 46 <span class="bold"><strong>uninitialized</strong></span>. Its actual value exist but 47 has an <span class="emphasis"><em>indeterminate initial value</em></span> (cf. 8.5/11). <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> intends 48 to formalize the notion of initialization (or lack of it) allowing a program 49 to test whether an object has been initialized and stating that access to 50 the value of an uninitialized object is undefined behavior. That is, when 51 a variable is declared as <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> 52 and no initial value is given, the variable is <span class="emphasis"><em>formally</em></span> 53 uninitialized. A formally uninitialized optional object has conceptually 54 no value at all and this situation can be tested at runtime. It is formally 55 <span class="emphasis"><em>undefined behavior</em></span> to try to access the value of an 56 uninitialized optional. An uninitialized optional can be assigned a value, 57 in which case its initialization state changes to initialized. Furthermore, 58 given the formal treatment of initialization states in optional objects, 59 it is even possible to reset an optional to <span class="emphasis"><em>uninitialized</em></span>. 60 </p> 61<p> 62 In C++ there is no formal notion of uninitialized objects, which means that 63 objects always have an initial value even if indeterminate. As discussed 64 on the previous section, this has a drawback because you need additional 65 information to tell if an object has been effectively initialized. One of 66 the typical ways in which this has been historically dealt with is via a 67 special value: <code class="computeroutput"><span class="identifier">EOF</span></code>, <code class="computeroutput"><span class="identifier">npos</span></code>, -1, etc... This is equivalent to 68 adding the special value to the set of possible values of a given type. This 69 super set of <code class="computeroutput"><span class="identifier">T</span></code> plus some 70 <span class="emphasis"><em>nil_t</em></span>—where <code class="computeroutput"><span class="identifier">nil_t</span></code> 71 is some stateless POD—can be modeled in modern languages as a <span class="bold"><strong>discriminated union</strong></span> of T and nil_t. Discriminated 72 unions are often called <span class="emphasis"><em>variants</em></span>. A variant has a <span class="emphasis"><em>current 73 type</em></span>, which in our case is either <code class="computeroutput"><span class="identifier">T</span></code> 74 or <code class="computeroutput"><span class="identifier">nil_t</span></code>. Using the <a href="../../../../variant/index.html" target="_top">Boost.Variant</a> library, this model 75 can be implemented in terms of <code class="computeroutput"><span class="identifier">boost</span><span class="special">::</span><span class="identifier">variant</span><span class="special"><</span><span class="identifier">T</span><span class="special">,</span><span class="identifier">nil_t</span><span class="special">></span></code>. 76 There is precedent for a discriminated union as a model for an optional value: 77 the <a href="http://www.haskell.org/" target="_top">Haskell</a> <span class="bold"><strong>Maybe</strong></span> 78 built-in type constructor. Thus, a discriminated union <code class="computeroutput"><span class="identifier">T</span><span class="special">+</span><span class="identifier">nil_t</span></code> 79 serves as a conceptual foundation. 80 </p> 81<p> 82 A <code class="computeroutput"><span class="identifier">variant</span><span class="special"><</span><span class="identifier">T</span><span class="special">,</span><span class="identifier">nil_t</span><span class="special">></span></code> follows naturally from the traditional 83 idiom of extending the range of possible values adding an additional sentinel 84 value with the special meaning of <span class="emphasis"><em>Nothing</em></span>. However, 85 this additional <span class="emphasis"><em>Nothing</em></span> value is largely irrelevant 86 for our purpose since our goal is to formalize the notion of uninitialized 87 objects and, while a special extended value can be used to convey that meaning, 88 it is not strictly necessary in order to do so. 89 </p> 90<p> 91 The observation made in the last paragraph about the irrelevant nature of 92 the additional <code class="computeroutput"><span class="identifier">nil_t</span></code> with 93 respect to <span class="underline">purpose</span> of <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> suggests 94 an alternative model: a <span class="emphasis"><em>container</em></span> that either has a 95 value of <code class="computeroutput"><span class="identifier">T</span></code> or nothing. 96 </p> 97<p> 98 As of this writing I don't know of any precedent for a variable-size fixed-capacity 99 (of 1) stack-based container model for optional values, yet I believe this 100 is the consequence of the lack of practical implementations of such a container 101 rather than an inherent shortcoming of the container model. 102 </p> 103<p> 104 In any event, both the discriminated-union or the single-element container 105 models serve as a conceptual ground for a class representing optional—i.e. 106 possibly uninitialized—objects. For instance, these models show the <span class="emphasis"><em>exact</em></span> 107 semantics required for a wrapper of optional values: 108 </p> 109<p> 110 Discriminated-union: 111 </p> 112<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "> 113<li class="listitem"> 114 <span class="bold"><strong>deep-copy</strong></span> semantics: copies of the variant 115 implies copies of the value. 116 </li> 117<li class="listitem"> 118 <span class="bold"><strong>deep-relational</strong></span> semantics: comparisons 119 between variants matches both current types and values 120 </li> 121<li class="listitem"> 122 If the variant's current type is <code class="computeroutput"><span class="identifier">T</span></code>, 123 it is modeling an <span class="emphasis"><em>initialized</em></span> optional. 124 </li> 125<li class="listitem"> 126 If the variant's current type is not <code class="computeroutput"><span class="identifier">T</span></code>, 127 it is modeling an <span class="emphasis"><em>uninitialized</em></span> optional. 128 </li> 129<li class="listitem"> 130 Testing if the variant's current type is <code class="computeroutput"><span class="identifier">T</span></code> 131 models testing if the optional is initialized 132 </li> 133<li class="listitem"> 134 Trying to extract a <code class="computeroutput"><span class="identifier">T</span></code> 135 from a variant when its current type is not <code class="computeroutput"><span class="identifier">T</span></code>, 136 models the undefined behavior of trying to access the value of an uninitialized 137 optional 138 </li> 139</ul></div> 140<p> 141 Single-element container: 142 </p> 143<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "> 144<li class="listitem"> 145 <span class="bold"><strong>deep-copy</strong></span> semantics: copies of the container 146 implies copies of the value. 147 </li> 148<li class="listitem"> 149 <span class="bold"><strong>deep-relational</strong></span> semantics: comparisons 150 between containers compare container size and if match, contained value 151 </li> 152<li class="listitem"> 153 If the container is not empty (contains an object of type <code class="computeroutput"><span class="identifier">T</span></code>), it is modeling an <span class="emphasis"><em>initialized</em></span> 154 optional. 155 </li> 156<li class="listitem"> 157 If the container is empty, it is modeling an <span class="emphasis"><em>uninitialized</em></span> 158 optional. 159 </li> 160<li class="listitem"> 161 Testing if the container is empty models testing if the optional is initialized 162 </li> 163<li class="listitem"> 164 Trying to extract a <code class="computeroutput"><span class="identifier">T</span></code> 165 from an empty container models the undefined behavior of trying to access 166 the value of an uninitialized optional 167 </li> 168</ul></div> 169</div> 170<div class="section"> 171<div class="titlepage"><div><div><h3 class="title"> 172<a name="boost_optional.development.the_semantics"></a><a class="link" href="development.html#boost_optional.development.the_semantics" title="The semantics">The semantics</a> 173</h3></div></div></div> 174<p> 175 Objects of type <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> 176 are intended to be used in places where objects of type <code class="computeroutput"><span class="identifier">T</span></code> 177 would but which might be uninitialized. Hence, <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code>'s 178 purpose is to formalize the additional possibly uninitialized state. From 179 the perspective of this role, <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> 180 can have the same operational semantics of <code class="computeroutput"><span class="identifier">T</span></code> 181 plus the additional semantics corresponding to this special state. As such, 182 <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> could 183 be thought of as a <span class="emphasis"><em>supertype</em></span> of <code class="computeroutput"><span class="identifier">T</span></code>. 184 Of course, we can't do that in C++, so we need to compose the desired semantics 185 using a different mechanism. Doing it the other way around, that is, making 186 <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> a 187 <span class="emphasis"><em>subtype</em></span> of <code class="computeroutput"><span class="identifier">T</span></code> 188 is not only conceptually wrong but also impractical: it is not allowed to 189 derive from a non-class type, such as a built-in type. 190 </p> 191<p> 192 We can draw from the purpose of <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> 193 the required basic semantics: 194 </p> 195<div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "> 196<li class="listitem"> 197 <span class="bold"><strong>Default Construction:</strong></span> To introduce a 198 formally uninitialized wrapped object. 199 </li> 200<li class="listitem"> 201 <span class="bold"><strong>Direct Value Construction via copy:</strong></span> 202 To introduce a formally initialized wrapped object whose value is obtained 203 as a copy of some object. 204 </li> 205<li class="listitem"> 206 <span class="bold"><strong>Deep Copy Construction:</strong></span> To obtain a 207 new yet equivalent wrapped object. 208 </li> 209<li class="listitem"> 210 <span class="bold"><strong>Direct Value Assignment (upon initialized):</strong></span> 211 To assign a value to the wrapped object. 212 </li> 213<li class="listitem"> 214 <span class="bold"><strong>Direct Value Assignment (upon uninitialized):</strong></span> 215 To initialize the wrapped object with a value obtained as a copy of some 216 object. 217 </li> 218<li class="listitem"> 219 <span class="bold"><strong>Assignment (upon initialized):</strong></span> To assign 220 to the wrapped object the value of another wrapped object. 221 </li> 222<li class="listitem"> 223 <span class="bold"><strong>Assignment (upon uninitialized):</strong></span> To 224 initialize the wrapped object with value of another wrapped object. 225 </li> 226<li class="listitem"> 227 <span class="bold"><strong>Deep Relational Operations (when supported by the 228 type T):</strong></span> To compare wrapped object values taking into account 229 the presence of uninitialized states. 230 </li> 231<li class="listitem"> 232 <span class="bold"><strong>Value access:</strong></span> To unwrap the wrapped 233 object. 234 </li> 235<li class="listitem"> 236 <span class="bold"><strong>Initialization state query:</strong></span> To determine 237 if the object is formally initialized or not. 238 </li> 239<li class="listitem"> 240 <span class="bold"><strong>Swap:</strong></span> To exchange wrapped objects. (with 241 whatever exception safety guarantees are provided by <code class="computeroutput"><span class="identifier">T</span></code>'s 242 swap). 243 </li> 244<li class="listitem"> 245 <span class="bold"><strong>De-initialization:</strong></span> To release the wrapped 246 object (if any) and leave the wrapper in the uninitialized state. 247 </li> 248</ul></div> 249<p> 250 Additional operations are useful, such as converting constructors and converting 251 assignments, in-place construction and assignment, and safe value access 252 via a pointer to the wrapped object or null. 253 </p> 254</div> 255<div class="section"> 256<div class="titlepage"><div><div><h3 class="title"> 257<a name="boost_optional.development.the_interface"></a><a class="link" href="development.html#boost_optional.development.the_interface" title="The Interface">The Interface</a> 258</h3></div></div></div> 259<p> 260 Since the purpose of optional is to allow us to use objects with a formal 261 uninitialized additional state, the interface could try to follow the interface 262 of the underlying <code class="computeroutput"><span class="identifier">T</span></code> type 263 as much as possible. In order to choose the proper degree of adoption of 264 the native <code class="computeroutput"><span class="identifier">T</span></code> interface, the 265 following must be noted: Even if all the operations supported by an instance 266 of type <code class="computeroutput"><span class="identifier">T</span></code> are defined for 267 the entire range of values for such a type, an <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> 268 extends such a set of values with a new value for which most (otherwise valid) 269 operations are not defined in terms of <code class="computeroutput"><span class="identifier">T</span></code>. 270 </p> 271<p> 272 Furthermore, since <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> 273 itself is merely a <code class="computeroutput"><span class="identifier">T</span></code> wrapper 274 (modeling a <code class="computeroutput"><span class="identifier">T</span></code> supertype), 275 any attempt to define such operations upon uninitialized optionals will be 276 totally artificial w.r.t. <code class="computeroutput"><span class="identifier">T</span></code>. 277 </p> 278<p> 279 This library chooses an interface which follows from <code class="computeroutput"><span class="identifier">T</span></code>'s 280 interface only for those operations which are well defined (w.r.t the type 281 <code class="computeroutput"><span class="identifier">T</span></code>) even if any of the operands 282 are uninitialized. These operations include: construction, copy-construction, 283 assignment, swap and relational operations. 284 </p> 285<p> 286 For the value access operations, which are undefined (w.r.t the type <code class="computeroutput"><span class="identifier">T</span></code>) when the operand is uninitialized, a 287 different interface is chosen (which will be explained next). 288 </p> 289<p> 290 Also, the presence of the possibly uninitialized state requires additional 291 operations not provided by <code class="computeroutput"><span class="identifier">T</span></code> 292 itself which are supported by a special interface. 293 </p> 294<h5> 295<a name="boost_optional.development.the_interface.h0"></a> 296 <span class="phrase"><a name="boost_optional.development.the_interface.lexically_hinted_value_access_in_the_presence_of_possibly_untitialized_optional_objects__the_operators___and___gt_"></a></span><a class="link" href="development.html#boost_optional.development.the_interface.lexically_hinted_value_access_in_the_presence_of_possibly_untitialized_optional_objects__the_operators___and___gt_">Lexically-hinted 297 Value Access in the presence of possibly untitialized optional objects: The 298 operators * and -></a> 299 </h5> 300<p> 301 A relevant feature of a pointer is that it can have a <span class="bold"><strong>null 302 pointer value</strong></span>. This is a <span class="emphasis"><em>special</em></span> value which 303 is used to indicate that the pointer is not referring to any object at all. 304 In other words, null pointer values convey the notion of nonexistent objects. 305 </p> 306<p> 307 This meaning of the null pointer value allowed pointers to became a <span class="emphasis"><em>de 308 facto</em></span> standard for handling optional objects because all you have 309 to do to refer to a value which you don't really have is to use a null pointer 310 value of the appropriate type. Pointers have been used for decades—from 311 the days of C APIs to modern C++ libraries—to <span class="emphasis"><em>refer</em></span> 312 to optional (that is, possibly nonexistent) objects; particularly as optional 313 arguments to a function, but also quite often as optional data members. 314 </p> 315<p> 316 The possible presence of a null pointer value makes the operations that access 317 the pointee's value possibly undefined, therefore, expressions which use 318 dereference and access operators, such as: <code class="computeroutput"><span class="special">(</span> 319 <span class="special">*</span><span class="identifier">p</span> <span class="special">=</span> <span class="number">2</span> <span class="special">)</span></code> 320 and <code class="computeroutput"><span class="special">(</span> <span class="identifier">p</span><span class="special">-></span><span class="identifier">foo</span><span class="special">()</span> <span class="special">)</span></code>, implicitly 321 convey the notion of optionality, and this information is tied to the <span class="emphasis"><em>syntax</em></span> 322 of the expressions. That is, the presence of operators <code class="computeroutput"><span class="special">*</span></code> 323 and <code class="computeroutput"><span class="special">-></span></code> tell by themselves 324 —without any additional context— that the expression will be undefined 325 unless the implied pointee actually exist. 326 </p> 327<p> 328 Such a <span class="emphasis"><em>de facto</em></span> idiom for referring to optional objects 329 can be formalized in the form of a concept: the <a href="../../../../utility/OptionalPointee.html" target="_top">OptionalPointee</a> 330 concept. This concept captures the syntactic usage of operators <code class="computeroutput"><span class="special">*</span></code>, <code class="computeroutput"><span class="special">-></span></code> 331 and contextual conversion to <code class="computeroutput"><span class="keyword">bool</span></code> 332 to convey the notion of optionality. 333 </p> 334<p> 335 However, pointers are good to <span class="underline">refer</span> 336 to optional objects, but not particularly good to handle the optional objects 337 in all other respects, such as initializing or moving/copying them. The problem 338 resides in the shallow-copy of pointer semantics: if you need to effectively 339 move or copy the object, pointers alone are not enough. The problem is that 340 copies of pointers do not imply copies of pointees. For example, as was discussed 341 in the motivation, pointers alone cannot be used to return optional objects 342 from a function because the object must move outside from the function and 343 into the caller's context. 344 </p> 345<p> 346 A solution to the shallow-copy problem that is often used is to resort to 347 dynamic allocation and use a smart pointer to automatically handle the details 348 of this. For example, if a function is to optionally return an object <code class="computeroutput"><span class="identifier">X</span></code>, it can use <code class="computeroutput"><span class="identifier">shared_ptr</span><span class="special"><</span><span class="identifier">X</span><span class="special">></span></code> 349 as the return value. However, this requires dynamic allocation of <code class="computeroutput"><span class="identifier">X</span></code>. If <code class="computeroutput"><span class="identifier">X</span></code> 350 is a built-in or small POD, this technique is very poor in terms of required 351 resources. Optional objects are essentially values so it is very convenient 352 to be able to use automatic storage and deep-copy semantics to manipulate 353 optional values just as we do with ordinary values. Pointers do not have 354 this semantics, so are inappropriate for the initialization and transport 355 of optional values, yet are quite convenient for handling the access to the 356 possible undefined value because of the idiomatic aid present in the <a href="../../../../utility/OptionalPointee.html" target="_top">OptionalPointee</a> concept 357 incarnated by pointers. 358 </p> 359<h5> 360<a name="boost_optional.development.the_interface.h1"></a> 361 <span class="phrase"><a name="boost_optional.development.the_interface.optional_lt_t_gt__as_a_model_of_optionalpointee"></a></span><a class="link" href="development.html#boost_optional.development.the_interface.optional_lt_t_gt__as_a_model_of_optionalpointee">Optional<T> 362 as a model of OptionalPointee</a> 363 </h5> 364<p> 365 For value access operations <code class="computeroutput"><span class="identifier">optional</span><span class="special"><></span></code> uses operators <code class="computeroutput"><span class="special">*</span></code> 366 and <code class="computeroutput"><span class="special">-></span></code> to lexically warn 367 about the possibly uninitialized state appealing to the familiar pointer 368 semantics w.r.t. to null pointers. 369 </p> 370<div class="warning"><table border="0" summary="Warning"> 371<tr> 372<td rowspan="2" align="center" valign="top" width="25"><img alt="[Warning]" src="../../../../../doc/src/images/warning.png"></td> 373<th align="left">Warning</th> 374</tr> 375<tr><td align="left" valign="top"><p> 376 However, it is particularly important to note that <code class="computeroutput"><span class="identifier">optional</span><span class="special"><></span></code> objects are not pointers. <span class="underline"><code class="computeroutput"><span class="identifier">optional</span><span class="special"><></span></code> is not, and does not model, a pointer</span>. 377 </p></td></tr> 378</table></div> 379<p> 380 For instance, <code class="computeroutput"><span class="identifier">optional</span><span class="special"><></span></code> 381 does not have shallow-copy so does not alias: two different optionals never 382 refer to the <span class="emphasis"><em>same</em></span> value unless <code class="computeroutput"><span class="identifier">T</span></code> 383 itself is a reference (but may have <span class="emphasis"><em>equivalent</em></span> values). 384 The difference between an <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> 385 and a pointer must be kept in mind, particularly because the semantics of 386 relational operators are different: since <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> 387 is a value-wrapper, relational operators are deep: they compare optional 388 values; but relational operators for pointers are shallow: they do not compare 389 pointee values. As a result, you might be able to replace <code class="computeroutput"><span class="identifier">optional</span><span class="special"><</span><span class="identifier">T</span><span class="special">></span></code> 390 by <code class="computeroutput"><span class="identifier">T</span><span class="special">*</span></code> 391 on some situations but not always. Specifically, on generic code written 392 for both, you cannot use relational operators directly, and must use the 393 template functions <a href="../../../../utility/OptionalPointee.html#equal" target="_top"><code class="computeroutput"><span class="identifier">equal_pointees</span><span class="special">()</span></code></a> 394 and <a href="../../../../utility/OptionalPointee.html#less" target="_top"><code class="computeroutput"><span class="identifier">less_pointees</span><span class="special">()</span></code></a> 395 instead. 396 </p> 397</div> 398</div> 399<table xmlns:rev="http://www.cs.rpi.edu/~gregod/boost/tools/doc/revision" width="100%"><tr> 400<td align="left"></td> 401<td align="right"><div class="copyright-footer">Copyright © 2003-2007 Fernando Luis Cacciola Carballal<br>Copyright © 2014 Andrzej Krzemieński<p> 402 Distributed under the Boost Software License, Version 1.0. (See accompanying 403 file LICENSE_1_0.txt or copy at <a href="http://www.boost.org/LICENSE_1_0.txt" target="_top">http://www.boost.org/LICENSE_1_0.txt</a>) 404 </p> 405</div></td> 406</tr></table> 407<hr> 408<div class="spirit-nav"> 409<a accesskey="p" href="tutorial.html"><img src="../../../../../doc/src/images/prev.png" alt="Prev"></a><a accesskey="u" href="../index.html"><img src="../../../../../doc/src/images/up.png" alt="Up"></a><a accesskey="h" href="../index.html"><img src="../../../../../doc/src/images/home.png" alt="Home"></a><a accesskey="n" href="synopsis.html"><img src="../../../../../doc/src/images/next.png" alt="Next"></a> 410</div> 411</body> 412</html> 413
