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 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502
|
++++++++++++++++++++++++++++++++++
|Boost| Pointer Container Library
++++++++++++++++++++++++++++++++++
.. |Boost| image:: boost.png
=========
Reference
=========
The documentation is divided into a an explanation for
each container. When containers have the same interface, that common interface is explained only once,
but links are always provided to more relevant information.
Please make sure you understand
the `Clonable <reference.html#the-clonable-concept>`_ concept and
the `Clone Allocator <reference.html#the-clone-allocator-concept>`_ concept.
- `Conventions <conventions.html>`_
- `The Clonable concept`_
- `The Clone Allocator concept`_
- `Class hierarchy`_:
- `reversible_ptr_container <reversible_ptr_container.html>`_
- `ptr_sequence_adapter <ptr_sequence_adapter.html>`_
- `ptr_vector <ptr_vector.html>`_
- `ptr_list <ptr_list.html>`_
- `ptr_deque <ptr_deque.html>`_
- `ptr_array <ptr_array.html>`_
- `associative_ptr_container <associative_ptr_container.html>`_
- `ptr_set_adapter <ptr_set_adapter.html>`_
- `ptr_multiset_adapter <ptr_multiset_adapter.html>`_
- `ptr_map_adapter <ptr_map_adapter.html>`_
- `ptr_multi_map_adapter <ptr_multimap_adapter.html>`_
- `ptr_set <ptr_set.html>`_
- `ptr_multi_set <ptr_multiset.html>`_
- `ptr_map <ptr_map.html>`_
- `ptr_multimap <ptr_multimap.html>`_
- `Serialization`_
- `Indirected functions <indirect_fun.html>`_
- `Class nullable`_
- `Exception classes`_
- `Disabling the use of exceptions`_
..
- Class `reversible_ptr_container <reversible_ptr_container.html>`_
- Class `associative_ptr_container <associative_ptr_container.html>`_
- `Pointer container adapters`_
- `ptr_sequence_adapter <ptr_sequence_adapter.html>`_
- `ptr_set_adapter <ptr_set_adapter.html>`_
- `ptr_multiset_adapter <ptr_multiset_adapter.html>`_
- `ptr_map_adapter <ptr_map_adapter.html>`_
- `ptr_multimap_adapter <ptr_multimap_adapter.html>`_
- `Sequence containers`_
- `ptr_vector <ptr_vector.html>`_
- `ptr_deque <ptr_deque.html>`_
- `ptr_list <ptr_list.html>`_
- `ptr_array <ptr_array.html>`_
- `Associative containers`_
- `ptr_set <ptr_set.html>`_
- `ptr_multiset <ptr_multiset.html>`_
- `ptr_map <ptr_map.html>`_
- `ptr_multimap <ptr_multimap.html>`_
The Clonable concept
++++++++++++++++++++
**Refinement of**
- Heap Allocable
- Heap Deallocable
The Clonable concept is introduced to formalize the requirements for
copying heap-allocated objects. A type ``T`` might be Clonable even though it
is not Assignable or Copy Constructible. Notice that many operations on
the containers does not even require the stored type to be Clonable.
**Notation**
======================= ============================================ =================== =====================
**Type** **Object** (``const`` or non-``const``) **Pointer** **Describes**
``T`` ``a`` ``ptr`` A Clonable type
======================= ============================================ =================== =====================
**Valid expressions**
===================================== =========================== ======================================================================================== ===================================
**Expression** **Type** **Semantics** **Postcondition**
``new_clone(a);`` ``T*`` Allocate a new object that can be considered equivalent to the ``a`` object ``typeid(*new_clone(a)) == typeid(a)``
``delete_clone(ptr);`` ``void`` Deallocate an object previously allocated with ``allocate_clone()``. Must not throw
===================================== =========================== ======================================================================================== ===================================
Default implementation
----------------------
In the ``<boost/ptr_container/clone_allocator.hpp>`` header a default implementation
of the two functions is given:
.. parsed-literal::
namespace boost
{
template< class T >
inline T* new_clone( const T& t )
{
return new T( t );
}
template< class T >
void delete_clone( const T* t )
{
checked_delete( r );
}
}
Notice that this implementation makes normal Copy Constructible classes are automatically
Clonable unless ``operator new()`` or ``operator delete()`` are hidden.
The two functions represent a layer of indirection which is necessary to support
classes that are not Copy Constructible by default. Notice that the implementation
relies on argument-dependent lookup (ADL) to find the right version of
``new_clone()`` and ``delete_clone()``. This means that one does not need to overload or specialize
the function is the boost namespace, but it can be placed together with
the rest of the interface of the class. If you are implementing a class
inline in headers, remember to forward declare the functions.
**Warning: We are considering to remove the default implementation above. Therefore always make sure that you overload the functions for your types and do not rely on the defaults in any way.**
The Clone Allocator concept
+++++++++++++++++++++++++++
The Clone Allocator concept is introduced to formalize the way
pointer containers controls memory of
the stored objects (and not the pointers to the stored objects).
The clone allocator allows
users to apply custom allocators/deallocators for the cloned objects.
More information can be found below:
.. contents:: :depth: 1
:local:
Clone Allocator requirements
----------------------------
**Notation**
===================== ============================================= ==================================================
**Type** **Object** (``const`` or non-``const``) **Describes**
``T`` ``a`` A type
``T*`` ``ptr`` A pointer to ``T``
===================== ============================================= ==================================================
**Valid expressions**
============================================== ============= ============================================================================= =============================================================
**Expression** **Type** **Semantics** **Postcondition**
``CloneAllocator::allocate_clone(a);`` ``T*`` Allocate a new object that can be considered equivalent to the
``a`` object ``typeid(*CloneAllocator::allocate_clone(a)) == typeid(a)``
``CloneAllocator::deallocate_clone(ptr);`` ``void`` Deallocate an object previously allocated with
``CloneAllocator::allocate_clone()`` or a compatible allocator.
Must not throw.
============================================== ============= ============================================================================= =============================================================
The library comes with two predefined clone allocators.
Class ``heap_clone_allocator``
------------------------------
This is the default clone allocator used by all pointer containers. For most
purposes you will never have to change this default.
**Definition**
.. parsed-literal::
namespace boost
{
struct heap_clone_allocator
{
template< class U >
static U* allocate_clone( const U& r )
{
return new_clone( r );
}
template< class U >
static void deallocate_clone( const U* r ) const
{
delete_clone( r );
}
};
}
Notice that the above definition allows you to support custom allocation
schemes by relying on ``new_clone()`` and ``delete_clone()``.
Class ``view_clone_allocator``
------------------------------
This class provides a way to remove ownership properties of the
pointer containers. As its name implies, this means that you can
instead use the pointer containers as a view into an existing
container.
**Definition**
.. parsed-literal::
namespace boost
{
struct view_clone_allocator
{
template< class U >
static U* allocate_clone( const U& r )
{
return const_cast<U*>(&r);
}
template< class U >
static void deallocate_clone( const U* )
{
// empty
}
};
}
.. **See also**
- `Changing the clone allocator <examples.html#changing-the-clone-allocator>`_
Class hierarchy
+++++++++++++++
The library consists of the following types of classes:
1. Pointer container adapters
..
2. Pointer containers
The pointer container adapters are used when you
want to make a pointer container starting from
your own "normal" container. For example, you
might have a map class that is extends ``std::map``
in some way; the adapter class then allows you
to use your map class as a basis for a new
pointer container.
The library provides an adapter for each type
of standard container highlighted as links below:
- ``reversible_ptr_container``
- `ptr_sequence_adapter <ptr_sequence_adapter.html>`_
- ``ptr_vector``
- ``ptr_list``
- ``ptr_deque``
- ``ptr_array``
- ``associative_ptr_container``
- `ptr_set_adapter <ptr_set_adapter.html>`_
- `ptr_multiset_adapter <ptr_multiset_adapter.html>`_
- `ptr_map_adapter <ptr_map_adapter.html>`_
- `ptr_multi_map_adapter <ptr_multimap_adapter.html>`_
- ``ptr_set``
- ``ptr_multi_set``
- ``ptr_map``
- ``ptr_multimap``
The pointer containers of this library are all built using
the adapters. There is a pointer container
for each type of "normal" standard container highlighted as links below.
- ``reversible_ptr_container``
- ``ptr_sequence_adapter``
- `ptr_vector <ptr_vector.html>`_
- `ptr_list <ptr_list.html>`_
- `ptr_deque <ptr_deque.html>`_
- `ptr_array <ptr_array.html>`_
- ``associative_ptr_container``
- ``ptr_set_adapter``
- ``ptr_multiset_adapter``
- ``ptr_map_adapter``
- ``ptr_multi_map_adapter``
- `ptr_set <ptr_set.html>`_
- `ptr_multi_set <ptr_multiset.html>`_
- `ptr_map <ptr_map.html>`_
- `ptr_multimap <ptr_multimap.html>`_
Serialization
+++++++++++++
As of version 1.34.0 of Boost, the library support
serialization as defined by `Boost.Serialization`__.
.. __: ../../serialization/index.html
Of course, for serialization to work it is required
that the stored type itself is serializable. For maps, both
the key type and the mapped type must be serializable.
When dealing with serialization (and serialization of polymophic objects in particular),
pay special attention to these parts of Boost.Serialization:
1. Output/saving requires a const-reference::
//
// serialization helper: we can't save a non-const object
//
template< class T >
inline T const& as_const( T const& r )
{
return r;
}
...
Container cont;
std::ofstream ofs("filename");
boost::archive::text_oarchive oa(ofs);
oa << as_const(cont);
See `Compile time trap when saving a non-const value`__ for
details.
.. __: ../../serialization/doc/rationale.html#trap
2. Derived classes need to call ``base_object()`` function::
struct Derived : Base
{
template< class Archive >
void serialize( Archive& ar, const unsigned int version )
{
ar & boost::serialization::base_object<Base>( *this );
...
}
};
For details, see `Derived Classes`_.
.. _`Derived Classes`: ../../serialization/doc/tutorial.html#derivedclasses
3. You need to use ``BOOST_CLASS_EXPORT`` to register the
derived classes in your class hierarchy::
BOOST_CLASS_EXPORT( Derived )
See `Export Key`__ and `Object Tracking`_
for details.
.. __: ../../serialization/doc/traits.html#export
.. _`Object Tracking`: ../../serialization/doc/special.html
Remember these three issues and it will save you a lot of trouble.
..
Map iterator operations
+++++++++++++++++++++++
The map iterators are a bit different compared to the normal ones. The
reason is that it is a bit clumsy to access the key and the mapped object
through i->first and i->second, and one tends to forget what is what.
Moreover, and more importantly, we also want to hide the pointer as much as possibble.
The new style can be illustrated with a small example::
typedef ptr_map<string,int> map_t;
map_t m;
m[ "foo" ] = 4; // insert pair
m[ "bar" ] = 5; // ditto
...
for( map_t::iterator i = m.begin(); i != m.end(); ++i )
{
*i += 42; // add 42 to each value
cout << "value=" << *i << ", key=" << i.key() << "n";
}
So the difference from the normal map iterator is that
- ``operator*()`` returns a reference to the mapped object (normally it returns a reference to a ``std::pair``, and
- that the key can be accessed through the ``key()`` function.
Class ``nullable``
++++++++++++++++++
The purpose of the class is simply to tell the containers
that null values should be allowed. Its definition is
trivial::
namespace boost
{
template< class T >
struct nullable
{
typedef T type;
};
}
Please notice that ``nullable`` has no effect on the containers
interface (except for ``is_null()`` functions). For example, it
does not make sense to do ::
boost::ptr_vector< boost::nullable<T> > vec;
vec.push_back( 0 ); // ok
vec.push_back( new boost::nullable<T> ); // no no!
boost::nullable<T>& ref = vec[0]; // also no no!
Exception classes
+++++++++++++++++
There are three exceptions that are thrown by this library. The exception
hierarchy looks as follows::
namespace boost
{
class bad_ptr_container_operation : public std::exception
{
public:
bad_ptr_container_operation( const char* what );
};
class bad_index : public bad_ptr_container_operation
{
public:
bad_index( const char* what );
};
class bad_pointer : public bad_ptr_container_operation
{
public:
bad_pointer();
bad_pointer( const char* what );
};
}
Disabling the use of exceptions
+++++++++++++++++++++++++++++++
As of version 1.34.0 of Boost, the library allows you to disable exceptions
completely. This means the library is more fit for domains where exceptions
are not used. Furthermore, it also speeds up a operations a little. Instead
of throwing an exception, the library simply calls `BOOST_ASSERT`__.
.. __: ../../utility/assert.html
To diable exceptions, simly define this macro before including any header::
#define BOOST_PTR_CONTAINER_NO_EXCEPTIONS 1
#include <boost/ptr_container/ptr_vector.hpp>
It is, however, recommended that you define the macro on the command-line, so
you are absolutely certain that all headers are compiled the same way. Otherwise
you might end up breaking the One Definition Rule.
If ``BOOST_NO_EXCEPTIONS`` is defined, then ``BOOST_PTR_CONTAINER_NO_EXCEPTIONS``
is also defined.
.. raw:: html
<hr>
**Navigate:**
- `home <ptr_container.html>`_
.. raw:: html
<hr>
:Copyright: Thorsten Ottosen 2004-2006. Use, modification and distribution is subject to the Boost Software License, Version 1.0 (see LICENSE_1_0.txt__).
__ http://www.boost.org/LICENSE_1_0.txt
|