Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-01-05 15:56:03


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?

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk