[boost] Re: implicit smart pointer conversions

From: Nathan Myers (ncm_at_[hidden])
Date: 2000-03-19 04:37:26

On Sat, Mar 18, 2000 at 10:01:31AM -0500, Mark Borgerding wrote:
> Greg Colvin wrote:
> > (somebody) wrote: 
> > > The idea was that the implicit casts like:
> > >   operator T*() const throw() { return ptr; }
> > > be replaced with:
> > >   operator void*() const throw() { return ptr; }
> > > [so that] such a pointer can be checked for NULLness...
> > > but cannot be dereferenced by accident.
> >
> > 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().
> ... 
> I think the slight unwieldiness of using get() is a small 
> price to pay for fewer runtime errors.  If I have to choose between 
> compile-time checks and ease of use,  I will choose the compile-time 
> checks nearly every time.

Indeed, some of us argued for naming them member of auto_ptr<> that
reveals the raw pointer value "auto_ptr<>::leak()".  To me it seems
a grave, grave design error to provide an automatic conversion for
that purpose.  Automatic conversions are dangerous enough in general, 
but when they contradict the base purpose of the component, it makes
me wonder why somebody wants such a component at all.

If I may be allowed an analogy, it's like nipping the ground post off
of a three-prong power cord so it can be used in a two-hole power socket.

Very frequently people ask why basic_string<> has no automatic conversion
to char const* (or, worse, char*).  The answer is the same.

Nathan Myers
ncm_at_[hidden]