Re: [Boost-users] shared_ptr<> null deleter

From: Noah Roberts (roberts.noah_at_[hidden])
Date: 2008-05-17 17:21:24

Nevin ":-]" Liber wrote:

> Please go back to the top and reread my rule of thumb (with Marshall's
> addendum, which I agree with and use).

You mean this:

My general rule of thumb is that if mucking with ownership or
lifetime, pass a smart pointer.  If not, pass a raw pointer.

Again, I disagree.  Did you think I didn't read it and didn't know what
I was disagreeing with?

Marshall's addendum, to which I replied, also doesn't change it for me
and relies, as the basis of its argument, on what I believe is
questionable design decisions.

> In other words, code written like that is fragile and should be used
> sparingly.

Exactly.  That's why I disagree.

  I prefer not to have fragile code,
> where the caller has to "be careful" (which is merely a euphemism for
> "be perfect", as any mistake creates a subtle bug).

Exactly why I disagree with your "rule of thumb".

> If you a way of passing a raw pointer or reference where it is always
> safe for the called function to copy and use that pointer or reference
> later without any external guarantees about the lifetime of the object
> pointed/referred to, I'd certainly be interested in hearing about it.

The fact that there is none is why I disagree.  At least a reference
advertises the fact that you certainly should not be keeping a copy.  So
use a shared pointer or other RAII device when a reference is
inappropriate...as a general rule of thumb.

By using a pointer you are already, "mucking with ownership issues."
Even if the answer to those issues is, "This function will not keep this
pointer."  So I think that your rule of thumb and the reasoning behind
it are flawed.  I can see when such is necessary given other
constraints, for you'll never be able to get code perfect by all
measures, but I do not like the idea of using it as a rule of thumb.  If
you see a pointer and you are not asking what the ownership semantics of
that pointer are, I'd say you're neglecting to consider a potentially
very large problem.

Furthermore, your general rule of thumb is going to kick you in the face
once you start mixing pointers gained and lost through other APIs such
as wxWidgets, where passing a pointer into a function can be disowning
it.  When your general rule of thumb is, "Avoid raw pointers," you can
separate that which you've created from these other libraries by simply
documenting that any raw pointer, unless otherwise commented, is owned
by that library.

Your rule of thumb seems arbitrary to me, fails to address the ownership
issue, and balances precariously upon the understanding of other
developers in the face of competing paradigms.  I don't think I like it.