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

From: Marshall Clow (marshall_at_[hidden])
Date: 2008-05-16 18:29:36

At 3:13 PM -0700 5/16/08, Noah Roberts wrote:
>Marshall Clow wrote:
>>  At 2:37 PM -0500 5/16/08, Nevin \":-]\" Liber wrote:
>>>  2008/5/16 Kevin Martin <kev82_at_[hidden]>:
>>>>   My problem is module interfaces. I have a module (set of classes) that
>>>>   solve a problem, and they require data. They don't care whether that
>>>>   data is on the heap, the stack, or the moon. They just want a pointer
>>>>   to it. In this case it is arguable that the pointers passed shouldn't
>>>>   be smart pointers at all, just normal pointers.
>>>  My general rule of thumb is that if mucking with ownership or
>>>  lifetime, pass a smart pointer.  If not, pass a raw pointer.
>>
>>  A brief addenda (from my rules of thumb) for non-ownership cases:
>>	* If the parameter is optional, pass a raw pointer, and the
>>  callee should
>>  expect a NULL pointer.
>>	* If the parameter is not optional, pass a reference.
>
>I don't like this idea.  You are creating a dependency on the fact that
>the called function will NOT keep a copy - or you are insisting that the
>object in question implement the shared_from_this model.

I explicitly qualified this approach with "for non-ownership" cases.

As for the other point - I certainly am.

When I write a routine that returns an std::auto_ptr<whatever> I am 
creating a dependency on the fact that the routine will allocate some 
memory and return it - and it is the responsibility of the caller to 
deal with that. Alternately, if I write a routine that takes an 
auto_ptr<whatever> as a value parameter, that means that I expect the 
callee to dispose of that memory. This is another way (sadly not 
enforced by the language; hence just a convention) to indicate 
parameter requirements.

>If you later
>decide that it would be prudent for the function or object in question
>to create or pass a kept copy of this object then you'll have to change
>the signature of the function and then each and every call to it (to
>remove get() calls).

Yes. And since the semantics of the routine are changing, I have to 
examine each and every call to the routine anyway to determine if 
such a change will introduce bugs. I don't see that that is less 
work. The only difference between changing the semantics and changing 
the calling convention is that the compiler will help you if you 
change the calling conventions.

-- 
-- Marshall
Marshall Clow     Idio Software   <mailto:marshall_at_[hidden]>
It is by caffeine alone I set my mind in motion.
It is by the beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.