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

"Peter Dimov" wrote in message news:019701c264b3$8af21640$1d00a8c0@pdimov2...

...

From: "Alan M. Carroll, CodeSlinger"

...

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

From: "Alan M. Carroll, CodeSlinger" 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.

What kind of unwanted comparisons can occur? The ability to compare

5.3.5/2 (ISO): "[Note: a pointer to a const type can be the operand of a delete-expression; ...]" 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 *?