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

[Peter Kümmel]

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
>