Boost logo

Boost :

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:
>class SmartArray : public SmartPtr<T,ArrayStoragePolicy,... > {
> // 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.


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