The bane of Dangling Pointers

[Mark Kretschmann]

On Mon, Dec 21, 2009 at 1:53 PM, Ian Monroe <ian.monroe at gmail.com> wrote:
> QSharedPointers can be fairly dangerous if not used correctly. Whereas
> QPointer is to solve the dangling pointer issue, and are pretty much
> "free" for any QObject (they just connect to existing signals),
> QSharedPointers is for memory management. So you have to be mindful
> when using QShared*Pointers/KSharedPtr (basically you must ensure that
> the ref-counting is happening correctly by not passing around the bare
> pointer too much). And I would say its totally overkill if you're only
> worried about dangling pointers.
>
> Also QSharedPointers do their referencing counting inside the pointer
> object. This is inferior to QSharedDataPointer and KSharedPtr which
> hold the reference counter inside the object itself (so you can pass
> the bare pointer, make a QSharedDataPointer or KSharedPtr from it and
> the counting works just fine). So I'd say to always use KSharedPtr,
> unless you are holding a pointer to an object defined in a library
> that you can't derive from QSharedData.

That's right, and I talked to Thiago about this too. Basically, what
we really want in most cases is Qt 4.6's "QWeakPointer". It's a simple
Smart  Pointer that is not reference-counting, but yet thread-safe. So
it's basically a QPointer on steroids.

However, the QWeakPointer implementation is somewhat different in Qt
4.5 from that in Qt 4.6. In 4.5 it's not really of much use, and as we
depend on that still, we can't use the nicer version from Qt 4.6.

-- 
Mark Kretschmann
Amarok Developer
Fellow of the Free Software Foundation Europe
www.kde.org - amarok.kde.org - www.fsfe.org