Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-22 15:22:17


At 03:56 AM 1/21/2002, teamhyer wrote:

>--- In boost_at_y..., "Andrei Alexandrescu"
>> <andrewalex_at_h...> wrote:
>> I think a good solution would be the following.
>>
>> The policies might take two template arguments, the last one being
>the SmartPtr class itself. In turn, SmartPtr exposes all of its
>policies through typedefs. Here's a trimmed-down example.
>>
>> template <
>> class T,
>> template <class, class> class Checking>
>> template <class, class> class Storage>
>> class SmartPtr
>> : public Checking< T, SmartPtr<T, Checking, Storage> >
>> : public Storage< T, SmartPtr<T, Checking, Storage> >
>> {
>> public:
>> typedef Checking checking_policy;
>> typedef Storage storage_policy;
>> ...
>> };
>>
>> So now the policies that don't care of each
>> other simply ignore
>> their second template parameter. Policies that
>> do need to
>> communicate with neighbouring policies can
>> access them by
>> using the parent class and their named typedefs.
>
>
> I'm very suspicious of this proposed solution. It's closely
>analogous to (in non-template C++ programming) passing *this
>rather than extracting the relevant members "so we won't have to
>worry about the details of communication". Like that strategy,
>it will have the effect of denying the user the knowledge of which
>parameters truly are needed -- it will make complicated things
>appear simple on the surface, and make truly simple things
>indistinguishable from them. Happily, policies are often truly
>orthogonal.

I don't think anyone is arguing with you for the case where policies are
"truly orthogonal".

But when a framework class has forwarding functions whose only job is to
facilitate communication between policies, the polices aren't "truly
orthogonal" in my mind. Also, if some feature can't be implemented because
it would require inter-policy communication that hasn't been provided, the
policies may be "true orthogonal", but the design is crippled.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk