The recommended usage pattern of the container classes are the same as the for normal standard containers.
ptr_vector, ptr_list and ptr_deque offer the programmer different complexity tradeoffs and should be used accordingly. ptr_vector is the type of sequence that should be used by default. ptr_list should be used when there are frequent insertions and deletions from the middle of the sequence and if the container is fairly large (for example, more than 100 elements). ptr_deque is the data structure of choice when most insertions and deletions take place at the beginning or at the end of the sequence. The special container ptr_array may be used when the size of the container is invariant and known at compile time.
An associative container supports unique keys if it may contain at most one element for each key. Otherwise, it supports equivalent keys. ptr_set and ptr_map support unique keys. ptr_multiset and ptr_multimap support equivalent keys.
Idiomtic Object-Oriented Programming in C++ looks a bit different from the way it is done in other languages. This is partly because C++ has both value and reference semantics, and partly because C++ is more flexible than other languages. Below is a list of recommendations that the user can follow:
This has the following advantages:
It reduces coupling as, there is no need to maintain or update state
It helps avoid slicing
It ensures the user overrides the right function
Read the following articles:
Kevlin Henney's Six of the best
Jack Reeves' Multiple Inheritance Considered Useful
In code:
class Polymorphic
{
private:
virtual int do_foo() = 0;
public:
int foo()
{
return do_foo();
}
...
};
This has the following advantages:
It makes sure all calls to the virtual function always goes through one place in the code
It enables the user to check preconditions and postconditions inside the forwarding function
Read Herb Sutter's article Virtuality.
Having an abstact base class prevents slicing when the base class is involved, but it does not prevent it for classes further down the hierarchy. This is where boost::noncopyable is handy to use:
class Polymorphic : boost::noncopyable
{
...
};
By default the pointer containers do not allow to store null-pointer in them. This behavior can be changed explicitly with the use of boost::nullable.
The primary reason to avoid null-pointers is that the user has to check for null-pointers every time the container is used. This extra checking is easy to forget, and it is somewhat contradictory to the spirit of OO where special cases are replaced with dynamic dispatch.
Often, however, there is a need to place some special object in the container because there is not enough information to construct a full object. In that case use, the Null Object pattern which simply dictates that virtual functions are implemented from the abstract base-class as empty functions or with dummy return values. This means that the OO-code still does not need to worry about null-pointers.
Read
Kevlin Henney's Null Object - Something for Nothing
Finally, when the Null Object does not help. Use container< nullable<T> >.
|
©Thorsten Ottosen 2004-2006. Use, modification and distribution is subject to the Boost Software License, Version 1.0 (see http://www.boost.org/LICENSE_1_0.txt). |
|
|---|