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
communication
> 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
complexity.
> >
> >The idea is that the framework is written by the library
designer, and
> >policies can be written by both the library designer and the
library
> user.
> >In particular, an important goal of Loki::SmartPtr was to make
typical
> >user-defined policies (COM/CORBA ownership, custom checkers,
etc.) easy
> to
> >implement. Also, SmartPtr can be fairly intricate because it is
designed
> >and
> >implemented only once.
> >
> >That's why I find the design in which SmartPtr is an orchestrator
of
> >various
> >policies a natural one. It also was one that satisfied its users.
> >
> >What practical problem requires policies to communicate with each
other?
>
> By communicate, I assume you mean directly via inheritance rather
than
> indirectly via the framework.
>
> The StoragePolicy needs to know if implicit conversion is
requested,
> because it needs (in the case of arrays for sure, but that probably
means
> 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
framework.
>
> 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:
template<T,...>
class SmartArray : public SmartPtr<T,ArrayStoragePolicy,... > {
public:
// forwarding constructors
// aimed assecc method
Reference operator[]( size_t index )
{
return GetImpl(*this)[index];
}
};
Gennadiy.