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

[Barth Netterfield]

Actually, I am in the midst of a major update system redesign.

Kst::Object provides the interface for a number of general things related to 
updates.

cbn

On Friday 20 November 2009 12:20:52 Peter Kümmel wrote:
> Now I realize, sharedptr.h is only to implement a thread save smart
>  pointer, with the disadvantage that a class which SharedPtr points to must
>  inherit from Shared. So sharedptr.h could be completely replaced by
>  QSharedPointer.
> 
> I also have the impression often the only feature used from Object is the
> memory management, so I wonder if we couldn't remove inheritance of Object
> at several classes, because QSharedPointer works with any class.
> 
> Peter
> 
> Barth Netterfield wrote:
> > 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
> >
> > _______________________________________________
> > Kst mailing list
> > Kst at kde.org
> > https://mail.kde.org/mailman/listinfo/kst
> 
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>