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

Erik Hovland erik at hovland.org
Mon Oct 20 21:22:39 CEST 2008


> 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.

> 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.

> 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.

E

-- 
Erik Hovland
erik at hovland.org
http://hovland.org/


More information about the Amarok-devel mailing list