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

[Adam Treat]

I haven't gone into the details of what you all are debating, but this might 
be informative when discussing anything related to shared ptr's and Qt:

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

Cheers,
Adam Treat - aka original author of kst2 port

On Friday 20 November 2009 12:49:06 pm Peter Kümmel wrote:
> Replacing sharedptr.h by
>
> #include <QSharedPointer>
> #define SharedPtr QSharedPointer
>
> and removing all inheritance from Shared kills really much.
> The whole hierarchy is in question.
>
> Peter
>
> 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
>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst