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

[Adam Treat]

Ahh, heh... looking over the entire thread seems you already posted this link.  
Sorry for the extra noise...
On Friday 20 November 2009 12:56:14 pm Adam Treat wrote:
> 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-smar
> > >>t- 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
>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst