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

[Peter Kümmel]

Barth Netterfield wrote:
> Well...
> 
> I've been grinding through doing the changes listed below.... Tedious!
> 
> I admit I am a little confused about what you mean about removing the 
> ObjectStore, and what you would replace its functionality with.

I thought ObjectStore is mainly used for memory management which becomes
obsolete when we use shared pointers.
The only usefull thing which I currently see is
  DataSourceList dataSourceList() const;
and related functions. But this could be moved to a update class
splitted out from 'Object'.


> Its functionality is to have an essentially global list of objects.

Do we need such a monster? Making all objects global accessible?

> (ie, what is a 'container'?)

QVector, std::vector, ...
http://qt.nokia.com/doc/4.6/containers.html#container-classes


Peter

> 
> thanks!
> cbn
> 
> On Wednesday 02 December 2009 13:45:05 Peter Kümmel wrote:
>> Barth Netterfield wrote:
>>> On Friday 20 November 2009 12:49:06 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
>>> None-the-less, I think this is what we need to do in order to solve our
>>> memory leakage/fragility issues.
>>>
>>> -Delete SharedPtr
>>> -Move all ObjectPtr typedefs to use QSharedPointer
>>> -change all kst_cast to  qSharedPointerDynamicCast()
>>> -Make sure there are *no* bare pointers of any Kst::Objects
>>> -Get rid of all explicit destructor calls of any Kst::Objects (especially
>>> in the store).
>>>
>>> It will be long and tedious, but we should end up with a much safer
>>> system.
>> And a system where you know what's going on.
>>
>>> After that will be the task of replacing the locks with the QT
>>> equivalent, and making sure they are in the right place, before we go
>>> into multi-threading.
>>>
>>> Thoughts?
>>> cbn
>> In the meantime I think it will be better to start by removing
>> template<class T> ObjectStore::SharedPtr<T> createObject();
>> Then the compiler points us directly to the places where a container
>> should be used instead of ObjectStore.
>>
>> With attached patch it will be possible to do the changes step by step:
>> 1. enable KST_DISABLE_CREATE_OBJECT
>> 2. fix some classes
>> 3. disable KST_DISABLE_CREATE_OBJECT
>> 4. commit
>>
>> When all compiles with KST_DISABLE_CREATE_OBJECT defined applying your
>> changes from above maybe become simpler and could be done within one
>>  commit.
>>
>>
>> So the question remains, do we really wanna remove ObjectStore, and do
>> we know all implications?
>>
>> When we are sure, I could commit attached patch and we start patching
>> class by class: find createObject, remove it, remove also the store,
>> add a container with Qt' shared pointer. A problem will be when the store
>> is used as argument for function calls on other classes' member functions.
>>
>>> Currently, we can't do this with ViewObjects, as the QT graphics system
>>> holds them as bare pointers.
>> We should know the ownership for each object, then a solution would not
>> be complicated (I hope ;)
>>
>>
>> Peter
>>
>>
>> PS.:
>> Due to pchs it now builds with msvc MUCH faster! (On Linux I wasn't that
>>  impressed)
>>
> _______________________________________________
> Kst mailing list
> Kst at kde.org
> https://mail.kde.org/mailman/listinfo/kst
>