Boost logo

Boost :

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,
> 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

> 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, gregod at, cpdaniel at, john at