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

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-01-07 17:17:51

> The plumbing that can't be replaced includes public interface.  The
> framework knows too much about the public interface.  The policies should
> be free to alter it.  Much more powerful.

But the policies can alter the public interface in either design. Or maybe I
misunderstood something.

> Able to cope with arrays, for
> example.

At the risk of beating a dead horse, I'll repeat that trying to implement
comprehensive array support (operator[], bounds checking...) in SmartPtr is
a red herring. A more compelling example would be helpful.

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 ...
};

If that's the case, please restate exactly, with examples, what advantages
are brought by the second approach. You mention direct inter-policy
communication. I guess that is a kind of one-way, because for example
Policy1 can "see" Policy2 but not vice versa. Well, there might be some
sensical order in which to arrange the chaining of policies.

Validation of design was another point. I believe that's a red herring. In
all applications of SmartPtr I know of, the smart pointer type definition is
a design artifact which is never treated naively. Developers think on what
features they want and the resulting typedefs reflect a well-thought-out set
of behaviours, rather than a hasty decision made by a junior.

Of course, it would be very nice to have the design validated, but any
effective validation complicates things a lot. And no matter how hard you
try at validating, a user still can misuse SmartPtr quite easily. They can
design a wrong policy (allocate with malloc and free with delete), simply
choose the wrong policies (choose a non-checking policy when the app
architecture expects exceptions to be thrown for null dereference), or
misuse the produced smart pointer object.

Andrei

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