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
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 pointer 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 the 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 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