From: rogeeff (rogeeff_at_[hidden])
Date: 2002-01-05 16:03:46
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 02:14 PM 1/5/2002, Andrei Alexandrescu wrote:
> >As much as I hate wasting bandwith with messages such as "I
> >compelled to underline that Peter hit the nail on the head.
> >> > >The other fundamental problem - that some policy
> >> > >nonsensical (array_access with intrusive_storage) - has
> >> > >solutions:
> >> > >
> >> > >1. Do nothing.
> >> >
> >> > I don't think that's acceptable.
> >> I'm not so sure. It looks acceptable - if not perfect - to me.
> >> are supposed to use "precanned" variants of smart_ptr<> called
> >> shared_array<>, and so on; the general interface is for power
> >> with power comes responsibility.
> >> I don't mind an implementation catching obvious mistakes as a
> >> course.
> >It looks acceptable to me, too.
> If doing nothing means a compile time error, I could live with
> that. Although it does sound like settling for second best.
> error messages would be better.
> If doing nothing means silent runtime failures, I have a hard time
> > The idea is that elaborate uses of smart_ptr
> >will be almost exclusively through typedefs. Those typedefs are
> >place by people who know what they're asking for. It's not like
> >naive user defines smart_ptr instantiations. Then, of course,
> >to validate the design at compile time, but this shouldn't be
> >the expense of orthogonality.
> >> The problem with validating a configuration is that the
> >> recognize each and every policy. This is not possible in the
> >My words exactly. SmartPtr has *hundreds* of valid, useful
> >strength comes exactly from the policies being independent and
> >onto each other.
> No, a validator does not need to recognize each and every policy.
> Validators are like other generic components. Their requirements
> inherited enums like is_array and disallow_array.
> So the validator does something like:
> BOOST_STATIC_ASSERT( !disallow_array || !is_array )
> Furthermore, if the validator is itself a policy, then a do-nothing
> can always be supplied.
> For smart pointers there is probably a limited number of
> validity issues, so a policy class would probably be overkill. The
> framework class itself can handle it; isn't that already done by
> SmartPtr once or twice?
But few statements above you sad that we should be able to
provide 'do-nothing version'. I think that the rationale could be
like this: every decision that could be made by user should be a
Policy. Now some related policies couls be compined in 'Policy
adaptors', though , I assume, it will be a rare case. In general we
should try to design orthogonal independent policies, while 'policy
adaptors' provide small reuse level and could cause some other
problems (like need for extensive use of partial specialization to
extend one specific policy).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk