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
>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,
>> with power comes responsibility.
>> I don't mind an implementation catching obvious mistakes as a QoI
>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
> 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
>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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk