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

[Peter Kümmel]

What about splitting out the update functionality in a new class,
eg. 'Updatable'?

Peter


Barth Netterfield wrote:
> 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
>>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>