Hi By the way, you shuld newer call x->~TXobj directly. You !!!MUST delete x
Here is explanation http://www.parashift.com/c++-faq-lite/freestore-mgmt.html#faq-16.9 BRGS Franček Franček Prijatelj wrote: > > Hi Pritpal > > This behavior is usual for any C++ program. > > Here is example: > > > #include <iostream> > > using namespace std; > > class TRect > { > public: > TRect(int t,int l,int w,int h) > :_t(t),_l(l),_w(w),_h(h) > {} > > int top() const { return _t; } > int left() const { return _l; } > int width() const { return _w; } > int height() const { return _h; } > > private: > int _t,_l,_w,_h; > }; > > int main() > { > TRect *r1= new TRect(20,20,30,400); > cout << "before delete " << endl; > cout << r1->top() << endl; > cout << r1->left() << endl; > cout << r1->width() << endl; > cout << r1->height() << endl; > > delete r1; > cout << "after delete " << endl; > //r1=0; > cout << r1->top() << endl; > cout << r1->left() << endl; > cout << r1->width() << endl; > cout << r1->height() << endl; > return 0; > } > > /******** output > "before delete " > 20 > 20 > 30 > 400 > "after delete " > 0 > 20 > 30 > 400 > ************/ > > Because of that it's recomender to set pointers to 0 (r1=0) > > Brgs > Franček > > > > Pritpal Bedi wrote: >> >> Hello Viktor >> >> >> Viktor Szakáts wrote: >>> >>> This means QT cannot be used in apps which is supposed >>> to run continuously. (?) >>> >>> Continuously running GUI apps aren't that typical, but >>> to me it's still a serious concern that and app just >>> eats memory while running. This makes it f.e. unsuitable >>> for any sort of embedded GUI applications (like a kiosk). >>> >>> Is this a property of QT itself, or the property of >>> Harbour wrappers? >>> >> >> It is a property of Qt itself. >> I have made extensive experiments as far as Harbour's >> parameter passing is concerned and have reached to the >> conclusion that it is harmless. Experiments with Qt's >> object destruction has given me weired results. >> For example: >> >> oRect := QRect():new( 20,20,30,400 ) >> ? oRect:left() => 20 >> ? oRect:top() => 20 >> ? oRect:right() => 30 >> ? oRect:bottom() => 400 >> >> Qt_QRect_destroy( oRect ) >> ? oRect:left() => 4534342 ( a long figure ) >> ? oRect:top() => 8967354 ( another long figure ) >> ? oRect:right() => 30 >> ? oRect:bottom() => 400 >> >> .cpp >> >> HB_FUNC( QT_QRECT_DESTROY ) >> { >> delete hbqt_par_QRect( 1 ); >> // OR/AND >> hbqt_par_QRect( 1 )->~QRect(); >> } >> >> So even after destroy, oRect is an active pointer and >> only firts two slots are pointing to garbase. In theory >> after destroying it it should raise som error or appln >> must hang, but results are contrary. >> >> Though I have not given up, YET, on this issue, >> but at the face value ( till now ) it appears we cannot >> use Harbour-Qt for production level applications. >> >> NOTE: struggle is still on to overcome it. >> >> Regards >> Pritpal Bedi >> >> > > -- View this message in context: http://www.nabble.com/demoqt-tests-with-debug_new---Leaked-objects-tp25434990p25480744.html Sent from the Harbour - Dev mailing list archive at Nabble.com. _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
