Re: Re: Re: Problem using 'shared_ptr<T>::operator impl-defined-type()'

From: Alan M. Carroll (yg-boost-users_at_[hidden])
Date: 2002-09-26 21:05:23

"Peter Dimov" <pdimov_at_[hidden]> wrote in message
news:009501c2655c$126794d0$1d00a8c0_at_pdimov2...
> From: "Alan M. Carroll, CodeSlinger" <yg-boost-users_at_[hidden]>
> > "Peter Dimov" <pdimov_at_[hidden]> wrote in message
> > news:019701c264b3$8af21640$1d00a8c0_at_pdimov2...
> > > From: "Alan M. Carroll, CodeSlinger" <yg-boost-users_at_[hidden]>
> > > >     operator void const * () const { return px; }
> > > delete ptr; // ;-)
> > >
> > > In the general case unwanted comparisons are a problem, too.
> >
> 5.3.5/2 (ISO): "[Note: a pointer to a const type can be the operand of a
> delete-expression; ...]"

So, you agree that "delete ptr" is not a problem for the cast to (void const
*)?

> The conversion to "void const *" allows any comparisons between two
objects
> that define such a conversion: two different smart pointers to unrelated
> types, shared_ptr to std::cout, and so on. Even in a shared_ptr<T>-only
> context, it makes it difficult to not provide operator>=, for instance.
>
> It is true that in this particular context a void const * conversion is
> somewhat less evil as shared_ptr is a pointer, but many undesirable
> properties still remain.
>
> That aside, do you really have code that depends on a specific conversion
to
> void const *?

Not directly. This issue came up with earlier version of Boost smart_ptr
that didn't have the methods necessary for things like
    if (ptr) { /* stuff */ }
The conversion provides this. It also supports the idiom
    if (ptr == 0) { /* stuff */ }
which I believe is not possible with the current Boost smart_ptr. I've also
had issues with comparisons between shared_ptr<T> and T*. While this can be
avoided through minor changes of habit, it is much easier for me to overcome
the resistance of fellow programmers if they can literally drop in
shared_ptr<T> instead of T* and constructs such as the above occur
frequently enough to be an issue. While not optimally safe, I judge it
better to get a weaker version of smart pointer than no smart pointer at
all. But I understand the Boost point of view now.