Hi, >> >> The HBQT_RELEASE_WITH_DESTRUTOR method does not release the memory >> allocated by the operator new. >>
> But logs suggest that it does. Do it tells a lie ? I think, you are referring to the log generated by the following lines: HB_TRACE( HB_TR_DEBUG, ( "hbqt_gcRelease_QUiLoader Object deleted! %i B %i KB", ( int ) hb_xquery( 1001 ), hbqt_getmemused() ) ); Yes, indeed the message is too optimistic, but in any case shows that the hbqt sends a request the Qt layer to do it. The FM statistic and valgrind output should be the basis of our investigations. >> The HBQT_RELEASE_WITH_DELETE_LATER method releases the allocated memory >> with a delay. >> > So it should be out of our experiments then. I will remove from generator. In this way, we will restrict the possibilities of the hbqt based application developers. This release method is useful in a situation when the object is no more necessary, but there are some pending events related to this object. > For sure we need a general solution. > But the solution above is destructive, I cannot even compile qtcore > after changes above to honour > hb_retptrGC( hbqt_gcAllocate_Q*( new Q*( hbqt_par_Q*( 1 )->somefunction( > hbqt_par_someparam( 2 ), someparamnext( 3 ) ) ) ) ); > The reason is we never want a "new" object for return values it it is > of type FAR. hbQT will not work at all as we will be dealing with local > copy of the object in question. If the type is not FAR we can employ > this technique. This is what is employed currently. > The solution could be like ( and I did it initially ): > Construct a GC pointer which holds this pointer and releases the wrapper > returned pointer. > BTW I am not a C guru so I may be wrong. So, this issue should be marked as TODO. Best regards, István _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
