syntheticpp at gmx.net
Fri Nov 20 18:49:06 CET 2009
Replacing sharedptr.h by
#define SharedPtr QSharedPointer
and removing all inheritance from Shared kills really much.
The whole hierarchy is in question.
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.
> Barth Netterfield wrote:
>> 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.
>> 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.
>>> 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:
>>> For reference counting there is QSharedPointer.
>>> We should map kst's classes to Qt's classes, and therefore the
>>> 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
>>> Kst mailing list
>>> Kst at kde.org
>> Kst mailing list
>> Kst at kde.org
> Kst mailing list
> Kst at kde.org
More information about the Kst