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

[Peter Kümmel]

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)

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: remove.patch
Url: http://mail.kde.org/pipermail/kst/attachments/20091202/a677181b/attachment-0001.bat