[boost] Re: implicit smart pointer conversions

From: Greg Colvin (gcolvin_at_[hidden])
Date: 2000-03-18 01:21:43

> From: Dave Abrahams <abrahams_at_[hidden]>
> on 3/17/00 5:34 PM, Greg Colvin at gcolvin_at_[hidden] wrote:
> 
> > The impasse is that some users of smart pointers, myself
> > included, actually want operator T*().  If you have generic
> > code written to accept pointers then operator void*() won't
> > do, and neither will get().
> > 
> 
> Ya know, I don't think I buy it. Could you give an example?
> 
> If you mean generic code as in "template code", it will just use the smart
> pointer type instead, and no implicit conversion is needed (unless you
> intend to do something evil which the interface of a raw pointer allows but
> smart pointers do not, like pointer arithmetic).

Yes, I meant template code, and the evil thing might be as simple
as trying to pass shared_array<char> to strncpy().  Yes, I know,
the C string functions are evil.  They are also implemented as
very fast intrinisics on many compilers.

Even without templates not having the conversion is an obstacle to
converting code that uses raw pointers to use shared_ptr.  It is not
at all unusual to pass objects around by address, with a convention
that functions that take a pointer to an object do not ever delete
the object.

> Finally, I worry that allowing the implicit conversion will break this
> smart_ptr<Derived> -> smart_ptr<Base> conversion or others like it:
> 
> void f(smart_ptr<Derived> d)
> {
>     smart_ptr<Base> b(d); // ambiguous?
> }
> 
> at least that would be true for auto_ptr, since conversions proceed through
> auto_ptr_ref.

There is no shared_ptr_ref, and I think no ambiguity.

A compromise might be to have the conditional chose between T* and
void* conversions, rather than T* and no conversion like we have now.