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

[Peter Kümmel]

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
>