Boost logo

Boost :

From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-07 16:31:29

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 03:14 PM 1/7/2002, Andrei Alexandrescu wrote:
> >> The difficulty with using the framework to mediate the
> via
> >> forwarding functions is that communication is limited to
exactly those
> >> forwarding functions and now others. And they are still there
even when
> >not
> >> needed. The forwarding function also represent additional
> >
> >The idea is that the framework is written by the library
designer, and
> >policies can be written by both the library designer and the
> user.
> >In particular, an important goal of Loki::SmartPtr was to make
> >user-defined policies (COM/CORBA ownership, custom checkers,
etc.) easy
> to
> >implement. Also, SmartPtr can be fairly intricate because it is
> >and
> >implemented only once.
> >
> >That's why I find the design in which SmartPtr is an orchestrator
> >various
> >policies a natural one. It also was one that satisfied its users.
> >
> >What practical problem requires policies to communicate with each
> By communicate, I assume you mean directly via inheritance rather
> indirectly via the framework.
> The StoragePolicy needs to know if implicit conversion is
> because it needs (in the case of arrays for sure, but that probably
> there are other cases too) to supply operator[] or not depending on
> that. Perhaps you could get around that with your current design
by making
> ConversionPolicy a policy of StoragePolicy rather than of the
> Another example: Say a StoragePolicy adds an additional access
function to
> the public interface. There is no way I can see for this
additional access
> function to call one of the CheckingPolicy functions.
> I haven't totally made up my mind about any of this. I want to be
sure I
> understand the pros and cons in detail. I'm also looking forward
to seeing
> the details Dave's policy adaptor approach.
> --Beman

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.
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];


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