Problems with the new KSharedPtr
raabe at froglogic.com
Wed Oct 26 15:54:02 BST 2005
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
More information about the kde-core-devel