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
> are supposed to use "precanned" variants of smart_ptr<> called
> 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,
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
> 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
> > has enough information should make the compile-time assertion.
> As I see it, the policies are supposed to be as independent as possible;
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk