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

[Barth Netterfield]

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.

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

(ie, what is a 'container'?)

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)
>