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.

????

<<.>> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

"Jon Skeet [C# MVP]" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> <<.>> 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 - <(E-Mail Removed)>
> http://www.pobox.com/~skeet
> If replying to the group, please do not mail me too

> 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!

<<.>> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

n! <(E-Mail Removed)> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

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!" <(E-Mail Removed)> wrote in message
news:%23OnStqh%(E-Mail Removed)...
> > 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!
>
>

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:OiFEiEi%(E-Mail Removed)...
> 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!" <(E-Mail Removed)> wrote in message
> news:%23OnStqh%(E-Mail Removed)...
> > > 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!
> >
> >
>
>

<<.>> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

<<.>> 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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too