Hello Przemek
Przemyslaw Czerpak-2 wrote:
>
>> 2. If the object is released by Qt itself and detection line if( ph &&
>> * ph )
>> does not reconizes that the pointer has been releases.
>
> This detection works only for object released by GC block destructors
> or released/detached by your own helper functions which explicitly clear
> the reference inside ph. It does not help in any way to detect that
> object was released by QT code. To resolve this problem you should
> "detach" all objects which are managed by QT and will be released by
> QT code. If it's hard for you to implement such detaching then you
> should use guarded pointers as Teo suggested and store them in GC
> block instead of direct QObject pointers.
>
Yep. And I have already implemented it. It gives guard against pointer
for classes derived from QObject and this is a majot part of Qt.
I am looking for another class type ( very few but there ).
>> Please note that try{}catch{} mechanism is not helping any way.
>
> It usually do not help to resolve programmers errors so it's not a
> solution.
> Never create code which uses try/catch as some type of workaround for bugs
> in code, i.e. to hide problems with doubly free pointers.
>
Agreed.
>> 2. If it could be determined which type of object <ph> is referring
>> to.
>> [ All objects deriving from QObject are detected fine but any
>> other
>> class does not respect this construct, i.e. QSize and allied
>> classes ]
>
> You have to use different GC blocks with different destructors for each
> class which do not have common destructor. You can also add 'type' filed
> and try to implement it using single GC destructor function but IMO it's
> not good idea.
>
I am thinking of separate GC destructor.
However I would like to experiment with "type" field, what is this
and how it will behave? Some small code snippet will be handy.
>> 3. If GPF could be trapped anyway if any of the above implementions
>> are
>> not possible.
>
> It can be trapped but it will not resolve any problems so fighting
> with it it's a waste of time and in the worst case you will only
> hide very serious application bugs which will still exists but
> problems will be exploited in different places, i.e. GPFs in valid
> code which fails due to memory corruption caused by hidden real
> errors.
>
Agreed.
Thanks for your imput.
Regards
Pritpal Bedi
--
View this message in context:
http://www.nabble.com/HBQT---HBXBP-%3A-Garbage-Collection-tp25813841p25865871.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
