Re: Loki SmartPtr study: Policy orthogonality issues

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-08 01:18:33

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> 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.)

So do I. But I still want to stick to the existant fixed interface. 
Is there real example where we need to introduce new interface 
(excuding operator[], which I agree with Andrei is red herring).

> 
>  >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

In reality for this example there are 2 things to check: 
  is the Pointer hold valid reference, that could be validated by 
GetImpl
 and bounds checking, which is complitly out of smart pointer domain.

Storage Policies we provide ourself and Ownership Policy either fitt 
for arrays or would not compile (lyrical digression: I do not really 
like the fact that Loki Ownership policy need to know now to deep 
copy StorageType; it should be part of Storage policy).
  In any case it does not seems reasonable to provide any generic 
class to support only operator[]. You would immidiately want also size
(), begin(), end() and so on. My expirience agree with Andrei: I only 
needed smart pointer on array as a storage wrapped in some other 
class that provide access interface.

Gennadiy.