Problems with the new KSharedPtr

[Frerich Raabe]

On Wednesday 26 October 2005 16:37, David Faure wrote:
> I forgot the reasoning for switching to refcount-in-the-pointer instead of
> refcount-in-the-object, but after fixing kdelibs for 3 days due to the new
> KSharedPtr, and it's still far from being completely fixed, I have very
> strong reservations against it.

[..]

> I'm asking for reverting to the KShared mechanism, it did work fine.

I think that makes most sense in retrospective, yes. I did not anticipate 
(and, as far as I see when re-iterating over the threads of a month ago, 
nobody who read the code and/or contributed to the threads) the big amount of 
code in kdelibs which depends on the reference count being in the object.

> The only thing we gained in the new KSharedPtr was the conversion from
> KSharedPtr<Base> to KSharedPtr<Derived> without ugly casts, but let's just
> port that over to the old KSharedPtr (either the same way, auto conversion,
> or with an explicit cast method).

The lack of a T* conversion and thread-safe reference counting and pointer 
handling are probably nice things, but we can have *that* in the old pointer 
just as well.

I suggest checking out the old KSharedPtr, removing the T* conversion, adding 
the template constructor/assignment operator (because those avoided some very 
ugly casts), and adding QAtomic-based reference counting in KShared.

-- 
Frerich Raabe - raabe at froglogic.com
www.froglogic.com - Qt consulting and add-ons