Boost logo

Boost Users :

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


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net