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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-08 07:04:21

From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> I have the impression that I work under some misunderstanding, so I'd like
> to clarify some things.
>
> Loki::SmartPtr does this:
>
> template <several policies>
> class SmartPtr : public Policy1, public Policy2,... public PolicyN
> {
>     ... do stuff, use policies, coordinate policy interaction ...
> };
>
> Here I'm not positive (please confirm), but I think you are suggesting
this:
>
> template <several policies>
> class SmartPtr : public Policy1<Policy2<... <PolicyN> > ... >
> {
>     ... do stuff, use policies ...
> };

What I had in mind in my original summary was this:

template<class T, template class Policy1, ...>
class smart_ptr: public Policy1<T, smart_ptr>, ...
{
};

That is, pass the parent class to each policy so that it can downcast 'this'
to smart_ptr*.

Now it's not necessary to implement forwarders in smart_ptr.

Example:

Loki has, in smart_ptr:

        PointerType operator->() const
        {
            KP::OnDereference(GetImplRef(*this));
            return SP::operator->();
        }

        operator AutomaticConversionResult() const
        { return GetImpl(*this); }

etc.

The other design wouldn't need these. They will go in the access policy:

template<class T, class SmartPtr> struct some_access_policy
{
    T * operator->() const
    {
        SmartPtr const * this_ = static_cast<SmartPtr const *>(this);
        T * p = this_->get(); // probably comes from the storage policy
        this_->on_dereference(p); // probably comes from the checking policy
        return p;
    }

    operator T * () const // may or may not be present
    {
        SmartPtr const * this_ = static_cast<SmartPtr const *>(this);
        return this_->get();
    }
};

If this isn't clear, I can try to duplicate the whole smart_ptr using this
approach.

--
Peter Dimov
Multi Media Ltd.