Larry Evans wrote:

Currently, policy_ptr:

http://cvs.sourceforge.net/viewcvs.py/boost-sandbox/boost-sandbox/boost/poli...

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