Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-07 15:56:52

At 03:14 PM 1/7/2002, Andrei Alexandrescu wrote:

>> The difficulty with using the framework to mediate the communication
>> forwarding functions is that communication is limited to exactly those
>> forwarding functions and now others. And they are still there even when
>> 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
>In particular, an important goal of Loki::SmartPtr was to make typical
>user-defined policies (COM/CORBA ownership, custom checkers, etc.) easy
>implement. Also, SmartPtr can be fairly intricate because it is designed
>implemented only once.
>That's why I find the design in which SmartPtr is an orchestrator of
>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.


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