Re: [Boost-users] Rationale for explicit ctors in boost smart pointers

From: Matthias Kaeppler (noreply_at_[hidden])
Date: 2005-08-28 06:30:53

Peter Dimov wrote:
> One reason is that the pointer constructor assumes ownership of the pointer 
> and as such, it imposes the requirement that the pointer has to be 
> delete-able.
Not sure what you're getting at here. Do you mean, you want to avoid 
statements like:
coll.insert(NULL); // coll is a collection of smart pointers
?

> The design of shared_ptr is based on the premise that the user assumes the 
> responsibility of constructing the shared_ptr with a valid pointer (and not 
> invalidating the pointer afterwards). In return, shared_ptr promises that 
> the rest of the operations are safe and the passed pointer will be deleted 
> exactly once, using its original type.
Well, yes, that's why one uses a smart pointer in the first place. To 
completely move responsibility for allocating and freeing memory to the 
smart pointer device.

> Therefore, when doing a code review, you have to concentrate on shared_ptr 
> constructors (and the reset alias). For this to be possible, you have to be 
> able to locate them easily. If shared_ptr had an implicit constructor, all 
> kinds of innocent statements of the form
> 
> coll.insert( p );
> 
> could potentially create a shared_ptr, making the review much harder.
> 
Sorry, you have lost me here. The reason I would want to use some form 
of smart pointer facility is to pass the burden of memory management to 
some other instance. IOW, I don't want to care anymore. Why would I want 
to concentrate on shared_ptr ctors on a code review? I assume that it's 
handled correctly as long as I don't interfere (what you said before).

> For another reason, see the Best Practices section of the documentation.
I'll do that :)

Regards,
Matthias