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

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:

...

...

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

2008/5/16 Kevin Martin : 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@idio.com 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.