473,322 Members | 1,504 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

Destructon of .NET objects

Hi,

Why doesnt the runtime set the object to null when the finalizer has been
called? Wouldnt this prevent a slew of bugs?

I just called the obj.__dtor(); from a MC++ wrapper class I made and its
still referencing the type even tho its "destructed". Why do I have to set
it to null in my view it should be set by destruction.

????

Jul 21 '05 #1
13 1873
<<.>> wrote:
Why doesnt the runtime set the object to null when the finalizer has been
called? Wouldnt this prevent a slew of bugs?


Where exactly would it set it to null? Would you want it to walk
through the entire managed heap (and stack) to find all references to
the object? If there are references to the object, why has it been
finalized in the first place? Presumably either because the objects
referring to it are eligible for garbage collection too, or because it
doesn't know the type of the data, in which case it wouldn't know to
set that to null anyway.

Note that there's no such thing as "setting an object to null" -
there's only setting the value of a reference-type variable to null.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #2

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<<.>> wrote:
Why doesnt the runtime set the object to null when the finalizer has been called? Wouldnt this prevent a slew of bugs?
Where exactly would it set it to null? Would you want it to walk
through the entire managed heap (and stack) to find all references to
the object? If there are references to the object, why has it been
finalized in the first place? Presumably either because the objects
referring to it are eligible for garbage collection too, or because it
doesn't know the type of the data, in which case it wouldn't know to
set that to null anyway.


If it doesnt know where to set it to null, then how does it know what and
where the object reference is in the first palce.
Ofcourse it can set the reference to null, its knows where it is, what it is
and its been destructed, simple matter of setting that reference to null.
Note that there's no such thing as "setting an object to null" -
there's only setting the value of a reference-type variable to null.

Thats what I mean. --
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #3
n!
> If it doesnt know where to set it to null, then how does it know what and
where the object reference is in the first palce.
Ofcourse it can set the reference to null, its knows where it is, what it is and its been destructed, simple matter of setting that reference to null.


As Jon said, why is it being finalized when you still have a reference to
it? It wouldn't be garbage collected if it was 'live'.

It knows where the object is, but not its references. IIRC the garbage
collector works by determining which objects are live, and then removing the
others (as, by definition, they are not live) so it wouldn't know *where*
they were being referenced unless it touched *everything* :) I think this is
what Jon was implying?

n!
Jul 21 '05 #4
<<.>> wrote:
Where exactly would it set it to null? Would you want it to walk
through the entire managed heap (and stack) to find all references to
the object? If there are references to the object, why has it been
finalized in the first place? Presumably either because the objects
referring to it are eligible for garbage collection too, or because it
doesn't know the type of the data, in which case it wouldn't know to
set that to null anyway.
If it doesnt know where to set it to null, then how does it know what and
where the object reference is in the first palce.


Usually it does - but you may have some opaque data which the GC
doesn't know about. Don't forget that the GC won't have necessarily
walked all paths where there might be a reference - only paths where
there might be a reference which would keep the object alive.
Ofcourse it can set the reference to null, its knows where it is, what it is
and its been destructed, simple matter of setting that reference to null.


But if there are non-null references, why is the object being destroyed
in the first place? It has to be due to all the other references being
within objects which are about to be destroyed anyway - so why do you
care? (Note that the object itself won't be destroyed until everything
that has a reference to it is about to be destroyed - if there's a
finalizer which can access the object, the object can itself be
finalized but not destroyed.)
Note that there's no such thing as "setting an object to null" -
there's only setting the value of a reference-type variable to null.


Thats what I mean.


Personally I'm happier with it not having to look all over the heap for
things to do when there's no need to.

Why do you think you need it to do this? What's your use case?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #5
n! <nf********@nomailplease.com> wrote:
It knows where the object is, but not its references. IIRC the garbage
collector works by determining which objects are live, and then removing the
others (as, by definition, they are not live) so it wouldn't know *where*
they were being referenced unless it touched *everything* :) I think this is
what Jon was implying?


Yup - although assuming it's doing its job, it would actually only need
to look at all the other objects which are eligible for garbage
collection. That's still a significant overhead, IMO.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #6
Becuase I called the __dtor and that calls delete obj; in my mixed mode C++
assembly.

Just curious why it cant be set to null as this is something I would do
myself on all destructed objects. When its destructed it wont be used again
until a new reference is constructed. Setting it to null would make it
more obvious that its no longer valid and could go and construct a new
reference is thats needed.

"n!" <nf********@nomailplease.com> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...
If it doesnt know where to set it to null, then how does it know what and where the object reference is in the first palce.
Ofcourse it can set the reference to null, its knows where it is, what
it is
and its been destructed, simple matter of setting that reference to
null.
As Jon said, why is it being finalized when you still have a reference to
it? It wouldn't be garbage collected if it was 'live'.

It knows where the object is, but not its references. IIRC the garbage
collector works by determining which objects are live, and then removing the others (as, by definition, they are not live) so it wouldn't know *where*
they were being referenced unless it touched *everything* :) I think this is what Jon was implying?

n!

Jul 21 '05 #7
If you set an object to Nothing (not null), it will cause that object's
Dispose method to fire and "flag" the object as eligible for removal from
the heap the next time the GC does its clean up. Setting the object to
Nothing won't cause its finalize method to run or remove it from the heap.

Since an object will fire its dispose method and get "flagged" as eligible
fro removal from the heap when it falls out of scope anyway, there is not
usually a need to explicitly set your objects to Nothing. You are, however,
allowed to do this as setting the object to Nothing yourself, rather than
waiting for it to fall out of scope, can speed up the call to the object's
dispose method. If you have your own code in that method, it will run a bit
sooner this way. For most applications though, the delay in waiting for the
object to fall out of scope is negligible.
<.> wrote in message news:Oi****************@tk2msftngp13.phx.gbl...
Becuase I called the __dtor and that calls delete obj; in my mixed mode C++ assembly.

Just curious why it cant be set to null as this is something I would do
myself on all destructed objects. When its destructed it wont be used again until a new reference is constructed. Setting it to null would make it
more obvious that its no longer valid and could go and construct a new
reference is thats needed.

"n!" <nf********@nomailplease.com> wrote in message
news:%2******************@TK2MSFTNGP11.phx.gbl...
If it doesnt know where to set it to null, then how does it know what and where the object reference is in the first palce.
Ofcourse it can set the reference to null, its knows where it is, what it
is
and its been destructed, simple matter of setting that reference to
null.

As Jon said, why is it being finalized when you still have a reference

to it? It wouldn't be garbage collected if it was 'live'.

It knows where the object is, but not its references. IIRC the garbage
collector works by determining which objects are live, and then removing

the
others (as, by definition, they are not live) so it wouldn't know *where* they were being referenced unless it touched *everything* :) I think

this is
what Jon was implying?

n!


Jul 21 '05 #8
<<.>> wrote:
Becuase I called the __dtor and that calls delete obj; in my mixed mode C++
assembly.
Hmm... I'm not entirely sure that calling the destructor actually
*does* delete the object. It might call the finalizer, but that's not
the same as deleting or destroying the object. I don't know much about
mixed mode C++, but I'd expect the actual memory to still be allocated
until the GC collects the object in the normal way.
Just curious why it cant be set to null as this is something I would do
myself on all destructed objects. When its destructed it wont be used again
until a new reference is constructed. Setting it to null would make it
more obvious that its no longer valid and could go and construct a new
reference is thats needed.


Keeping live references to destroyed objects strikes me as a pretty
rare (and dangerous) thing to do. Why should everyone else who relies
on the GC to do things automatically suffer nasty performance penalties
because you don't want to rely on it?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #9
Well it should because its wrapping an unmanaged class, its calling the
delete.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<<.>> wrote:
Becuase I called the __dtor and that calls delete obj; in my mixed mode C++ assembly.


Hmm... I'm not entirely sure that calling the destructor actually
*does* delete the object. It might call the finalizer, but that's not
the same as deleting or destroying the object. I don't know much about
mixed mode C++, but I'd expect the actual memory to still be allocated
until the GC collects the object in the normal way.
Just curious why it cant be set to null as this is something I would do
myself on all destructed objects. When its destructed it wont be used again until a new reference is constructed. Setting it to null would make it
more obvious that its no longer valid and could go and construct a new
reference is thats needed.


Keeping live references to destroyed objects strikes me as a pretty
rare (and dangerous) thing to do. Why should everyone else who relies
on the GC to do things automatically suffer nasty performance penalties
because you don't want to rely on it?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #10
Its unmanaged, so the GC wont touch it, its stored on an unmanaged heap. On
mixed mode modules you have 2 heaps, managed and unmanaged. Its you to you
to manage the unmanaged heap as you normally would. If its not deleted then
somethings seriously wrong I would imagine. As for the managed wrapper, we
cannot tell when thats destructed, are you saying that the managed type even
tho the destructor is called, its never finalized until I set it to null
myself? If it is destructed at somepoint, why cant it just set it to null
as its obviously an invalid reference at that point.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
<<.>> wrote:
Becuase I called the __dtor and that calls delete obj; in my mixed mode C++ assembly.


Hmm... I'm not entirely sure that calling the destructor actually
*does* delete the object. It might call the finalizer, but that's not
the same as deleting or destroying the object. I don't know much about
mixed mode C++, but I'd expect the actual memory to still be allocated
until the GC collects the object in the normal way.
Just curious why it cant be set to null as this is something I would do
myself on all destructed objects. When its destructed it wont be used again until a new reference is constructed. Setting it to null would make it
more obvious that its no longer valid and could go and construct a new
reference is thats needed.


Keeping live references to destroyed objects strikes me as a pretty
rare (and dangerous) thing to do. Why should everyone else who relies
on the GC to do things automatically suffer nasty performance penalties
because you don't want to rely on it?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #11
<<.>> wrote:
Well it should because its wrapping an unmanaged class, its calling the
delete.


I dare say it's deleting the unmanaged class it's wrapping, but whether
that means it's deleting the managed class itself is a different
matter.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #12
<<.>> wrote:
Its unmanaged, so the GC wont touch it, its stored on an unmanaged heap. On
mixed mode modules you have 2 heaps, managed and unmanaged. Its you to you
to manage the unmanaged heap as you normally would. If its not deleted then
somethings seriously wrong I would imagine. As for the managed wrapper, we
cannot tell when thats destructed, are you saying that the managed type even
tho the destructor is called, its never finalized until I set it to null
myself? If it is destructed at somepoint, why cant it just set it to null
as its obviously an invalid reference at that point.


I'm not *entirely* sure whether or not there's any difference between
the finalizer and the destructor - there certainly isn't in C#.

However, in the normal managed world, no - the object won't be
finalized or garbage collected until there are no live references to it
left. You can't manually force a specific object to be garbage
collected.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jul 21 '05 #13
so, the reference to the object is a reference variable within your wrapper
class... right?

I assume that this is a managed code wrapper class. (not sure how you'd
have a reference to a managed code object in unmanaged code, but I'm not a
C++ developer... if you have done this: you'd have no right to complain...
the garbage collector runs in managed code... it couldn't reach in to your
unmanaged class and modify your reference variable, even if it wanted to).

Assuming all managed code: If you have a reference to the object, it has not
been garbage collected (by definition... you have a reference to it). You
may have called the destructor, which ran a method on the object, but you
are responsible for changing the value of your reference variable to 'null',
not the destructor or any part of the system.

I guess I'm as perplexed by your question as the other folks here...

--- Nick

<.> wrote in message news:el****************@TK2MSFTNGP09.phx.gbl...
Hi,

Why doesnt the runtime set the object to null when the finalizer has been called? Wouldnt this prevent a slew of bugs?

I just called the obj.__dtor(); from a MC++ wrapper class I made and its
still referencing the type even tho its "destructed". Why do I have to set
it to null in my view it should be set by destruction.

????

Jul 21 '05 #14

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

13
by: | last post by:
Hi, Why doesnt the runtime set the object to null when the finalizer has been called? Wouldnt this prevent a slew of bugs? I just called the obj.__dtor(); from a MC++ wrapper class I made and...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.