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
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.
>
> If doing nothing means a compile time error, I could live with
> that. Although it does sound like settling for second best.
Explicit
> error messages would be better.
>
> If doing nothing means silent runtime failures, I have a hard time
with
> that.
>
> > 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.
>
> No, a validator does not need to recognize each and every policy.
>
> Validators are like other generic components. Their requirements
include
> 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
version
> can always be supplied.
>
> For smart pointers there is probably a limited number of
configuration
> validity issues, so a policy class would probably be overkill. The
> framework class itself can handle it; isn't that already done by
Loki
> 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).
Regards,
Gennadiy.
>
> --Beman