Pointer Container Library
OverviewBoost.Pointer Container provides containers for holding heap-allocated objects in an exception-safe manner and with minimal overhead. The aim of the library is in particular to make OO programming easier in C++ by establishing a standard set of classes, methods and designs for dealing with OO specific problems MotivationWhenever a programmer wants to have a container of pointers to heap-allocated objects, there is usually only one exception-safe way: to make a container of smart pointers like boost::shared_ptr This approach is suboptimal if
This library therefore provides standard-like containers that are for storing heap-allocated or cloned objects (or in case of a map, the mapped object must be a heap-allocated or cloned object). For each of the standard containers there is a pointer container equivalent that takes ownership of the objects in an exception safe manner. In this respect the library is intended to solve the so-called polymorphic class problem. The advantages of pointer containers are
The disadvantages are
When you do need shared semantics, this library is not what you need. Upgrading from Boost v. 1.33.*If you upgrade from one of these versions of Boost, then there has been one major interface change: map iterators now mimic iterators from std::map. Previously you may have written for( boost::ptr_map<std::string,T>::iterator i = m.begin(), e = m.end(); i != e; ++i ) { std::cout << "key:" << i.key(); std::cout << "value:" << *i; i->foo(); // call T::foo() } and this now needs to be converted into for( boost::ptr_map<std::string,T>::iterator i = m.begin(), e = m.end(); i != e; ++i ) { std::cout << "key:" << i->first; std::cout << "value:" << *i->second; i->second->foo(); // call T::foo() } Apart from the above change, the library now also introduces
Also note that Boost.Assign introduces better support for pointer containers. Upgrading from Boost v. 1.34.*Serialization has now been made optional thanks to Sebastian Ramacher. You simply include <boost/ptr_container/serialize.hpp> or perhaps just one of the more specialized headers. All containers are now copy-constructible and assignable. So you can e.g. now do: boost::ptr_vector<Derived> derived = ...; boost::ptr_vector<Base> base( derived ); base = derived; As the example shows, derived-to-base class conversions are also allowed. A few general functions have been added: VoidPtrContainer& base(); const VoidPtrContainer& base() const; These allow direct access to the wrapped container which is sometimes needed when you want to provide extra functionality. A few new functions have been added to sequences: void resize( size_type size ); void resize( size_type size, T* to_clone ); ptr_vector<T> has a few new helper functions to integrate better with C-arrays: void transfer( iterator before, T** from, size_type size, bool delete_from = true ); T** c_array(); Finally, you can now also "copy" and "assign" an auto_type ptr by calling move(): boost::ptr_vector<T>::auto_type move_ptr = ...; return boost::ptr_container::move( move_ptr ); Upgrading from Boost v. 1.35.*The library has been fairly stable, but a few new containers have been supported:
There are no docs for these classes yet, but they are almost identical to boost::ptr_set<T>, boost::ptr_map<Key,T> and boost::ptr_array<T,N>, respectively. The underlying containers stem from the two boost libraries Furthermore, insert iterators have been added. Future DevelopmentsThere are indications that the void* implementation has a slight performance overhead compared to a T* based implementation. Furthermore, a T* based implementation is so much easier to use type-safely with algorithms. Therefore I anticipate to move to a T* based implementation. Furthermore, the clone allocator might be allowed to have state. This design requires some thought, so if you have good ideas and use-cases' for this, please don't hesitate to contact me. Also, support for Boost.Interprocess is on the todo list. There has been a few request for boost::ptr_multi_index_container<T,...>. I investigated how difficult it would be, and it did turn out to be difficult, albeit not impossible. But I don't have the resources to implement this beast for years to come, so if someone really needs this container, I suggest that they talk with me in private about how it can be done. AcknowledgementsThe following people have been very helpful:
References
|