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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-01-06 07:47:35

From: "Beman Dawes" <bdawes_at_[hidden]>
> 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.
[...]
>  >> >  >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.

"Do nothing" means do not burden the specification with extra non-free
features that have no other purpose except to validate a configuration.
Sometimes this translates into a compile-time error and sometimes it means
that some features of smart_ptr may invoke undefined behavior, like using
operator[] with an index that is not zero on a scalar pointer.

Note that you can easily make smart_ptr misbehave even when its
configuration is perfectly valid, though.

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

Yes, a validator needs to recognize the policies it's supposed to validate.

It can recognize policies by name; or it can recognize policies by an
identifier - is_array in the above.

Recognition by id means that every policy needs to supply an id.

> Furthermore, if the validator is itself a policy, then a do-nothing
version
> can always be supplied.

True.

> For smart pointers there is probably a limited number of configuration
> validity issues, so a policy class would probably be overkill.

The number of smart_ptr configurations is unbounded. It's possible for a
predefined validation scheme to fail for some of them, sometimes in both
ways, i.e. both silent negatives and false positives may be reported.
("misconcept checks" as coined by John Potter.)

Furthermore, we don't know yet which smart_ptr (configuration) errors are
most common. It may turn out that the most common errors go undetected, and
that the errors that are detected by the validator (for which all policy
authors pay the enum { is_array = 0 } cost) are virtually never encountered.

I'm not trying to say that validation attempts are a dead end; I'm simply
pointing out that quickly dismissing the non-validating alternative simply
by saying "this is unacceptable" is, well, unacceptable.

--
Peter Dimov
Multi Media Ltd.