Example 1:
auto_ptr. Objects of
auto_ptr<T> are not value-like because of their transfer-of-ownership copy semantics. Using a container of
auto_ptr s (e.g., a
vector< auto_ptr<int> > ) should fail to compile. Even if it does compile,
never write that; if you want to write it, you almost certainly want a container of
Example 2: Heterogeneous containers. To have a container store and own objects of different but related types, such as types derived from a common
Base class, prefer
container< shared_ptr<Base> > . An alternative is to store proxy objects whose nonvirtual functions pass through to corresponding virtual functions of the actual object.
Example 3: Containers of non-value types. To contain objects even though they are not copyable or otherwise not value-like (e.g.,
DatabaseLock s and
TcpConnection s), prefer containing them indirectly via smart pointers (e.g.,
container< shared_ptr\zwbo<DatabaseLock> > and
container< shared_ptr\zwbo<TcpConnection> > ).
Example 4: Optional values. When you want a
map<Thing, Widget> , but some
Thing s have no associated
Widget , prefer
map<Thing, shared_ptr<Widget> > .
Example 5: Index containers. To have a main container hold the objects and access them using different sort orders without resorting the main container, you can set up secondary containers that "point into" the main one and sort the secondary containers in different ways using dereferenced compare predicates. But prefer a container of
MainContainer::iterator s (which are value-like) instead of a container of pointers.