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