Is Sub Finalize Implicity Created on Classes?

Hi. Is Sub Finalize Implicity created at run-time by the CLR, even if you
(the programmer) don't explicity create a Sub Finalize method on the class?

Thanks

PRSoCo
Mon Mar 17 15:08:00 CDT 2008

No, the runtime does not add a Finalize method if the class doesn't have one.
The class would inherit Object.Finalize.

Why do you ask?

--
Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
http://www.peterRitchie.com/blog/
Microsoft MVP, Visual Developer - Visual C#


"Mike" wrote:

> Hi. Is Sub Finalize Implicity created at run-time by the CLR, even if you
> (the programmer) don't explicity create a Sub Finalize method on the class?
>
> Thanks

Mike
Mon Mar 17 15:16:06 CDT 2008

Ok. I'm just trying to better understand the processes that occur when an
object is destroyed. Based on what I've read thusfar with Sub Finalize, I
was under the impression that it acted like Sub New, in that the CLR created
it if you didn't.

"Peter Ritchie [C# MVP]" wrote:

> No, the runtime does not add a Finalize method if the class doesn't have one.
> The class would inherit Object.Finalize.
>
> Why do you ask?
>
> --
> Browse http://connect.microsoft.com/VisualStudio/feedback/ and vote.
> http://www.peterRitchie.com/blog/
> Microsoft MVP, Visual Developer - Visual C#
>
>
> "Mike" wrote:
>
> > Hi. Is Sub Finalize Implicity created at run-time by the CLR, even if you
> > (the programmer) don't explicity create a Sub Finalize method on the class?
> >
> > Thanks

Jon
Mon Mar 17 15:24:17 CDT 2008

Mike <Mike@discussions.microsoft.com> wrote:
> Ok. I'm just trying to better understand the processes that occur when an
> object is destroyed. Based on what I've read thusfar with Sub Finalize, I
> was under the impression that it acted like Sub New, in that the CLR created
> it if you didn't.

The CLR doesn't create constructors for you either. The compiler might
(it does in C#, for instance, if you're not writing a static class and
you don't explicitly provide any constructors) but the CLR doesn't.

--
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

Mike
Mon Mar 17 15:38:02 CDT 2008

Ok, thanks for the clarification.

"Jon Skeet [C# MVP]" wrote:

> Mike <Mike@discussions.microsoft.com> wrote:
> > Ok. I'm just trying to better understand the processes that occur when an
> > object is destroyed. Based on what I've read thusfar with Sub Finalize, I
> > was under the impression that it acted like Sub New, in that the CLR created
> > it if you didn't.
>
> The CLR doesn't create constructors for you either. The compiler might
> (it does in C#, for instance, if you're not writing a static class and
> you don't explicitly provide any constructors) but the CLR doesn't.
>
> --
> Jon Skeet - <skeet@pobox.com>
> http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
> World class .NET training in the UK: http://iterativetraining.co.uk
>

Peter
Mon Mar 17 15:55:16 CDT 2008

On Mon, 17 Mar 2008 13:16:06 -0700, Mike <Mike@discussions.microsoft.com>
wrote:

> Ok. I'm just trying to better understand the processes that occur when
> an
> object is destroyed. Based on what I've read thusfar with Sub Finalize,
> I
> was under the impression that it acted like Sub New, in that the CLR
> created
> it if you didn't.

In addition to what's already been written, I think it's important to
emphasize that the Finalize method isn't really a destructor, or otherwise
a method to balance the constructor ("Sub New").

It exists to ensure that an object gets a chance to clean up unmanaged
resources if the user of the class forgets to do so, but it's not required
the way a constructor is, and there's no practical way for the compiler to
automatically create a Finalize method that would do anything useful.

Pete

Mike
Mon Mar 17 16:28:02 CDT 2008

Peter, I have a question...
When you say "there's no practical way for the compiler to automatically
create a Finalize method that would do anything useful"...

Is this statement true because at runtime there's really no way for the CLR
to know 'what' unmanaged resources would have to be cleaned-up?

I just want to make sure I'm understanding all this stuff.

Thank you.


"Peter Duniho" wrote:

>
> In addition to what's already been written, I think it's important to
> emphasize that the Finalize method isn't really a destructor, or otherwise
> a method to balance the constructor ("Sub New").
>
> It exists to ensure that an object gets a chance to clean up unmanaged
> resources if the user of the class forgets to do so, but it's not required
> the way a constructor is, and there's no practical way for the compiler to
> automatically create a Finalize method that would do anything useful.
>
> Pete
>

Peter
Mon Mar 17 17:25:58 CDT 2008

On Mon, 17 Mar 2008 14:28:02 -0700, Mike <Mike@discussions.microsoft.com>
wrote:

> Peter, I have a question...
> When you say "there's no practical way for the compiler to automatically
> create a Finalize method that would do anything useful"...
>
> Is this statement true because at runtime there's really no way for the
> CLR
> to know 'what' unmanaged resources would have to be cleaned-up?

Sort of. I mean, I was speaking of the compiler, but yes...the same issue
applies to the run-time as well. By definition, unmanaged resources are
unknown to the run-time. But not only can't the CLR know which resources
would have to be cleaned up, it also doesn't have any way to know in a
reliable way how to clean them up. For a subset of all unmanaged
resources there are assumptions the CLR could make about how to clean them
up, but they wouldn't necessarily be correct in all situations, and for
some unmanaged objects the CLR just wouldn't know how at all.

Really, I think my statement didn't go far enough. It would theoretically
be possible to imbue the compiler and/or run-time with knowledge about
unmanaged objects and how to dispose them, at least for a broad class of
unmanaged objects. But because the unmanaged objects don't themselves
have a well-defined model for declaring when they are no longer in use,
there's no reliable way for the compiler or run-time to know whether it's
actually safe to dispose them or not.

Basically, for unmanaged objects, the lifetime is determined by the order
of execution of code, which isn't something that the run-time can inspect
in any practical fashion (and the compiler definitely can't, since it
doesn't even have access to all of the code that might execute). Managed
objects can be properly handled because their lifetime is entirely
determined by a present state that is (relatively) easily inspected: is
the object reachable or not? This has nothing to do with what code might
execute in the future, it only has to do with what the data looks like
now. But you can't do that with unmanaged objects.

So, any finalizer has to be written explicitly by the programmer, using
that programmer's knowledge of how the unmanaged object is going to be
used and the right way to clean it up, assuming it needs cleaning up at
all.

Pete

Mike
Mon Mar 17 21:20:03 CDT 2008

Thank you for that helpful info! And thanks to everyone else who has posted
as well!
Mike

"Peter Duniho" wrote:

> On Mon, 17 Mar 2008 14:28:02 -0700, Mike <Mike@discussions.microsoft.com>
> wrote:
>
> > Peter, I have a question...
> > When you say "there's no practical way for the compiler to automatically
> > create a Finalize method that would do anything useful"...
> >
> > Is this statement true because at runtime there's really no way for the
> > CLR
> > to know 'what' unmanaged resources would have to be cleaned-up?
>
> Sort of. I mean, I was speaking of the compiler, but yes...the same issue
> applies to the run-time as well. By definition, unmanaged resources are
> unknown to the run-time. But not only can't the CLR know which resources
> would have to be cleaned up, it also doesn't have any way to know in a
> reliable way how to clean them up. For a subset of all unmanaged
> resources there are assumptions the CLR could make about how to clean them
> up, but they wouldn't necessarily be correct in all situations, and for
> some unmanaged objects the CLR just wouldn't know how at all.
>
> Really, I think my statement didn't go far enough. It would theoretically
> be possible to imbue the compiler and/or run-time with knowledge about
> unmanaged objects and how to dispose them, at least for a broad class of
> unmanaged objects. But because the unmanaged objects don't themselves
> have a well-defined model for declaring when they are no longer in use,
> there's no reliable way for the compiler or run-time to know whether it's
> actually safe to dispose them or not.
>
> Basically, for unmanaged objects, the lifetime is determined by the order
> of execution of code, which isn't something that the run-time can inspect
> in any practical fashion (and the compiler definitely can't, since it
> doesn't even have access to all of the code that might execute). Managed
> objects can be properly handled because their lifetime is entirely
> determined by a present state that is (relatively) easily inspected: is
> the object reachable or not? This has nothing to do with what code might
> execute in the future, it only has to do with what the data looks like
> now. But you can't do that with unmanaged objects.
>
> So, any finalizer has to be written explicitly by the programmer, using
> that programmer's knowledge of how the unmanaged object is going to be
> used and the right way to clean it up, assuming it needs cleaning up at
> all.
>
> Pete
>