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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2002-09-26 07:56:01

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.
>
> According to (an admittedly old) spec (Annotated C++), 5.3.4 says "A
pointer
> to constant cannot be deleted" in reference to the delete operator. Since
> the value returned by this operator is a pointer to constant void, the
> statement you have should generate a compiler error. I've tested in on
MS-VC
> 6 (SP5) and it does not compile.

5.3.5/2 (ISO): "[Note: a pointer to a const type can be the operand of a
delete-expression; ...]"

> What kind of unwanted comparisons can occur? The ability to compare
directly
> to a raw pointer seems like a feature. It would seem that this just allows
> the same comparisons one would get with a raw pointer, which makes
> shared_ptr easier to drop in as a replacement.

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 *?