The issue is that converting a raw pointer to a smart pointer under uncontrolled conditions can be dangerous. Remember that once a pointer is placed into a smart pointer the smart pointer system now "owns" the

and is responsible for its life time. If it was easy to do the conversion, then it would be easy to convert a raw pointer multiple times to a smart pointer (and eventually each conversion will lead to a delete of the value), place a pointer into a smart pointer that something else is controlling

lifetime, or even put a non-heap value into a smart pointer. Safe guidelines would suggest that the pointer be moved directly from the new call into

The "ugliness" of setting a shared pointer is intentional, to help protect from mistakes. I would say that 90% of code where the person wanted to say shared_pointer = raw_pointer is probably in error, where the person hasn't thought about the transfer of ownership that has happened. If the person has thought about it, it isn't that much harder to write shared_pointer.reset(raw_pointer), and in addition, as part of a code review, you can search for all occurrences of the latter, but not the former. Making a smart pointer look too much like a raw pointer, and you will start to forget the differences, and it becomes too easy to break its rules. As for the container, there is an operator = that handles shared_pointer1 = shared_pointer2, which is what would normally be wanted by the container. I do believe that the early versions of smart pointers had the operator = for shared_pointer = raw_pointer, and the sheer number of mistakes in usage is why it was removed. The removal does not really limit what you can do with the point, since you can always use the .reset() function, but it just makes it more obvious (unless it is buried in template code, in which case it most likely does NOT assume the proper ownership transfer). You are of course allowed to make your own smart pointer class that follows your own idea, and deriving from a smart pointer class will help with a lot of the work. Richard Damon -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Alessandro Re Sent: Monday, September 10, 2007 4:39 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Smart pointers operator= Thanks, but i still don't understand: with auto_ptr is possible to get() the raw pointer without changing owning, so a get()ted pointer may be invalid after ~auto_ptr(). And is also possible to assign a non-heap value to a smart pointer with int a; auto_ptr<int> p(&a). I find interesting the idea to use reset() explicitly to make easier code checking. Thanks also to Christian Larsen for his reply. But my point of view is unchanged: anyway one can do nasty things with smart pointers, they are just a convenient way to handle pointers in a safe manner. But, i say, a smart pointer should "look like" a raw pointer, no matter what happen behind. I think that omitting the operator=(raw pointer) is "ugly" to see and use... Well, i guess that using smart pointers is anyway a good practice, and of course one should know what he's doing when dealing with smart pointers. So if i assign shared_ptr = raw_ptr, the semantic is to put the raw pointer under the own of shared_ptr, in this way i don't need to care about it. Imho, if someone doesn't need shared_ptr facility, just don't use it :) And at last, isn't missing operator=(raw) a limitation for the use of auto_ptr? I mean, if someone creates a container which deals with pointers of some kind and need that the pointer type has operator=, the smart pointers doesn't fit this container. Of course this is how i see the things, but i find operator= more useful than harmful, so, a last question: what about deriving the x_ptr classes to add such operator? Thanks a lot On 9/10/07, Richard Damon wrote: pointer the the

smart pointer, and making that operation an explicit reset call makes it easier to search your code and check those occurrences to make sure you did it right.

Richard Damon

-- ~Ale _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users