Re: [Boost-users] Smart pointers operator=

From: Alessandro Re (akirosspower_at_[hidden])
Date: 2007-09-10 16:39:04

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 <Richard_at_[hidden]> wrote:
> 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