From: David Maisonave (dmaisonave_at_[hidden])
Date: 2006-01-24 10:45:24
Since the current smart_ptr (policy_ptr) class at boost vault is on
hold, I like to propose adding the following smart_ptr class to the
IMHO, the above class has more functional features, than the class in
the boost vault, and the class is ready for use.
The smart pointer is very exchangeable with each other, and it has easy
to use policy options.
It has an optional lock policy that can be used on all three main
ownership policy types (deep_copy, COW, & Shared).
It has three methods of cloning policies that can give different levels
of generic coding and/or slicing avoidance.
The shared and COW policy, can use reference-count, reference-link, and
In my performance test, the shared and COW policies along with
reference-link policy, are able to out perform the boost::shared_ptr.
It can be used with non-compliant compilers like VC++6.0 and Borland
And on more compliant compilers (VC++7.x, 8.0, GNU 3.x, 4.x), it has
additional capabilities, which allows it to be exchangeable with
different policy types, and derive types (T).
Like boost::week_ptr, the smart_ptr supports value (pointee) comparison
semantics, so it can be used in an associated container like std::map
and std:set. Unlike the boost pointer containers, this smart pointer can
be used as the first type in the std::map container.
The smart_ptr can be used as a shared-pointer, clone smart pointer,
Copy-On-Write pointer, and a synchronized smart pointer.
Since there's already a similar class in the boost vault, that indicates
that there's already interest in this type of class.
So IMHO, the question really should be, should we continue to wait for a
class in the vault that might never get completed, and might not have
all the functionality available in the above smart_ptr?
Or should this class be pushed through in parallel to the current vault
To see a validation test, and performance test, use the following code: