[patch] Looking for an opinion on std::auto_ptr

[Ian Monroe]

On Mon, Oct 20, 2008 at 2:22 PM, Erik Hovland <erik at hovland.org> wrote:
>> Like has been already pointed out, we use KSharedPtr. KSharedPtr has a
>> major advantage over std::auto_ptr in that the reference counter
>> exists in the object instead of a pointer. So if you have a
>> KSharedPtr, pass it to a function as a plain pointer and then make
>> another KSharedPtr of the plain pointer, the reference count remains
>> accurate (the situation in which this would happen is more complicated
>> likely).
>
> KSharedPtr has a major disadvantage. To use it on anything that thing
> has to inherit from KShared.

It's QSharedData, and this is why its so much better then auto_ptr. It
does make it difficult to use for data objects willy nilly which is
just as well. :)

>> Also you have to use .get() to see if its null or not? KSharedPtr can
>> always be used just like a pointer.
>
> Yes, to get to the underlying pointer - you have to use get(). That I dislike.
> This was likely done to make sure that it was easy to get to the pointer of
> the auto_ptr object itself.

They should've added a boolean operator like KSharedPtr has.

>> That said I don't like that patch regardless since its fixing
>> something that isn't broken. Creating an object and then deleting it
>> two lines later seems fine. Personally I think use of reference
>> counting pointers should be restricted to where they are actually
>> needed - objects like Meta::Track that get passed around to many
>> objects and keeping track of it manually would be complicated and
>> buggy.
>
> Well, it does fix one memory leak in the first usage. And the throwing
> auto_ptr around was done more to explain the usage not to fix anything.
>
> But I don't mind if you like typing 'delete' all the time and making sure
> "everything" is cleaned up. I'll just change the patch so that the
> delete is done.

You can just go ahead and commit it at that point.

Ian