Re: [boost] Re: Re: Re: Querying the Interest in a new AutoPtr class?

From: Chris Just (cpjust_at_[hidden])
Date: 2005-02-14 12:41:20

Jonathan Turkanis wrote:
>>>> I wanted to create a very simple AutoPtr that was essentially the
>>>> same as the STL auto_ptr (and backwards compatible with it).
>>>
>>> Unfortunately, you haven't (see below). Furthermore, auto_ptr is
>>> widely recognized as unsafe because it is too easy to transfer
>>> ownership unintentionally.
>>
>> Of course you can unintentionally transfer ownership if you don't
>> know what you're doing.  ;)
>
> The problem is that the code which transfers ownership appears innocuous on the
> surface, because auto_ptr allows transfer of ownership with the same syntax
> ordinarily used for copying:
>
>     void f()
>     {
>          auto_ptr<int> ptr(new int);
>          auto_ptr<int> ptr2(ptr); // ptr is now empty.
>     }

Why would anyone in their right mind do that?

>> I believe that's why you're not supposed to pass an auto_ptr to a
>> function -- instead you pass the pointer itself with .get().  You
>> can't stop everyone from shooting themselves in the foot.
>
> Declaring a function to take an argument of type auto_ptr<...> is one way to
> signal that ownership is being transfered to the function. It also ensures that
> the managed object will be deleted, unless the function takes explicit steps to
> cause a leak. Passing raw pointers defeats this system.

Yes, this is true if you're calling a function that you wrote and compiled yourself, but if you're
calling a 3rd party API that you didn't compile yourself, that can be dangerous (or so I've been
told).

>> How?  If you pass a pointer to a function, you shouldn't be deleting
>> it inside that function anyways (so pass it with .get()),
>
> What if you want to transfer ownership to the function, as is often the case?

Then pass ptr.release() to the function.

>> and if you
>> return a pointer from a function, you can save it in a new AutoPtr so
>> it will get deleted automatically...
>
> This depends on the calling code to do the right thing. If you return an
> auto_ptr, the managed object will be freed even if the calling code choses to
> ignore the return value.

I agree, if it's your own code, return an auto_ptr, but if you're an API, you must return a raw
pointer.

>> I don't set my pointer to NULL when I release() it, I just set
>> m_Owner = false.
>
> This behavior is not compatible with std::auto_ptr.

I could change it to set the pointer to NULL, but this is what Microsoft's auto_ptr does, and it
looked safer.

> move_ptr has the same overhead as auto_ptr.

Thanks, when I get some time I'll take a look at those.

As you might infer from some of my comments, I'm dealing mostly with API component code myself,
which integrates some older sub components, so I have no choice but to pass raw pointers most of
the time.

   Chris Just

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com