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

From: Jonathan Turkanis (technews_at_[hidden])
Date: 2005-02-15 00:33:58

Chris Just wrote:
> Jonathan Turkanis wrote:
>>>> 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).
>>
>> Dangeous how? Actually the opposite is true: if you declare such a
>> function to take a raw pointer,
>
> I'm not an expert with compilers so I'll tell you how it was
> explained to me.  Different compilers could take the same C++ code
> and compile it into different machine code, causing function pointers
> to shift.  When you pass an object that was compiled on one machine
> to a function that was compiled on another machine, you can't be sure
> that the object will be deleted properly.

I guess you're talking about passing objects between modules compiled with
compilers having incompatible ABIs. In general this is a recipe for disaster. If
you restrict yourself to a C language interface you often have more flexibility,
but in that case you can't use smart pointers.

Is this what you mean?

At any rate, we've strayed considerably from the main point.

>> callers might think they still own the pointer after calling
>> the function, or the function might not clean up the resource
>> properly.
>
> That's what documentation is for.

Self-documenting code is much better, especially if violations of the contract
fail to compile.

Jonathan