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-tp25434990p25480346.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
