Suppress finalize in dataset constructor???

[Alvin Bruney [ASP.NET MVP]]

Does any body know or have a clue why the constructor of DataSet needs
GC.SuppressFinalize(this) call

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Miha Markic [MVP C#]]

Hi Alvin,

That's because DataSet is derived from MarshalByValueComponent and this
class implements Finalize method (which does nothing - it calls dispose, but
its derived classes my need it).
Since DataSet doesn't need a finalizer because it doesn't hold any unmanaged
resources it doesn't need a finalization (which would occur since it
implements finalizer) it simply calls SuppressFinalize and so it is taken
off the finalization queue.

 

[Sahil Malik]

Alvin,

This is really a question for the folks who architected the dataset but here
are my thoughts -

You *should* *must* dispose DataSets. Why? Because if you don't Dispose the
dataset, then when the Garbage Collector runs and the DataSet is
unreachable, instead of freeing the memory the DataSet is using the
Collector will add the DataSet to the FReachable queue and promote it to a
higher generation. And a dataset might occupy considerable memory.

So why supress a finalizer?
Because it doesn't do anything in Datasets. (Or anything that inherits from
MarshalByValueComponent). Finalize in that class simply calls
dispose(false) --- completely useless, so might as well supress it.

Why such an implementation?
Because Disposing a dataset, should not dispose underlying datatables (hey
someone else might be using them). This logic is controlled inside the
dispose(true) stuff.

So what happens when you forget to call Dispose on a dataset?
Well I guess it sticks around in memory until the GC gets to it. Given that
it is a complex object, the entire object tree must be clean - and that
might take a while, so go ahead and dispose datasets/datatables/data*.*
whenever ur done using them.

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

 

[Miha Markic [MVP C#]]

Sahil,

I don't think you are right here.
Dispose is primarly meant to free unmanaged resources and doesn't do much on
managed resources.
It normally doesn't matter whether you call or don't call Dispose on a
instance that doesn't use unamanged resources - from the GC point of view.
However, since DataSet implementes (or better inherits) IDisposable and you
never know of future changes it is better to call it.
But for now, one really doesn't need to call Dispose on DataSet (note that
you actually should call it since it might act differently in a future
upgrade).

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

Alvin,

This is really a question for the folks who architected the dataset but
here are my thoughts -

You *should* *must* dispose DataSets. Why? Because if you don't Dispose
the dataset, then when the Garbage Collector runs and the DataSet is
unreachable, instead of freeing the memory the DataSet is using the
Collector will add the DataSet to the FReachable queue and promote it to a
higher generation. And a dataset might occupy considerable memory.

So why supress a finalizer?
Because it doesn't do anything in Datasets. (Or anything that inherits
from MarshalByValueComponent). Finalize in that class simply calls
dispose(false) --- completely useless, so might as well supress it.

Why such an implementation?
Because Disposing a dataset, should not dispose underlying datatables (hey
someone else might be using them). This logic is controlled inside the
dispose(true) stuff.

So what happens when you forget to call Dispose on a dataset?
Well I guess it sticks around in memory until the GC gets to it. Given
that it is a complex object, the entire object tree must be clean - and
that might take a while, so go ahead and dispose
datasets/datatables/data*.* whenever ur done using them.

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

Does any body know or have a clue why the constructor of DataSet needs
GC.SuppressFinalize(this) call

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Cor Ligthert]

Miha,

I don't think you are right here,

When this would be true in a program language from Microsoft than they would
be a very unstable vendor. That is not my expirience.

(note that you actually should call it since it might act differently in a
future upgrade).

This I have as well readed in some text from some blogs, newsgroup messages
ect.

I nowhere saw this text in an official way, while that should than have been
in fat letters from the first day VB2002 was released on MSDN on the first
page of the documentation and even protected by the IDE's.

A program tool maker cannot change the outcomming from that tool, or he
should deliver as Microsoft did with VB6 a migration tool with that.

About the rest we agree of course.



Cor

 

[Sahil Malik]

Miha,

What prevents me from releasing managed resources in dispose() ?
And really what is managed .. is a SqlConnection object managed?

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

Sahil,

I don't think you are right here.
Dispose is primarly meant to free unmanaged resources and doesn't do much
on managed resources.
It normally doesn't matter whether you call or don't call Dispose on a
instance that doesn't use unamanged resources - from the GC point of view.
However, since DataSet implementes (or better inherits) IDisposable and
you never know of future changes it is better to call it.
But for now, one really doesn't need to call Dispose on DataSet (note that
you actually should call it since it might act differently in a future
upgrade).

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

Alvin,

This is really a question for the folks who architected the dataset but
here are my thoughts -

You *should* *must* dispose DataSets. Why? Because if you don't Dispose
the dataset, then when the Garbage Collector runs and the DataSet is
unreachable, instead of freeing the memory the DataSet is using the
Collector will add the DataSet to the FReachable queue and promote it to
a higher generation. And a dataset might occupy considerable memory.

So why supress a finalizer?
Because it doesn't do anything in Datasets. (Or anything that inherits
from MarshalByValueComponent). Finalize in that class simply calls
dispose(false) --- completely useless, so might as well supress it.

Why such an implementation?
Because Disposing a dataset, should not dispose underlying datatables
(hey someone else might be using them). This logic is controlled inside
the dispose(true) stuff.

So what happens when you forget to call Dispose on a dataset?
Well I guess it sticks around in memory until the GC gets to it. Given
that it is a complex object, the entire object tree must be clean - and
that might take a while, so go ahead and dispose
datasets/datatables/data*.* whenever ur done using them.

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

Does any body know or have a clue why the constructor of DataSet needs
GC.SuppressFinalize(this) call

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Miha Markic [MVP C#]]

Hi Sahil,

Miha,

What prevents me from releasing managed resources in dispose() ?

Nothing actually. But why would they (you mean references held by dataset?)
be released (you mean setting references to null/nothing?) in Dispose?
It is enough if you set variable with reference to dataset to null/nothing
and everything will go away - no sooner or later then if you explicitly
release them (any reference that dataset holds) in dispose.

And really what is managed .. is a SqlConnection object managed?

Yes, it is managed but it holds unmanaged resources thus should it be
treated as an unmanaged resource in this context.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

Sahil,

I don't think you are right here.
Dispose is primarly meant to free unmanaged resources and doesn't do much
on managed resources.
It normally doesn't matter whether you call or don't call Dispose on a
instance that doesn't use unamanged resources - from the GC point of
view.
However, since DataSet implementes (or better inherits) IDisposable and
you never know of future changes it is better to call it.
But for now, one really doesn't need to call Dispose on DataSet (note
that you actually should call it since it might act differently in a
future upgrade).

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

Alvin,

This is really a question for the folks who architected the dataset but
here are my thoughts -

You *should* *must* dispose DataSets. Why? Because if you don't Dispose
the dataset, then when the Garbage Collector runs and the DataSet is
unreachable, instead of freeing the memory the DataSet is using the
Collector will add the DataSet to the FReachable queue and promote it to
a higher generation. And a dataset might occupy considerable memory.

So why supress a finalizer?
Because it doesn't do anything in Datasets. (Or anything that inherits
from MarshalByValueComponent). Finalize in that class simply calls
dispose(false) --- completely useless, so might as well supress it.

Why such an implementation?
Because Disposing a dataset, should not dispose underlying datatables
(hey someone else might be using them). This logic is controlled inside
the dispose(true) stuff.

So what happens when you forget to call Dispose on a dataset?
Well I guess it sticks around in memory until the GC gets to it. Given
that it is a complex object, the entire object tree must be clean - and
that might take a while, so go ahead and dispose
datasets/datatables/data*.* whenever ur done using them.

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/




"Alvin Bruney [ASP.NET MVP]" <www.lulu.com/owc> wrote in message
Does any body know or have a clue why the constructor of DataSet needs
GC.SuppressFinalize(this) call

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Miha Markic [MVP C#]]

Miha,

I don't think you are right here,

When this would be true in a program language from Microsoft than they
would be a very unstable vendor. That is not my expirience.


This I have as well readed in some text from some blogs, newsgroup
messages ect.

I nowhere saw this text in an official way, while that should than have
been in fat letters from the first day VB2002 was released on MSDN on the
first page of the documentation and even protected by the IDE's.

A program tool maker cannot change the outcomming from that tool, or he
should deliver as Microsoft did with VB6 a migration tool with that.

Cor,

MS recommendes to call Dispose when class implements it. Simple as that.
Nowhere is stated that you don't need to call Dispose on DataSet.

 

[Sahil Malik]

You are right .. even managed resources can be set to "Nothing". Truly this
isn't much better than their falling out of scope - with one exception. By
calling Dispose, they will be collected, by falling out of scope, they will
be promoted by a generation by GC before being collected.

So even on managed resources, setting stuff = nothing/null has some
advantage, and thus should be done in Dispose for large objects - such as a
dataset (Even though dataset.dispose won't call dispose in datatable .. hmm
!!).

I could be wrong, but these are just my feelings. Either way, hopefully
someone else will express their views on the topic.

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

Hi Sahil,

Miha,

What prevents me from releasing managed resources in dispose() ?

Nothing actually. But why would they (you mean references held by
dataset?) be released (you mean setting references to null/nothing?) in
Dispose?
It is enough if you set variable with reference to dataset to null/nothing
and everything will go away - no sooner or later then if you explicitly
release them (any reference that dataset holds) in dispose.

And really what is managed .. is a SqlConnection object managed?

Yes, it is managed but it holds unmanaged resources thus should it be
treated as an unmanaged resource in this context.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

Sahil,

I don't think you are right here.
Dispose is primarly meant to free unmanaged resources and doesn't do
much on managed resources.
It normally doesn't matter whether you call or don't call Dispose on a
instance that doesn't use unamanged resources - from the GC point of
view.
However, since DataSet implementes (or better inherits) IDisposable and
you never know of future changes it is better to call it.
But for now, one really doesn't need to call Dispose on DataSet (note
that you actually should call it since it might act differently in a
future upgrade).

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

Alvin,

This is really a question for the folks who architected the dataset but
here are my thoughts -

You *should* *must* dispose DataSets. Why? Because if you don't Dispose
the dataset, then when the Garbage Collector runs and the DataSet is
unreachable, instead of freeing the memory the DataSet is using the
Collector will add the DataSet to the FReachable queue and promote it
to a higher generation. And a dataset might occupy considerable memory.

So why supress a finalizer?
Because it doesn't do anything in Datasets. (Or anything that inherits
from MarshalByValueComponent). Finalize in that class simply calls
dispose(false) --- completely useless, so might as well supress it.

Why such an implementation?
Because Disposing a dataset, should not dispose underlying datatables
(hey someone else might be using them). This logic is controlled inside
the dispose(true) stuff.

So what happens when you forget to call Dispose on a dataset?
Well I guess it sticks around in memory until the GC gets to it. Given
that it is a complex object, the entire object tree must be clean - and
that might take a while, so go ahead and dispose
datasets/datatables/data*.* whenever ur done using them.

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/




"Alvin Bruney [ASP.NET MVP]" <www.lulu.com/owc> wrote in message
Does any body know or have a clue why the constructor of DataSet needs
GC.SuppressFinalize(this) call

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Miha Markic [MVP C#]]

You are right .. even managed resources can be set to "Nothing". Truly
this isn't much better than their falling out of scope - with one
exception. By calling Dispose, they will be collected, by falling out of
scope, they will be promoted by a generation by GC before being collected.

No, no. Dispose won't do a thing to managed resources. At best it might set
to nothing references it holds - nothing else.
You can't control collection of managed resources (you can force garbage
collecton that will collect all collectable resources though).
When there are no *live* references on the instance it is marked for
collection - it doesn't matter whether this happens through dispose or by
falling out of scope.

So even on managed resources, setting stuff = nothing/null has some
advantage, and thus should be done in Dispose for large objects - such as
a dataset (Even though dataset.dispose won't call dispose in datatable ..
hmm !!).

Ok, let's have an example here. You have a dataset with several tables and
you hold a reference to the dataset but not to any instance dataset holds.
When you release the reference to dataset there will be no more live
references to dataset nor to instances dataset holds. Thus all object graph
will be marked as collectable and will be collected when GC runs.
It wouldn't make a difference if DataSet.Dispose releases references to
DataTables it holds..

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

I could be wrong, but these are just my feelings. Either way, hopefully
someone else will express their views on the topic.

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

Hi Sahil,

Miha,

What prevents me from releasing managed resources in dispose() ?

Nothing actually. But why would they (you mean references held by
dataset?) be released (you mean setting references to null/nothing?) in
Dispose?
It is enough if you set variable with reference to dataset to
null/nothing and everything will go away - no sooner or later then if you
explicitly release them (any reference that dataset holds) in dispose.

And really what is managed .. is a SqlConnection object managed?

Yes, it is managed but it holds unmanaged resources thus should it be
treated as an unmanaged resource in this context.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/


"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
Sahil,

I don't think you are right here.
Dispose is primarly meant to free unmanaged resources and doesn't do
much on managed resources.
It normally doesn't matter whether you call or don't call Dispose on a
instance that doesn't use unamanged resources - from the GC point of
view.
However, since DataSet implementes (or better inherits) IDisposable and
you never know of future changes it is better to call it.
But for now, one really doesn't need to call Dispose on DataSet (note
that you actually should call it since it might act differently in a
future upgrade).

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

Alvin,

This is really a question for the folks who architected the dataset
but here are my thoughts -

You *should* *must* dispose DataSets. Why? Because if you don't
Dispose the dataset, then when the Garbage Collector runs and the
DataSet is unreachable, instead of freeing the memory the DataSet is
using the Collector will add the DataSet to the FReachable queue and
promote it to a higher generation. And a dataset might occupy
considerable memory.

So why supress a finalizer?
Because it doesn't do anything in Datasets. (Or anything that inherits
from MarshalByValueComponent). Finalize in that class simply calls
dispose(false) --- completely useless, so might as well supress it.

Why such an implementation?
Because Disposing a dataset, should not dispose underlying datatables
(hey someone else might be using them). This logic is controlled
inside the dispose(true) stuff.

So what happens when you forget to call Dispose on a dataset?
Well I guess it sticks around in memory until the GC gets to it. Given
that it is a complex object, the entire object tree must be clean -
and that might take a while, so go ahead and dispose
datasets/datatables/data*.* whenever ur done using them.

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/




"Alvin Bruney [ASP.NET MVP]" <www.lulu.com/owc> wrote in message
Does any body know or have a clue why the constructor of DataSet
needs GC.SuppressFinalize(this) call

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Sahil Malik]

Miha, if I were to write a class, and if I put managed resource cleanup in
Dispose, wouldn't that clean up managed resources if someone called a
dispose on my class?
Anyway, it is impossible for us to clearly determine what exactly does
Dataset.dispose really do .. (cause we can't see the source code), so I
guess this is a softie question.

But one thing I would still insist on is "If you see a dispose, call it !!".
And datasets do have dispose.

But I do have a question here I'd your views on.

"If a dataset falls out of scope, what will eventually get called on it,
"Finalize" or "Dispose" ? "

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

You are right .. even managed resources can be set to "Nothing". Truly
this isn't much better than their falling out of scope - with one
exception. By calling Dispose, they will be collected, by falling out of
scope, they will be promoted by a generation by GC before being

collected.

No, no. Dispose won't do a thing to managed resources. At best it might set
to nothing references it holds - nothing else.
You can't control collection of managed resources (you can force garbage
collecton that will collect all collectable resources though).
When there are no *live* references on the instance it is marked for
collection - it doesn't matter whether this happens through dispose or by
falling out of scope.

So even on managed resources, setting stuff = nothing/null has some
advantage, and thus should be done in Dispose for large objects - such as
a dataset (Even though dataset.dispose won't call dispose in datatable ...
hmm !!).

Ok, let's have an example here. You have a dataset with several tables and
you hold a reference to the dataset but not to any instance dataset holds.
When you release the reference to dataset there will be no more live
references to dataset nor to instances dataset holds. Thus all object graph
will be marked as collectable and will be collected when GC runs.
It wouldn't make a difference if DataSet.Dispose releases references to
DataTables it holds..

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

I could be wrong, but these are just my feelings. Either way, hopefully
someone else will express their views on the topic.

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

Hi Sahil,

Miha,

What prevents me from releasing managed resources in dispose() ?

Nothing actually. But why would they (you mean references held by
dataset?) be released (you mean setting references to null/nothing?) in
Dispose?
It is enough if you set variable with reference to dataset to
null/nothing and everything will go away - no sooner or later then if you
explicitly release them (any reference that dataset holds) in dispose.

And really what is managed .. is a SqlConnection object managed?

Yes, it is managed but it holds unmanaged resources thus should it be
treated as an unmanaged resource in this context.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info


- Sahil Malik
http://codebetter.com/blogs/sahil.malik/


"Miha Markic [MVP C#]" <miha at rthand com> wrote in message
Sahil,

I don't think you are right here.
Dispose is primarly meant to free unmanaged resources and doesn't do
much on managed resources.
It normally doesn't matter whether you call or don't call Dispose on a
instance that doesn't use unamanged resources - from the GC point of
view.
However, since DataSet implementes (or better inherits) IDisposable and
you never know of future changes it is better to call it.
But for now, one really doesn't need to call Dispose on DataSet (note
that you actually should call it since it might act differently in a
future upgrade).

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
www.rthand.com
SLODUG - Slovene Developer Users Group www.codezone-si.info

Alvin,

This is really a question for the folks who architected the dataset
but here are my thoughts -

You *should* *must* dispose DataSets. Why? Because if you don't
Dispose the dataset, then when the Garbage Collector runs and the
DataSet is unreachable, instead of freeing the memory the DataSet is
using the Collector will add the DataSet to the FReachable queue and
promote it to a higher generation. And a dataset might occupy
considerable memory.

So why supress a finalizer?
Because it doesn't do anything in Datasets. (Or anything that inherits
from MarshalByValueComponent). Finalize in that class simply calls
dispose(false) --- completely useless, so might as well supress it.

Why such an implementation?
Because Disposing a dataset, should not dispose underlying datatables
(hey someone else might be using them). This logic is controlled
inside the dispose(true) stuff.

So what happens when you forget to call Dispose on a dataset?
Well I guess it sticks around in memory until the GC gets to it. Given
that it is a complex object, the entire object tree must be clean -
and that might take a while, so go ahead and dispose
datasets/datatables/data*.* whenever ur done using them.

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/




"Alvin Bruney [ASP.NET MVP]" <www.lulu.com/owc> wrote in message
Does any body know or have a clue why the constructor of DataSet
needs GC.SuppressFinalize(this) call

--
Regards,
Alvin Bruney
[Shameless Author Plug]
The Microsoft Office Web Components Black Book with .NET
available at www.lulu.com/owc
_________________________

 

[Chris Lyon [MSFT]]

Sahil and Miha,

There appears to be some confusion about Dispose. Hopefully I can clear it
up a bit.

-Dispose is primarily used to released unmanaged resources, although there
is nothing wrong with releasing managed resources inside Dispose as well
(Dataset is a good example of this).
-If a class implements IDisposable, you *should* call Dispose as soon as
you no longer need the object.

"If a dataset falls out of scope, what will eventually get called on it,

"Finalize" or "Dispose" ? "

Neither. Since DataSet's finalizer is suppressed, it's finalizer will not
be called. Dispose must be called by user code.

You are right .. even managed resources can be set to "Nothing". Truly this
isn't much better than their falling out of scope - with one exception. By

Setting instance fields to null (or Nothing) is valuable if the fields are
large, and you plan on keeping the class instance alive.

calling Dispose, they will be collected, by falling out of scope, they will
be promoted by a generation by GC before being collected.

No, Dispose does not make object be collected any sooner. Dispose is *just
a method*, there's nothing special about it with respect to the GC. It's
the code that's inside Dispose that releases resources.

See also:
http://blogs.msdn.com/clyon/archive/2004/09/21/232445.aspx
http://blogs.msdn.com/clyon/archive/2004/09/23/233464.aspx

Hope that helps!
-Chris

 

[Miha Markic [MVP C#]]

Hi Chris,

Sahil and Miha,

There appears to be some confusion about Dispose. Hopefully I can clear
it
up a bit.

-Dispose is primarily used to released unmanaged resources, although there
is nothing wrong with releasing managed resources inside Dispose as well
(Dataset is a good example of this).

What exactly do you mean by releasing managed resources?
DataSet actually doesn't implement Dispose it just inherits it.

-If a class implements IDisposable, you *should* call Dispose as soon as
you no longer need the object.
True.

"Finalize" or "Dispose" ? "

Neither. Since DataSet's finalizer is suppressed, it's finalizer will not
be called. Dispose must be called by user code.

Yup.

 

[Sahil Malik]

Thanks Chris, this clarifies a lot. Would you agree with this -

"There is a GC.SuppressFinalize on a dataset constructor because, finalize
in a dataset doesn't really do anything."

I agree, call Dispose first, ask questions later !!!

- Sahil Malik
http://codebetter.com/blogs/sahil.malik/

Sahil and Miha,

There appears to be some confusion about Dispose. Hopefully I can clear it
up a bit.

-Dispose is primarily used to released unmanaged resources, although there
is nothing wrong with releasing managed resources inside Dispose as well
(Dataset is a good example of this).
-If a class implements IDisposable, you *should* call Dispose as soon as
you no longer need the object.

"If a dataset falls out of scope, what will eventually get called on it,

"Finalize" or "Dispose" ? "

Neither. Since DataSet's finalizer is suppressed, it's finalizer will not
be called. Dispose must be called by user code.

You are right .. even managed resources can be set to "Nothing". Truly this
isn't much better than their falling out of scope - with one exception.

By

Setting instance fields to null (or Nothing) is valuable if the fields are
large, and you plan on keeping the class instance alive.

calling Dispose, they will be collected, by falling out of scope, they will
be promoted by a generation by GC before being collected.

No, Dispose does not make object be collected any sooner. Dispose is *just
a method*, there's nothing special about it with respect to the GC. It's
the code that's inside Dispose that releases resources.

See also:
http://blogs.msdn.com/clyon/archive/2004/09/21/232445.aspx
http://blogs.msdn.com/clyon/archive/2004/09/23/233464.aspx

Hope that helps!
-Chris

 

[Miha Markic [MVP C#]]

Thanks Chris, this clarifies a lot. Would you agree with this -

"There is a GC.SuppressFinalize on a dataset constructor because, finalize
in a dataset doesn't really do anything."

Sure.

 

[Cor Ligthert]

Miha,

MS recommendes to call Dispose when class implements it. Simple as that.
Nowhere is stated that you don't need to call Dispose on DataSet.

What are in my opinion always messages from individuals, so show me one
where that is said in a non free way with statements as, "it does not hurt
much to call it". Most statements does not hurt much to call. However
referering now a time the always told statement when I tell that boxing does
not hurt much. "When you do it 10000000 times in a loop it will cost time".

What you tells would mean that you should every time use Dispose when you
use one of the classes on the bellow page and even the classes which derives
from those.

http://msdn.microsoft.com/library/d...stemcomponentmodelcomponentclasshierarchy.asp

Therefore every time for a label, textbox, checkbox or whatever.

What would than mean that your program would almost only exist from dispose
statement.

The implementation from IDisposable should do that. (This when dispose is
not overloaded (as connection) or for reasons to get hugh amounts of
memory/resources as bitmaps/pens free) a little bit earlier free.

Just my thought,

Cor

 

[Cor Ligthert]

Chris,

-If a class implements IDisposable, you *should* call Dispose as soon as
you no longer need the object.

This means for every label or whatever?

Amost every class implements IDisposable. I had always thought, that that
was disposing using the components (and have to insert in this the unmanaged
resources when those are used).
\\\
Protected override void Dispose( bool disposing )
{
if( disposing )
{
if (components != null)
{
components.Dispose();
}
}
base.Dispose( disposing );
}
///

Maybe can you clearify this for me?

Cor

 

[Miha Markic [MVP C#]]

Miha,

What are in my opinion always messages from individuals, so show me one
where that is said in a non free way with statements as, "it does not hurt
much to call it". Most statements does not hurt much to call. However
referering now a time the always told statement when I tell that boxing
does not hurt much. "When you do it 10000000 times in a loop it will cost
time".

Yes. However, disposing is a required action while boxing/unboxing can be
avoided.

What you tells would mean that you should every time use Dispose when you
use one of the classes on the bellow page and even the classes which
derives from those.
Sure.


http://msdn.microsoft.com/library/d...stemcomponentmodelcomponentclasshierarchy.asp

Therefore every time for a label, textbox, checkbox or whatever.
Sure.


What would than mean that your program would almost only exist from
dispose statement.

I really don't think you create and destroy IDisposable classes all the
time, do you?

No.
So, for example, what exactly do you think is going on in Form.Dispose
method, more precisely, in components.Dispose() line?

The implementation from IDisposable should do that. (This when dispose is
not overloaded (as connection) or for reasons to get hugh amounts of
memory/resources as bitmaps/pens free) a little bit earlier free.

Can you clarify this statement - it is not entirely clear to me.

 

[Miha Markic [MVP C#]]

Cor,

What do you think components.Dispose does?
It loops through all components it has and it disposes them plus few minor
things.

 

[Cor Ligthert]

Miha,

I really don't think you create and destroy IDisposable classes all the
time, do you?

See the link therefore I showed it, almost every Net class derives from
component and that means that every class you create from that has a dispose
method. Which accoording to that crazy statement it does not hurts should be
disposed. (That kind of statements in documentation stops me direct with
reading. It shows for me that the author for not sure about what he is
writing)

No.
So, for example, what exactly do you think is going on in Form.Dispose
method, more precisely, in components.Dispose() line?

That is exactly what I mean and therefore there is in my opinion no need to
call it yourself or there should be a time aspect.

Can you clarify this statement - it is not entirely clear to me.

That is what I mean with what you told me about the form dispose method,
which should be in every Idisposable class however is that in every RAD
usable class.

When it was not, than every RAD created programs would be garbage. You see
not in any RAD created program an individual dispose line.


Cor