Boost logo

Boost :

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
> >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
> Kevlin Henney for opening my eyes to the wider view of what a smart
> 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
> >could be implemented outside of SmartPtr (which I assume will be
> >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
> which doesn't allow arrays nor a StoragePolicy which doesn't
provide arrays
> is diagnosed. It gets messy. Makes you wonder why the SmartPtr
> 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
 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at