Boost logo

Boost :

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

Larry Evans wrote:
> Currently, 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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at