[Kst] Architectural changes

[Peter Kümmel]

Thanks for the explanations. I wrote the mail without looking at the
code. 
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.

Peter


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.
> 
> cbn
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst