shared_ptr NULL assignment

[T. Lovset]

Having tried before, but only got a few (grumpy) answers, I would like
to see some more solid objections on this proposal:

Modifying boost::shared_ptr from

template <class T> class shared_ptr {
...
public:
shared_ptr() : px(0), pn() {}

to

template <class T> class shared_ptr {
...
private:
struct null_tag {};
public:
shared_ptr(null_tag* = 0) : px(0), pn() {}
shared_ptr& operator=(null_tag*) { reset(); return *this; }

leaving everything else unchanged, will give these benefits:


1. It allows
void someFunc(const boost::shared_ptr<SomeClass>& ptr = NULL);
someFunc(NULL);

which currently must be written (!!):
void someFunc(const boost::shared_ptr<SomeClass>& ptr =
boost::shared_ptr<SomeClass>());
someFunc(boost::shared_ptr<SomeClass>());

2. It allows
boost::shared_ptr<SomeClass> ptr1(NULL);
boost::shared_ptr<SomeClass> ptr2 = NULL;

which both currently produce compiler errors.

3. It allows
ptr = NULL;

which currently must be written
ptr.reset();

4. It simplifies converting raw pointers to shared_ptrs, and the usage
is intuitive to new users.

5. This proposal introduces no other side-effects, and has no backward
compability issues.


Note: This proposal cannot be applied on auto_ptr because of its
special copy semantics, but these two classes have already different
usage and application areas. However, the proposal can by applied on
most other smart pointers.

Not that I find this to be an important improvement, I do find it a
bit frustrating how difficult it is to gain sympathy on such an
obvious (to me) and small matter. Not really. :D

++
T. Lovset

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Emil Dotchevski]

The problem is that what you propose defines operations on shared_ptr
objects which are syntactically identical to operations on raw
pointers, but with different semantics. In fact, this impedes
converting to shared_ptr existing code that uses raw pointers.

--Emil

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[T. Lovset]

Post by Emil Dotchevski
The problem is that what you propose defines operations on shared_ptr
objects which are syntactically identical to operations on raw
pointers, but with different semantics. In fact, this impedes
converting to shared_ptr existing code that uses raw pointers.
--Emil

Hmm... I assume that you refer to the assignment operation, because
surely the constructor NULL initialization has equal semantics for
both shared_ptr and raw pointers.

But I don't follow you. The semantics of the raw ptr assignment
ptr=NULL is simply that ptr should no longer point to any object. That
is the semantics of shared_ptr assignment to NULL too. In addition, it
will destroy the object it previously pointed to it if it was the last
reference to it, but that is not part of the functional content of a
NULL assignment.

Consider the code:
typedef SomeClass* SomeClassPtr;

SomeClassPtr ptr1 = new SomeClass;
SomeClassPtr ptr2 = ptr1;
...
ptr2 = NULL;
...
delete ptr1;
ptr1 = NULL;


You can rewrite it to use shared_ptr's:
typedef shared_ptr<SomeClass> SomeClassPtr;

SomeClassPtr ptr1(new SomeClass);
SomeClassPtr ptr2 = ptr1;
...
ptr2 = NULL;
...
ptr1 = NULL;

The rewrite basically removes the delete operation, but the NULL
assignments have equal semantics (or functional content) as in the raw
pointer version. Whether ptr1 is reclaimed to the heap at the last
line, later, or never, is functionally irrelevant, as long as the
object is available when there are pointers pointing to it.

I honestly don't see how this impeds converting from raw pointers to
shared_ptrs - please explain.

TL.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Roland Pibinger]

Post by Emil Dotchevski
The problem is that what you propose defines operations on shared_ptr
objects which are syntactically identical to operations on raw
pointers, but with different semantics. In fact, this impedes
converting to shared_ptr existing code that uses raw pointers.

shared_ptr shares this 'feature' with most smart pointers.
BTW, your name reminds me of a very instructive thread you started
some time ago:

Emil Dotchevski 'Why I think policy-based smart pointers are evil'.
http://groups.google.com/groups?threadm=5059663b.0305081105.175f11c6%40posting.google.com

Everyone interested in smart pointers, especially their not so smart
aspects, should read it.

Best regards,
Roland Pibinger

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]