[Kst] Re: branches/work/kst/portto4/kst
Peter Kümmel
syntheticpp at gmx.net
Sat Jan 1 18:26:45 CET 2011
Happy new year Barth! I though you are back in Canada but it
seems you had a very cold Christmas ;)
I had forgotten completely the "Architectural changes" thread
from Dec 2009. Reading it again I see that nothing has changed,
facts and my opinion about KstSharedPtr ;)
I also discovered by my own that the main problem is the switching
between raw pointers and smart pointers. I will investigate it
further because I wonder why we need to pass raw pointers around
and to understand how it works at the moment. But I will be very
carefully and when the changes become to big I'll make a branch.
I think the benefits will be a simpler to maintain code, less memory
leaks, maybe more type checking by the compiler and at least I will
understand the code better. Working on this we get a lot of help from
the compiler and of Qt's checks in QSharedPointer, so I'm confident
that there will be not too much big surprises at runtime. So let's
see how far will get.
Threading would be good with all these cores around.
Peter
PS, the BLAST pages are very interesting. But I have no
real imagination how Kst looks like in your real world
application. Do you think some screen shots are worth to
add to our web page?
On 01.01.2011 13:06, Barth Netterfield wrote:
> Thanks Peter.
>
> As you say, I looked into this extensively a year ago. (See the
> thread Titled "Architectural changes" from Dec 2009). The main issue
> is that QSharedPtr stores the reference count externally, so once it
> has been passed through a plain pointer, the referencing is lost.
> KSharedPtr (or, KstSharedPtr) store the reference in the object
> itself, which lets one go back and forth when necessary. This is
> important in places where we pass 'this' on to another class - eg, a
> dialog - which needs to keep a reference to the object. QSharedPointer
> would require us to look up the object's QSharedPointer from the
> store() in order to maintain reference. This might be OK. I would
> like to keep the store() around, as it makes a lot of things easy to
> handle.
>
> I tend to be conservative about making a major change like this unless
> we are pretty sure it will provide actual benefit to users over the
> long term. There are certainly memory leaks in kst2 (I just
> experienced on while writing this email) so further cleaning of the
> memory system makes sense. Whether it is better to fix our usage of
> KSharedPtr, or to change over to QSharedPointers I'll leave up to you,
> but please consider carefully: are you fairly sure this change will
> result in a real benefit?
>
> We also need to get to threading one of these days.
>
> cbn
>
> PS, BLAST is flying right now, and so I am spending about 15 hours/day
> down here in Antarctica staring at kst2 plots of its performance.
>
> Where our balloon is right now:
> http://www.csbf.nasa.gov/map/balloon8/balloon8.htm
> Links about the project, including photoblogs: http://blastexperiment.info/
>
> On Sat, Jan 1, 2011 at 9:18 AM, Peter Kümmel <syntheticpp at gmx.net> wrote:
>> Yes, my plan is to replace Kst::Shared and Kst::SharedPtr by QSharedPointer.
>> Currently it seems to me that the lifetime management of objects is a little
>> bit cumbersome, hard to understand, and influenced by legacy code of KDE3.
>> But now we have Qt4 and QSharedPointer, so why should we implement our own
>> shared pointer class?
>>
>> The idea is to use the well known reference counted shared pointer C++ idiom,
>> implemented by QSharedPointer. The current solution is a bit wired because it
>> strongly correlates "worker" classes with the memory management system
>> (protected destructors, friend classes). But in principle it should be enough
>> to follow two paradigm:
>> - a object will not be deleted when it is in use, means an objects holds
>> a shared pointer.
>> - maybe it is necessary to register a object globally so it can be used by
>> other functions.
>>
>> I know we have discussed this topic a bit a year ago without a result,
>> but now having the merged build of cmake it doesn't hurt to recompile
>> everything again and again, so I tried it again. And while investigating
>> bug https://bugs.kde.org/show_bug.cgi?id=261260
>> I thought that the main reason for this bug is the memory management.
>>
>> Because I don't wanna make a branch I've used a macro which is disabled by
>> default. As mentioned in the commit message it's only the beginning
>> of the replacement, but I will have much time in January to finish it.
>>
>> I plan to replace more and more and if I don't get stopped by an overseen
>> feature of the old approach Kst::Shared and Kst::SharedPtr will be gone
>> and also all the #ifdef ST_USE_QSHAREDPOINTER.
>>
>> You know the old system much better, don't you also think it is a little
>> bit aged? Especially having the scripting support in mind I think a more
>> up-to-date system will avoid problems in future.
>>
>> Peter
>>
>>
>>
>>
>>
>>
>> On 31.12.2010 19:55, Barth Netterfield wrote:
>>> Peter,
>>>
>>> Can you outline your plan in a little more detail.
>>> Are you planning to replace KstSharedPtr? If so, this needs to be discussed.
>>>
>>> cbn
>>>
>>> On Sat, Jan 1, 2011 at 6:51 AM, Peter Kümmel <syntheticpp at gmx.net> wrote:
>>>> SVN commit 1210492 by kuemmel:
>>>>
>>>> Start port to QSharedPointer:
>>>> - the current live time handling is no standard C++ idiom
>>>> - implementing a shared pointer is legacy code from KDE 3
>>>> - QSharedPointer is a bullet proofed Qt class
>>>> - better encapsulation: objects should not know how they are stored (remove inheritance from Shared)
>>>> - define KST_USE_QSHAREDPOINTER in sharedptr.h to enable new code
>>>>
>>>> One problem is the pointer -> SharedPointer transition, because mostly there exists already
>>>> a QSharedPointer for the object Qt asserts. Could be solved with a consequent usage of shared pointers.
>>>> Don't know why raw pointers are used.
>>>>
>>>>
>>>> M +12 -0 devel-docs/Kst2Specs/Wishlist
>>>> M +2 -0 src/libkst/datamatrix.cpp
>>>> M +5 -0 src/libkst/datamatrix.h
>>>> M +4 -0 src/libkst/dataplugin.h
>>>> M +4 -0 src/libkst/datavector.cpp
>>>> M +6 -0 src/libkst/datavector.h
>>>> M +6 -0 src/libkst/matrix.h
>>>> M +9 -1 src/libkst/object.cpp
>>>> M +9 -1 src/libkst/object.h
>>>> M +11 -0 src/libkst/objectstore.h
>>>> M +13 -0 src/libkst/primitive.h
>>>> M +37 -1 src/libkst/sharedptr.h
>>>> M +5 -2 src/libkst/timezones.h
>>>> M +6 -0 src/libkst/vector.h
>>>> M +5 -0 src/libkstmath/basicplugin.h
>>>> M +6 -0 src/libkstmath/csd.h
>>>> M +5 -0 src/libkstmath/curve.h
>>>> M +1 -1 src/libkstmath/curvehint.cpp
>>>> M +4 -0 src/libkstmath/curvehint.h
>>>> M +8 -8 src/libkstmath/dataobject.cpp
>>>> M +6 -0 src/libkstmath/dataobject.h
>>>> M +6 -0 src/libkstmath/equation.h
>>>> M +6 -0 src/libkstmath/eventmonitorentry.h
>>>> M +6 -0 src/libkstmath/histogram.h
>>>> M +6 -0 src/libkstmath/image.h
>>>> M +6 -0 src/libkstmath/psd.h
>>>> M +8 -8 src/libkstmath/relation.cpp
>>>> MM +6 -0 src/plugins/filters/cumulativesum/cumulativesum.h
>>>> M +4 -0 src/widgets/matrixselector.cpp
>>>> M +4 -0 src/widgets/scalarselector.cpp
>>>> M +4 -0 src/widgets/stringselector.cpp
>>>> M +4 -0 src/widgets/vectorselector.cpp
>>>>
>>>>
>>>> http://websvn.kde.org/?view=rev&revision=1210492
>>>> _______________________________________________
>>>> 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
>>
>
>
>
More information about the Kst
mailing list