Re: [boost] Loki SmartPtr study: Policy orthogonality issues

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-01-13 05:39:08

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <boost_at_[hidden]>; <boost_at_[hidden]>
Sent: Friday, January 11, 2002 11.50
Subject: Re: [boost] Loki SmartPtr study: Policy orthogonality issues

> Be careful.  There is an interaction between operator[] and
> ConversionPolicy.  For an array, if the ConversionPolicy will cause
> operator T* to be supplied, then operator[] should not be supplied.  In
> other words, inter-policy communication is needed.

Hmm, I guess in this particular case there's no harm in simply leaving
operator[] in there, even if you do provide a conversion to pointer. The
compiler will prefer it, which is a good thing because you have more
control.

> I looked at making CheckingPolicy and ConversionPolicy policies of
> StoragePolicy, and that seems to work, but there may well be other ways to
> relate the three which are better.  I need to read Peter Dimov's recent
> posts more carefully.

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.
This is cool as long as we're working with static functions. If needed, a
static_cast could access the parent object as well. (I'd prefer something
better than that.)

> On the other hand, the only case I can come up with where those three need

> to communicate with OwnershipPolicy is to disallow certain configurations
> like arrays when the OwnershipPolicy is invasive reference counted.  But
as
> we previously discussed, these errors will be detected by compiler
> diagnostics, so we don't have to do anything special in the way of
> inter-policy communication.  Your present design WRT Ownership/other
policy
> separation seems to work well.  I don't want to toss your orthogonality
> arguments out the window; if there isn't a specific benefit to
inter-policy
> communication, the orthogonality rationale is a good reason to keep them
> separate.

Sounds like we got a good constructive dialog going. Your insights are
highly appreciated.

Andrei

---------------------------------
Check out THE C++ Seminar:  3 Days with 5 Experts
http://www.gotw.ca/cpp_seminar/