[Kst] Architectural changes

[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.

cbn