[Kst] Architectural changes
syntheticpp at gmx.net
Sat Dec 12 10:11:24 CET 2009
Am Donnerstag, den 10.12.2009, 10:16 -0500 schrieb Barth Netterfield:
> After going through in detail the use of <Object>Ptrs in kst last week, I
> found and removed a couple places that were causing some our memory leaks and
> crashes, or at least causing KstSharedPtr to not delete things when it should
> (and to delete things when it shouldn't).
> The Store is basically a list, with a couple convenience functions thrown in
> (template functions to create and find objects). I think that this is how it
> should probably stay.
Yes, it seems essential to the current design.
> Kst uses KstSharedPtr, which does in fact seem to work just fine. I don't
> think we should change that either.
> (Note: KstSharedPtr has the huge advantage over a QSharedPtr that it stores
> its reference count in the object itself, so a KstSharedPtr can be converted
> into a bare pointer, passed somewhere, and converted back into a KstSharedPtr,
> and the reference count is happily carried over. Not so for QSharedPtr, which
> holds the reference count in the pointer itself.)
Having access to the reference count completely breaks the idea of
shared pointers, so I would say such must NOT happen, and if access
is needed, then there is a bug in the design.
It also makes the code more readable if one don't need to learn
some strange smart pointer behavior.
Therefore I would still replace KstSharedPtr, even when it is more
complicated at some places. If we leave KstSharedPtr it will bite
> The last big 'under-the-hood' work is related to locking. Currently, we are
> not multi-threaded, except for some stuff related to data-source
> initialization, so any locking troubles we might have, we don't currently
> face. This will need to be fixed. I propose we delay this until after 2.0.
> So: From now to 2.0, we should work only on critical bug fixes and critical
> or very easy feature fixes, which a goal of a 2.0 release on the weekend of
> January 1.
> The exception to this would be if we find a reason we would need to do an API
> change to data-sources or plugins, in which case the Jan 1 release would be
> called '2.0-beta4'
> Kst mailing list
> Kst at kde.org
More information about the Kst