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