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

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-01-05 16:35:30

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

Now we're talking. The basic idea is that throwing in some sensical
validations for policies inside smart_ptr is good but should not go amok.
Again, I think array support is not a fertile field. No matter how hard you
try, you are still exposed to silly errors. Consider:

typedef smart_ptr<Widget, UltraSmartArrayPolicy> SPWidget;
...
SPWidget sp(new Widget); // oops

See what I'm saying?

So I guess my point is:

* It's good to have policies as independent to each other as it gets.

* It's good to have policies expose information to their host class.

* It's good to have policies that wrap ("filter") other policies and expose
the same interface so they can be chained (see the small string optimization
in flex_string and Beman's previous post on the subject). Also MC++D
mentions (without giving examples) that you can wrap a Storage in a Storage
that does locking.

* I happen to think that separate policies orchestrated by smart_ptr form a
better design for smart_ptr than nested ones. Maybe it's me, but I prefer
checking to have a different interface than storage.

* A policy should be reasonably easy to implement.

By the way, I arranged with InformIT and Addison-Wesley to publish MC++D's
chapter on Smart Pointers on InformIT's website.

Andrei