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

"Peter Dimov" wrote in message news:009501c2655c$126794d0$1d00a8c0@pdimov2...

From: "Alan M. Carroll, CodeSlinger"

...

"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.

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.