[boost] Re: [policy_ptr]source, sink policies proposal

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-05-12 10:35:27

Larry Evans wrote:
> Currently, policy_ptr:
>
>
>
http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/policy_ptr/
>
> constains a conversion policy which determines whether or
> not to contain an implicit conversion to the raw pointer via
> the smart_ptr</*polcies typelist*/>::to<Referent> method:
>
>    operator automatic_conversion_result(void) const;
>
> where:
>
>          typedef typename conversion_policy::result_type
>                             automatic_conversion_result;
>
> However, since smart_ptr<...>::to<Referent> is derived as:
>
>      class smart_ptr<P1, P2, P3, P4>::to
>          : public detail::policy_ptr::conversion_policy_
>
> couldn't the automatic conversion operator just be defined
> (in the case of allow_conversion) or not (in the case of
> disallow conversion) in the conversion policy itself?

> Along the same lines, why not allow a "source" policy which
> decides the "inputs" (the CTOR args) to the smart pointer.
> Currently, for smart_ptr<...>::to<Referent>, the only
> "source", IIUC, is Referent*. (By source, I mean any CTOR
> arguments that don't include another smart pointer ).  This
> would also allow for a "safer" smart pointer since the sole
> source could be something like David Abraham's auto_ptr_new:

I don't like the names sink or source, but it seems that the conversion policy
could be generalized to an interface policy which determines, e.g., whether
there is an implicit conversion to a pointer, whether the named accessor
functions are members or non-members, whether pointer arithmetic is supported,
... . Of course, you might argue that there is a single correct answer to all
these questions, in which case the conversion policy should be eliminated.

Jonathan