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

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-01-05 14:14:25

As much as I hate wasting bandwith with messages such as "I agree", I felt
compelled to underline that Peter hit the nail on the head.

> >  >The other fundamental problem - that some policy combinations are
> >  >nonsensical (array_access with intrusive_storage) - has three major
> >  >solutions:
> >  >
> >  >1. Do nothing.
> >
> > I don't think that's acceptable.
>
> I'm not so sure. It looks acceptable - if not perfect - to me. Novice
users
> are supposed to use "precanned" variants of smart_ptr<> called
scoped_ptr<>,
> shared_array<>, and so on; the general interface is for power users, and
> with power comes responsibility.
>
> I don't mind an implementation catching obvious mistakes as a QoI issue,
of
> course.

It looks acceptable to me, too. The idea is that elaborate uses of smart_ptr
will be almost exclusively through typedefs. Those typedefs are put in place
by people who know what they're asking for. It's not like any naive user
defines smart_ptr instantiations. Then, of course, it's nice to validate the
design at compile time, but this shouldn't be done at the expense of
orthogonality.

> The problem with validating a configuration is that the validator must
> recognize each and every policy. This is not possible in the general case.

My words exactly. SmartPtr has *hundreds* of valid, useful behaviors. Its
strength comes exactly from the policies being independent and orthogonal
onto each other.

> >  >2. Compile-time assertions in the parent class.
> >
> > I was assuming the first class (policy or otherwise) in the hierarchy
that
> > has enough information should make the compile-time assertion.
>
> As I see it, the policies are supposed to be as independent as possible;
so
> the logical "validator" should be the parent class.

Yes, to the extent that this is possible.

Again, I consider that implementing cross-policy validation of arrays is not
the right example, though.

Andrei