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

[Barth Netterfield]

No worries...

If you would like to give us some advice about when to use 
QExplicitlySharedPointers (where the data is shared) vs QSharedPointers, 
(where only the pointer is shared) I would certainly be interested!

cbn

On Friday 20 November 2009 13:12:29 Adam Treat wrote:
> 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-sm
> > > >>ar 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
> 
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>