[Harbour] Re: FM Stats - A puzzle I am unable to resolve

2010-01-29 Thread Pritpal Bedi
Przemysław Czerpak wrote: The above log does not mean that QT_QUILOADER_LOAD() was called more then once. It only means that inside this function or some deeper functions called from it few memory blocks were allocated and never released. Perfect explanation. Now I know that any reserved

Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve

2010-01-29 Thread Przemysław Czerpak
On Fri, 29 Jan 2010, Pritpal Bedi wrote: Hi, As I remember few weeks before /hbXBP/tests/demoxbp.exe was showing a clean log, and now it shows up with huge list of unreleased blocks. What I presume that after c++ stub introduced, it actually showed up real problem in Qt which we are

Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve

2010-01-29 Thread Przemysław Czerpak
On Fri, 29 Jan 2010, Szak�ts Viktor wrote: This class deals with loading UI object descriptions from disk and creates them in memory by making one QT call. So it's almost unlikely that these objects are created using HBQT GC allocator functions, but rather raw C++ memory allocations

[Harbour] Re: FM Stats - A puzzle I am unable to resolve

2010-01-29 Thread Pritpal Bedi
Viktor Szakáts wrote: Yes, these are shown because of the hbmk2 C++ stub, before the addition of it, basically no tests were accurate since the allocation functions were never overridden. It may also imply that Qt is taking two approaches, for alloc the standard C++ way and for

[Harbour] Re: FM Stats - A puzzle I am unable to resolve

2010-01-29 Thread Pritpal Bedi
Viktor Szakáts wrote: Yes, these are shown because of the hbmk2 C++ stub, before the addition of it, basically no tests were accurate since the allocation functions were never overridden. To streamline what is happening behind the curtain, can you show me a way how hbMK2 can be

[Harbour] Re: FM Stats - A puzzle I am unable to resolve

2010-01-29 Thread Pritpal Bedi
Przemysław Czerpak wrote: There is not differnce for GC id you make x := 1 x := NIL or x := NIL or x := 1 x := NIL x := .F. or ... in all cases only the 1-st assignment is significant. Thank you for explanation. I will clean the code accordingly. -

Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve

2010-01-29 Thread Mindaugas Kavaliauskas
Hi, BTW, I see such calls in many QT related calls in SVN: qObj:pPtr := 0 qObj:pPtr := NIL These can be optimized simply to: qObj:pPtr := NIL I used this method to release object instantly. This approach I took was since begining. My be my experiments at that point with Qt

Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve

2010-01-29 Thread Viktor Szakáts
Yes, these are shown because of the hbmk2 C++ stub, before the addition of it, basically no tests were accurate since the allocation functions were never overridden. It may also imply that Qt is taking two approaches, for alloc the standard C++ way and for releases some proprietory

Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve

2010-01-29 Thread Viktor Szakáts
Yes, these are shown because of the hbmk2 C++ stub, before the addition of it, basically no tests were accurate since the allocation functions were never overridden. To streamline what is happening behind the curtain, can you show me a way how hbMK2 can be directed not to use c++

Re: [Harbour] Re: FM Stats - A puzzle I am unable to resolve

2010-01-29 Thread Viktor Szakáts
BTW, I see such calls in many QT related calls in SVN: qObj:pPtr := 0 qObj:pPtr := NIL These can be optimized simply to: qObj:pPtr := NIL I used this method to release object instantly. This approach I took was since begining. My be my experiments at that point with Qt