Re: [Boost-users] Smart pointers operator=

From: Richard Damon (Richard_at_[hidden])
Date: 2007-09-10 17:41:05

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_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Alessandro Re
Sent: Monday, September 10, 2007 4:39 PM
To: boost-users_at_[hidden]
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 <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
_______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
http://lists.boost.org/mailman/listinfo.cgi/boost-users