[Kst] Architectural changes
syntheticpp at gmx.net
Tue Dec 15 22:29:06 CET 2009
Thanks for the explanations. I wrote the mail without looking at the
I will also try the port and see what happens. Anyway, I still tend to
separate memory management and user information.
And we also need good documentation about the architecture, not
only on our pointer strategy.
Am Dienstag, den 15.12.2009, 08:42 -0500 schrieb Barth Netterfield:
> I agreed with you until I actually spent too long trying to actually do the
> port and came to better understand how the current architecture works.
> On Saturday 12 December 2009 04:11:24 Peter Kümmel wrote:
> > > 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.
> We don't currently explicitly use the reference count (at least I hope I got
> rid of them) but the one place I was thinking of reading the reference count
> (but *never* changing it) it is in the data manager - to tell the user whether
> an object is being used anywhere - and if we decide to implement a 'purge'
> option, which was pretty useful.
> If we don't use the reference count here, we would need to go through all
> objects and see who is using who. I prefer to use the reference count. Why
> would using this be 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
> > us later.
> The biggest advantage with KstSharedPtr I found when trying to port to
> QSharedPointer is that there are numerous places where we give 'this' to
> another object, which needs to be able to rely on its continued existence.
> With KstSharedPtr, it can be cast to a smart pointer, and the reference count
> is kept correctly, including any other smart pointers to the object. With
> QSharedPointer, it can't - instead you would need to look up the object in the
> _store by name, and pass the QSharedPtr from there. Seems wrong to me.
> KstSharedPtr has is the same behavior as KDE3's KSharedPtr (in fact, it *is*
> KDE3's KSharedPtr), or QT's QExplicitlySharedPointer. We definitely need good
> documentation on our pointer strategy. I could imagine porting to
> QExplicitlySharedPointer, but I do think we need to stick with this general
> family of shared pointer.
> Kst mailing list
> Kst at kde.org
More information about the Kst