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 calls. > >> 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 were showing that until I set the :pPtr to > > some other value ( not NIL ) only then I could see object relaesed. > > NIL was delaying them for some later time, may be due to GC nature. > > So I continued with it. > > I may be wrong, if yes, I will clean-up above code. > > It is always a pain to free it in two calls. > If you were right, we'd have serious problems in > our GC core collector, not just in HBQT but in any > .prg level apps using the same method (quite some). > I'd be very surprised though if we had such basic > problem in core. > If you don't believe me, it's best if you ask Przemek > for the final verdict.
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. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
