[Kst] branches/work/kst/kst1kde4/kst/src/libkst

[Barth Netterfield]

http://labs.trolltech.com/blogs/2009/08/25/count-with-me-how-many-smart-
pointer-classes-does-qt-have/

I *think* we are OK with QSharedPointer for Kst::Object as long as we make 
sure that every Kst::Object that gets created is only pointed to by a 
QSharedPointer (and never a normal pointer). And this is good policy anyway.

In this case, we would never call delete on a Kst::Object - QSharedPointer 
takes care of that for us.

The QExplicitlySharedPtr class is used for sharing data, not pointers.  I 
don't see any use case for copy-on-write for Kst::Object (in fact, copy 
contstuctors aren't even defined).  So in principle, they would work - but I 
think at this point we will be much happier with QSharedPointers, as long as 
we follow the simple rule: No Kst::Object *s anywhere!

This won't work for Kst::ViewItem, unfortunately, since these are all held by 
the QGraphicsItem class as plain pointers... so, no smart pointers for 
Kst::ViewItems at this point.

cbn

On Thursday 19 November 2009 12:49:12 Peter Kümmel wrote:
> Barth Netterfield wrote:
> > On November 19, 2009 11:43:27 am Peter Kümmel wrote:
> >> do we need the 'Explicitly' version?
> >
> > Explicitly shared objects inherit from a class which keeps track of their
> > usage counts internally.  With QShared, the pointer itself keeps tack of
> > usage - which is harder to manage.
> >
> > cbn
> 
> I know the Qt's classes where QSharedData is used to implement
> shared data classes.
> Implicit or "copy on write" classes, like most of Qt's classes, use
> QSharedDataPointer internally, classes which do not support "copy
> on write" and
> where you have to detach manually (explicit) uses
> QExplicitlySharedDataPointer internally:
> http://doc.qt.nokia.com/4.6-snapshot/qshareddata.html
> 
> For reference counting there is QSharedPointer.
> 
> We should map kst's classes to Qt's classes, and therefore the
> question:
> Do we need shared data objects where we have to call detach() or
> is "copy on write"
> enough. "copy on write" is less error prone because you could not
> forget to call
> detach.
> 
> Peter
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>