Re: [boost] Re: Loki SmartPtr study: Policy orthogonality issues

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-07 20:01:58

At 04:31 PM 1/7/2002, rogeeff wrote:

 >SmartPtr implements very simple models of "Resource holder". It
 >1. aquire resource
 >2. Provide an access to it.
 >3. release resource
 >
 >(1) is implementing using constructors and assignment operators
 >(maybe method 'reset' also)
 >(2) is implemented with operator*, operator->, direct resource access
 >using free function like GetImpl
 >(3) is implemented using destructor (and probably method 'release')
 >
 >That's it. This is fixed interface. And it should stay that way.

Some of us are interested in a much more flexible resource holder where the 
resource may be something very different from memory.  (I should thank 
Kevlin Henney for opening my eyes to the wider view of what a smart pointer 
could be.)

 >Policies should not be allowed to expand it. Any other access methods
 >could be implemented outside of SmartPtr (which I assume will be very
 >rare case). For example operator[] for arrays could be implemented
 >like this:
 >
 >template<T,...>
 >class SmartArray : public SmartPtr<T,ArrayStoragePolicy,... > {
 >public:
 >    // forwarding constructors
 >
 >    // aimed assecc method
 >    Reference   operator[]( size_t index )
 >    {
 >       return GetImpl(*this)[index];
 >    }
 >};

Yes, that's the been discussed.  You have to be a bit more careful though - 
the access should be done via some function that applies the 
CheckingPolicy.  And of course neither a conflict with an Ownership policy 
which doesn't allow arrays nor a StoragePolicy which doesn't provide arrays 
is diagnosed. It gets messy.  Makes you wonder why the SmartPtr itself 
wasn't designed to allow such flexibility.

--Beman