Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-17 10:07:30


As we've been discussing, altering the inheritance pattern of Andrei
Alexandrescu's Loki::SmartPtr to allow freer inter-policy communication
would bring benefits in terms more policy flexibility (allowing fuller
array support for example) and less framework forwarding functions.

Andrei, Peter Dimov, Dave Abrahams, and I have all suggested possible
inheritance patterns that seem reasonable.

I wanted to explore a variation on the nested inheritance I suggested to
see if it really worked, and to see if the framework code really did get
simpler. The policy inheritance pattern looks like this:

template< typename T,
           template< class > class Ownership,
           template< class > class Checking,
           template< typename, template<class> class, class > class
Storage,
           class Conversion = no_implicit_conversion >
class nested_ptr
   : public Ownership< Storage< T, Checking, Conversion > > { ... };

The example code is available at:
http://groups.yahoo.com/group/boost/files/smart_pointers/nested_ptr.hpp

An array storage policy (as well as a non-array policy) is included. But
note that the code does not supply a complete smart pointer - it leaves out
portions not material to the discussion of policy inheritance techniques.

A test driver is available at:
http://groups.yahoo.com/group/boost/files/smart_pointers/nested_ptr_test.cpp

To me, this code is both flexible and reduces forwarding functions. The
requirements are simplified; for example there isn't any need for Ownership
to expose a clone() function. So only the deep copy ownership policy has
to concern itself with cloning.

I'm not asserting that nested_ptr's policy inheritance is superior to the
suggestions from others. Just that it is a viable candidate, and easy to
work with in practice. To me smart pointers are important enough that it
is worth actually writing code demonstrating various techniques, so that
when one is chosen we can all get behind it knowing that other avenues have
been thoroughly explored.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk