Re: [boost] Re: Policy-based smart pointers revisisted (was: Re:Preliminarysubmission: command line & config file library)

From: David Abrahams (dave_at_[hidden])
Date: 2003-01-18 08:49:47

"David B. Held" <dheld_at_[hidden]> writes:

> Actually, the policy_ptr<> code in the sandbox features a policy adaptor
> that automagically detects specified policies, and fills in defaults, in any
> order.  However, it requires that the user specify policies using MPL
> Lambda syntax.  And that still doesn't avoid the fact that non-default
> configurations may require specifying several policies.  Finally, the
> policy_ptr code has gotten too big for its own good, and has too many
> templated c'tors that interfere with each other.  Frankly, I don't
> understand all the issues with it any more.  I will probably try to write
> tests for some more policy combinations, and then solicit help to figure
> out how to make the conversion c'tors work.  They seem to be the last
> and biggest hurdle.
>
> As far as policy specification goes, perhaps a new idiom of building
> policies into a unit, and passing them as one parameter might address
> both the interface complexity issue and the default policy issue.  I think
> it needs to be considered further.

I'm sure I've suggested this before, but I think it was ignored:

In Boost.Python I'm using a system for interfaces such as this one
where optional template parameters can be passed in any order.  I'm
using the properties of the type to detect their meaning.  It works
great.  Using boost/mpl/has_xxx.hpp (and, for compilers which don't
support it, is_base_and_derived) should be enough to build a nice
policy-based interface.

-- 
                       David Abrahams
   dave_at_[hidden] * http://www.boost-consulting.com
Boost support, enhancements, training, and commercial distribution