By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,191 Members | 1,720 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,191 IT Pros & Developers. It's quick & easy.

A (not so) basic question.

P: n/a
The following issue is puzzling me:

There are 2 ways of writing the code below:
....
Dim fnt as Font = New Font(...)
DrawString(myText, fnt,...)
fnt.dispose().

or
DrawString(myText, New Font(...),...)

The difference between both is that in the second case, there is no way to
explicitely dispose of the object (in the example, a Font object, but that
is purely circumstantial). The basic issue is:

If an object is substantiated while passed a a parameter (as above), is it
inherently disposed by the called procedure (here: drawstring) or isn't it
at all?

The reason for this question is that I favor using the second way of coding,
because it much less verbose, but I am not sure about the consequences.

Can anybody shed some light on that? Thanks in advance.
May 28 '06 #1
Share this Question
Share on Google+
21 Replies


P: n/a
Hi Roland,
I am not the expert here, and am just learning .Net ways myself but I
think I can answer your question.
1) It is not normally necessary to call the dispose method for an object ( a
lot of objects don't even implement it). If the object does implement a
Dispose method (because it uses 'unmanaged' resources), then Dispose will be
called from the objects 'Finalize' method, which will be invoked at the time
the object is 'Garbage Collected'.
2) So, in your second way (instanciate the Font object inside the call to
DrawString, the object will go out of scope when the call returns and will be
GC'ed sometime later, at which time the Dispose method will be invoked. In
your first way, the Font object will still be GC'ed sometime later (after it
goes out of scope), but its Dispose method is called 'early' (it is up to it
to keep track that it has been 'Disposed' and not let it happen again when it
is GC'ed).
3) To put it another way, the Dispose method is only there to allow an
object to 'clean up' 'unmanaged resources' in advance of it being GC'ed. Of
course, depending on what resource we are talking about, that could be
important.
4) Your example implies that you are only calling DrawString only once, in
which case the second method should be fine. But if yo are going to call it
multiple times, why create a new font object each time? And if you are going
to call the routine a lot of times, then maybe 'fnt' should be static.
Hope this helped.
--
Terry
"Roland" wrote:
The following issue is puzzling me:

There are 2 ways of writing the code below:
....
Dim fnt as Font = New Font(...)
DrawString(myText, fnt,...)
fnt.dispose().

or
DrawString(myText, New Font(...),...)

The difference between both is that in the second case, there is no way to
explicitely dispose of the object (in the example, a Font object, but that
is purely circumstantial). The basic issue is:

If an object is substantiated while passed a a parameter (as above), is it
inherently disposed by the called procedure (here: drawstring) or isn't it
at all?

The reason for this question is that I favor using the second way of coding,
because it much less verbose, but I am not sure about the consequences.

Can anybody shed some light on that? Thanks in advance.

May 28 '06 #2

P: n/a
Terry, thanks for replying.
1) I understand from the IDisposable.Dispose method description that you
have to call the metod explicitly and not leave it at the discretion of the
GC.
It is true that the GC eventually will finalize the objects that are out of
scope and hence will call their dispose method if they implement the
Idisposable interface, but that may only happen minutes later.
It may even not happen at all until the program exits, depending on the
volume of garbage to collect. Basically, you are in the same situation as
when you are writing an unmanaged program, where you make all allocations
(handles,etc..) "along the way" and only releasing them at the end of the
program. And that 's worrying me: everybody will tell you that this is bad
programming.
I still have the feeling that, although the second way is tempting, it is
not the right way...
....
4) Of course, I agree that if you call a method repeatedly, you shouldn't
create an object in the paremeter list, but outside the loop.

"Terry" <Te***@nospam.nospam> wrote in message
news:FB**********************************@microsof t.com...
Hi Roland,
I am not the expert here, and am just learning .Net ways myself but I
think I can answer your question.
1) It is not normally necessary to call the dispose method for an object
( a
lot of objects don't even implement it). If the object does implement a
Dispose method (because it uses 'unmanaged' resources), then Dispose will
be
called from the objects 'Finalize' method, which will be invoked at the
time
the object is 'Garbage Collected'.
2) So, in your second way (instanciate the Font object inside the call to
DrawString, the object will go out of scope when the call returns and will
be
GC'ed sometime later, at which time the Dispose method will be invoked.
In
your first way, the Font object will still be GC'ed sometime later (after
it
goes out of scope), but its Dispose method is called 'early' (it is up to
it
to keep track that it has been 'Disposed' and not let it happen again when
it
is GC'ed).
3) To put it another way, the Dispose method is only there to allow an
object to 'clean up' 'unmanaged resources' in advance of it being GC'ed.
Of
course, depending on what resource we are talking about, that could be
important.
4) Your example implies that you are only calling DrawString only once, in
which case the second method should be fine. But if yo are going to call
it
multiple times, why create a new font object each time? And if you are
going
to call the routine a lot of times, then maybe 'fnt' should be static.
Hope this helped.
--
Terry
"Roland" wrote:
The following issue is puzzling me:

There are 2 ways of writing the code below:
....
Dim fnt as Font = New Font(...)
DrawString(myText, fnt,...)
fnt.dispose().

or
DrawString(myText, New Font(...),...)

The difference between both is that in the second case, there is no way
to
explicitely dispose of the object (in the example, a Font object, but
that
is purely circumstantial). The basic issue is:

If an object is substantiated while passed a a parameter (as above), is
it
inherently disposed by the called procedure (here: drawstring) or isn't
it
at all?

The reason for this question is that I favor using the second way of
coding,
because it much less verbose, but I am not sure about the consequences.

Can anybody shed some light on that? Thanks in advance.

May 29 '06 #3

P: n/a
Roland,

Who, are those *everybody* you talking about, surely not that bunch of
dotNet developers.

Maybe those who use obscure languages which don't help them to manage the
memory.

We are not anymore in the time of the 64Kb computers, mostly there is memory
enough and if it is not, buy it, it is cheap enough comparing to the cost of
a developer an hour.

Cor

"Roland" <ro**************@skynet.be> schreef in bericht
news:eR**************@TK2MSFTNGP02.phx.gbl...
Terry, thanks for replying.
1) I understand from the IDisposable.Dispose method description that you
have to call the metod explicitly and not leave it at the discretion of
the GC.
It is true that the GC eventually will finalize the objects that are out
of scope and hence will call their dispose method if they implement the
Idisposable interface, but that may only happen minutes later.
It may even not happen at all until the program exits, depending on the
volume of garbage to collect. Basically, you are in the same situation as
when you are writing an unmanaged program, where you make all allocations
(handles,etc..) "along the way" and only releasing them at the end of the
program. And that 's worrying me: everybody will tell you that this is bad
programming.
I still have the feeling that, although the second way is tempting, it is
not the right way...
...
4) Of course, I agree that if you call a method repeatedly, you shouldn't
create an object in the paremeter list, but outside the loop.

"Terry" <Te***@nospam.nospam> wrote in message
news:FB**********************************@microsof t.com...
Hi Roland,
I am not the expert here, and am just learning .Net ways myself but I
think I can answer your question.
1) It is not normally necessary to call the dispose method for an object
( a
lot of objects don't even implement it). If the object does implement a
Dispose method (because it uses 'unmanaged' resources), then Dispose will
be
called from the objects 'Finalize' method, which will be invoked at the
time
the object is 'Garbage Collected'.
2) So, in your second way (instanciate the Font object inside the call to
DrawString, the object will go out of scope when the call returns and
will be
GC'ed sometime later, at which time the Dispose method will be invoked.
In
your first way, the Font object will still be GC'ed sometime later (after
it
goes out of scope), but its Dispose method is called 'early' (it is up to
it
to keep track that it has been 'Disposed' and not let it happen again
when it
is GC'ed).
3) To put it another way, the Dispose method is only there to allow an
object to 'clean up' 'unmanaged resources' in advance of it being GC'ed.
Of
course, depending on what resource we are talking about, that could be
important.
4) Your example implies that you are only calling DrawString only once,
in
which case the second method should be fine. But if yo are going to call
it
multiple times, why create a new font object each time? And if you are
going
to call the routine a lot of times, then maybe 'fnt' should be static.
Hope this helped.
--
Terry
"Roland" wrote:
The following issue is puzzling me:

There are 2 ways of writing the code below:
....
Dim fnt as Font = New Font(...)
DrawString(myText, fnt,...)
fnt.dispose().

or
DrawString(myText, New Font(...),...)

The difference between both is that in the second case, there is no way
to
explicitely dispose of the object (in the example, a Font object, but
that
is purely circumstantial). The basic issue is:

If an object is substantiated while passed a a parameter (as above), is
it
inherently disposed by the called procedure (here: drawstring) or isn't
it
at all?

The reason for this question is that I favor using the second way of
coding,
because it much less verbose, but I am not sure about the consequences.

Can anybody shed some light on that? Thanks in advance.


May 29 '06 #4

P: n/a
Hi Roland,
You are correct, you never know for sure when the GC will get around to
the object. I guess the point I was trying to make was in reference to the
following line in your original post:
"there is no way to explicitely dispose of the object (in the example, a
Font object)"
Calling Dispose, does not 'Dispose of the Font object', it allows the font
object to release unmanaged resources. The Font object still needs to be
GC'ed.
And yes, this 'non-deterministic finialization' seems a bit strange, but
I guess we will just need to get use to it.
--
Terry
"Roland" wrote:
Terry, thanks for replying.
1) I understand from the IDisposable.Dispose method description that you
have to call the metod explicitly and not leave it at the discretion of the
GC.
It is true that the GC eventually will finalize the objects that are out of
scope and hence will call their dispose method if they implement the
Idisposable interface, but that may only happen minutes later.
It may even not happen at all until the program exits, depending on the
volume of garbage to collect. Basically, you are in the same situation as
when you are writing an unmanaged program, where you make all allocations
(handles,etc..) "along the way" and only releasing them at the end of the
program. And that 's worrying me: everybody will tell you that this is bad
programming.
I still have the feeling that, although the second way is tempting, it is
not the right way...
....
4) Of course, I agree that if you call a method repeatedly, you shouldn't
create an object in the paremeter list, but outside the loop.

"Terry" <Te***@nospam.nospam> wrote in message
news:FB**********************************@microsof t.com...
Hi Roland,
I am not the expert here, and am just learning .Net ways myself but I
think I can answer your question.
1) It is not normally necessary to call the dispose method for an object
( a
lot of objects don't even implement it). If the object does implement a
Dispose method (because it uses 'unmanaged' resources), then Dispose will
be
called from the objects 'Finalize' method, which will be invoked at the
time
the object is 'Garbage Collected'.
2) So, in your second way (instanciate the Font object inside the call to
DrawString, the object will go out of scope when the call returns and will
be
GC'ed sometime later, at which time the Dispose method will be invoked.
In
your first way, the Font object will still be GC'ed sometime later (after
it
goes out of scope), but its Dispose method is called 'early' (it is up to
it
to keep track that it has been 'Disposed' and not let it happen again when
it
is GC'ed).
3) To put it another way, the Dispose method is only there to allow an
object to 'clean up' 'unmanaged resources' in advance of it being GC'ed.
Of
course, depending on what resource we are talking about, that could be
important.
4) Your example implies that you are only calling DrawString only once, in
which case the second method should be fine. But if yo are going to call
it
multiple times, why create a new font object each time? And if you are
going
to call the routine a lot of times, then maybe 'fnt' should be static.
Hope this helped.
--
Terry
"Roland" wrote:
The following issue is puzzling me:

There are 2 ways of writing the code below:
....
Dim fnt as Font = New Font(...)
DrawString(myText, fnt,...)
fnt.dispose().

or
DrawString(myText, New Font(...),...)

The difference between both is that in the second case, there is no way
to
explicitely dispose of the object (in the example, a Font object, but
that
is purely circumstantial). The basic issue is:

If an object is substantiated while passed a a parameter (as above), is
it
inherently disposed by the called procedure (here: drawstring) or isn't
it
at all?

The reason for this question is that I favor using the second way of
coding,
because it much less verbose, but I am not sure about the consequences.

Can anybody shed some light on that? Thanks in advance.


May 29 '06 #5

P: n/a
Roland,
In addition to the other comments: I would use a variation of your first
method:

..NET 1.x
Dim fnt as Font = New Font(...)
Try
DrawString(myText, fnt,...)
Finally
' assuming fnt is not nothing
fnt.dispose().
End Try
..NET 2.0
Using fnt as Font = New Font(...)
DrawString(myText, fnt,...)
End Using

As this ensure that any unmanaged resources that Font may be exposing (as
evidenced by the fact that Font implements IDisposable) are released in a
timely manner. As you have pointed out. The GC may take minutes or longer to
release the resource, this may cause undue pressure on both the GC & Win32.
The GC as it is tracking a number of Finalizable objects, Win32 as you are
using Handles longer then necessary.
When to call Dispose?

* Call Dispose when the type itself implements IDisposable

* Call Dispose when the type or one of its base classes *overrides*
Dispose(Boolean) if the class inherits from System.ComponentModel.Component
or System.ComponentModel.MarshalByValueComponent

* Do not explicitly call Dispose on classes deriving from
System.Windows.Forms.Control for instances placed on a
System.Windows.Forms.Form as Form will implicitly dispose of them when the
form is Disposed

* Call Dispose on System.Windows.Forms.Form objects when Form.ShowDialog is
used.

* Do not explicitly call Dispose on System.Windows.Forms.Form objects if
Form.Show is used as Dispose will be implicitly called when the form is
closed

* Do not explicitly call Dispose on classes deriving from
System.Web.UI.Control as it will be implicitly called as part of the normal
ASP.NET page processing

I consider the second rule controversial as it relies on using ILDASM or
Reflector to find out implementation details of a class. Its meant for
classes such as DataSet, that have an inherited Dispose, but Dispose doesn't
really do anything.

These rules are based on private discussions with other MVPs & discussions
held in the newsgroups earlier in 2005.

These rules apply to objects that you create, explicitly or implicitly.
Objects that you "own".

Disposable Objects that are passed to you as a parameter of a method (such
as the Graphics object on the Paint event) should not have their disposed
method call, as the system calls it as part of the method that raises the
event.

Objects that something else "owns" should normally be disposed of by the
"owning" object.

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Roland" <ro**************@skynet.be> wrote in message
news:e2**************@TK2MSFTNGP04.phx.gbl...
| The following issue is puzzling me:
|
| There are 2 ways of writing the code below:
| ...
| Dim fnt as Font = New Font(...)
| DrawString(myText, fnt,...)
| fnt.dispose().
|
| or
| DrawString(myText, New Font(...),...)
|
| The difference between both is that in the second case, there is no way to
| explicitely dispose of the object (in the example, a Font object, but that
| is purely circumstantial). The basic issue is:
|
| If an object is substantiated while passed a a parameter (as above), is it
| inherently disposed by the called procedure (here: drawstring) or isn't it
| at all?
|
| The reason for this question is that I favor using the second way of
coding,
| because it much less verbose, but I am not sure about the consequences.
|
| Can anybody shed some light on that? Thanks in advance.
|
|
May 29 '06 #6

P: n/a
Jay,

Seeing it after a longer time now, I became confused by this one.
* Call Dispose when the type itself implements IDisposable
As the rest of the text is it in my opinion correct written, however I am
afraid that this one can be read wrong. I think that you are better than me
to have an eye on it, how it can be maybe better. I have nothing else than.

Call Dispose when the type *itself* implements IDisposable

Cor
* Call Dispose when the type or one of its base classes *overrides*
Dispose(Boolean) if the class inherits from
System.ComponentModel.Component
or System.ComponentModel.MarshalByValueComponent

* Do not explicitly call Dispose on classes deriving from
System.Windows.Forms.Control for instances placed on a
System.Windows.Forms.Form as Form will implicitly dispose of them when the
form is Disposed

* Call Dispose on System.Windows.Forms.Form objects when Form.ShowDialog
is
used.

* Do not explicitly call Dispose on System.Windows.Forms.Form objects if
Form.Show is used as Dispose will be implicitly called when the form is
closed

* Do not explicitly call Dispose on classes deriving from
System.Web.UI.Control as it will be implicitly called as part of the
normal
ASP.NET page processing

I consider the second rule controversial as it relies on using ILDASM or
Reflector to find out implementation details of a class. Its meant for
classes such as DataSet, that have an inherited Dispose, but Dispose
doesn't
really do anything.

These rules are based on private discussions with other MVPs & discussions
held in the newsgroups earlier in 2005.

These rules apply to objects that you create, explicitly or implicitly.
Objects that you "own".

Disposable Objects that are passed to you as a parameter of a method (such
as the Graphics object on the Paint event) should not have their disposed
method call, as the system calls it as part of the method that raises the
event.

Objects that something else "owns" should normally be disposed of by the
"owning" object.

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Roland" <ro**************@skynet.be> wrote in message
news:e2**************@TK2MSFTNGP04.phx.gbl...
| The following issue is puzzling me:
|
| There are 2 ways of writing the code below:
| ...
| Dim fnt as Font = New Font(...)
| DrawString(myText, fnt,...)
| fnt.dispose().
|
| or
| DrawString(myText, New Font(...),...)
|
| The difference between both is that in the second case, there is no way
to
| explicitely dispose of the object (in the example, a Font object, but
that
| is purely circumstantial). The basic issue is:
|
| If an object is substantiated while passed a a parameter (as above), is
it
| inherently disposed by the called procedure (here: drawstring) or isn't
it
| at all?
|
| The reason for this question is that I favor using the second way of
coding,
| because it much less verbose, but I am not sure about the consequences.
|
| Can anybody shed some light on that? Thanks in advance.
|
|

May 29 '06 #7

P: n/a
Cor
You may like to believe that in your world you don't have to be concerned
anymore about memory, but your world happens to be built on unmanaged
resources (read: memory).
Indeed a lot of the classes we use in our managed memory environment are
just wrappers around Win32 objects (handles, structures,...). And they have
to comply
to the rules of that world. As an aside: it's not because you have a lot
more room to put your garbage, that you don't have to keep the place tidy
anymore...
When the developers of the framework implemented the IDisposable Interface,
they must have got a very good reason for it, because it is basically in
contradiction with the concept of managed resources.
The reason for it (as I understand it) is that those objects are holding a
reference to the world of unmanaged resources. This implies that they have
to obey the rules of both worlds. The Win32 world is saying: release
unnecessary references as soon as possible, while the other world is saying
"don't worry, I'll clean up sooner or later". Therefor the IDisposable
Interface is making sure that you impose a deterministic finalisation for
those objects in contrast with the *really* managed resources.
After reading the comments of Jay B. Harlow, my conclusion is: when you
create an object that is disposable, do it in such a way that you can
dispose of it. In such a situation, my second approach is not right and I
should stick to the more verbose one.
Roland

"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:OH**************@TK2MSFTNGP05.phx.gbl...
Roland,

Who, are those *everybody* you talking about, surely not that bunch of
dotNet developers.

Maybe those who use obscure languages which don't help them to manage the
memory.

We are not anymore in the time of the 64Kb computers, mostly there is
memory enough and if it is not, buy it, it is cheap enough comparing to
the cost of a developer an hour.

Cor

"Roland" <ro**************@skynet.be> schreef in bericht
news:eR**************@TK2MSFTNGP02.phx.gbl...
Terry, thanks for replying.
1) I understand from the IDisposable.Dispose method description that you
have to call the metod explicitly and not leave it at the discretion of
the GC.
It is true that the GC eventually will finalize the objects that are out
of scope and hence will call their dispose method if they implement the
Idisposable interface, but that may only happen minutes later.
It may even not happen at all until the program exits, depending on the
volume of garbage to collect. Basically, you are in the same situation as
when you are writing an unmanaged program, where you make all allocations
(handles,etc..) "along the way" and only releasing them at the end of the
program. And that 's worrying me: everybody will tell you that this is
bad programming.
I still have the feeling that, although the second way is tempting, it is
not the right way...
...
4) Of course, I agree that if you call a method repeatedly, you shouldn't
create an object in the paremeter list, but outside the loop.

"Terry" <Te***@nospam.nospam> wrote in message
news:FB**********************************@microsof t.com...
Hi Roland,
I am not the expert here, and am just learning .Net ways myself but I
think I can answer your question.
1) It is not normally necessary to call the dispose method for an object
( a
lot of objects don't even implement it). If the object does implement a
Dispose method (because it uses 'unmanaged' resources), then Dispose
will be
called from the objects 'Finalize' method, which will be invoked at the
time
the object is 'Garbage Collected'.
2) So, in your second way (instanciate the Font object inside the call
to
DrawString, the object will go out of scope when the call returns and
will be
GC'ed sometime later, at which time the Dispose method will be invoked.
In
your first way, the Font object will still be GC'ed sometime later
(after it
goes out of scope), but its Dispose method is called 'early' (it is up
to it
to keep track that it has been 'Disposed' and not let it happen again
when it
is GC'ed).
3) To put it another way, the Dispose method is only there to allow an
object to 'clean up' 'unmanaged resources' in advance of it being GC'ed.
Of
course, depending on what resource we are talking about, that could be
important.
4) Your example implies that you are only calling DrawString only once,
in
which case the second method should be fine. But if yo are going to
call it
multiple times, why create a new font object each time? And if you are
going
to call the routine a lot of times, then maybe 'fnt' should be static.
Hope this helped.
--
Terry
"Roland" wrote:

The following issue is puzzling me:

There are 2 ways of writing the code below:
....
Dim fnt as Font = New Font(...)
DrawString(myText, fnt,...)
fnt.dispose().

or
DrawString(myText, New Font(...),...)

The difference between both is that in the second case, there is no way
to
explicitely dispose of the object (in the example, a Font object, but
that
is purely circumstantial). The basic issue is:

If an object is substantiated while passed a a parameter (as above), is
it
inherently disposed by the called procedure (here: drawstring) or isn't
it
at all?

The reason for this question is that I favor using the second way of
coding,
because it much less verbose, but I am not sure about the consequences.

Can anybody shed some light on that? Thanks in advance.



May 31 '06 #8

P: n/a
Thanks Jay, for this clarification.
I will stick to the more verbose way with objects that implement
IDisposable.

"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
message news:en**************@TK2MSFTNGP05.phx.gbl...
Roland,
In addition to the other comments: I would use a variation of your first
method:

.NET 1.x
Dim fnt as Font = New Font(...)
Try
DrawString(myText, fnt,...)
Finally
' assuming fnt is not nothing
fnt.dispose().
End Try
.NET 2.0
Using fnt as Font = New Font(...)
DrawString(myText, fnt,...)
End Using

As this ensure that any unmanaged resources that Font may be exposing (as
evidenced by the fact that Font implements IDisposable) are released in a
timely manner. As you have pointed out. The GC may take minutes or longer
to
release the resource, this may cause undue pressure on both the GC &
Win32.
The GC as it is tracking a number of Finalizable objects, Win32 as you are
using Handles longer then necessary.
When to call Dispose?

* Call Dispose when the type itself implements IDisposable

* Call Dispose when the type or one of its base classes *overrides*
Dispose(Boolean) if the class inherits from
System.ComponentModel.Component
or System.ComponentModel.MarshalByValueComponent

* Do not explicitly call Dispose on classes deriving from
System.Windows.Forms.Control for instances placed on a
System.Windows.Forms.Form as Form will implicitly dispose of them when the
form is Disposed

* Call Dispose on System.Windows.Forms.Form objects when Form.ShowDialog
is
used.

* Do not explicitly call Dispose on System.Windows.Forms.Form objects if
Form.Show is used as Dispose will be implicitly called when the form is
closed

* Do not explicitly call Dispose on classes deriving from
System.Web.UI.Control as it will be implicitly called as part of the
normal
ASP.NET page processing

I consider the second rule controversial as it relies on using ILDASM or
Reflector to find out implementation details of a class. Its meant for
classes such as DataSet, that have an inherited Dispose, but Dispose
doesn't
really do anything.

These rules are based on private discussions with other MVPs & discussions
held in the newsgroups earlier in 2005.

These rules apply to objects that you create, explicitly or implicitly.
Objects that you "own".

Disposable Objects that are passed to you as a parameter of a method (such
as the Graphics object on the Paint event) should not have their disposed
method call, as the system calls it as part of the method that raises the
event.

Objects that something else "owns" should normally be disposed of by the
"owning" object.

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Roland" <ro**************@skynet.be> wrote in message
news:e2**************@TK2MSFTNGP04.phx.gbl...
| The following issue is puzzling me:
|
| There are 2 ways of writing the code below:
| ...
| Dim fnt as Font = New Font(...)
| DrawString(myText, fnt,...)
| fnt.dispose().
|
| or
| DrawString(myText, New Font(...),...)
|
| The difference between both is that in the second case, there is no way
to
| explicitely dispose of the object (in the example, a Font object, but
that
| is purely circumstantial). The basic issue is:
|
| If an object is substantiated while passed a a parameter (as above), is
it
| inherently disposed by the called procedure (here: drawstring) or isn't
it
| at all?
|
| The reason for this question is that I favor using the second way of
coding,
| because it much less verbose, but I am not sure about the consequences.
|
| Can anybody shed some light on that? Thanks in advance.
|
|

May 31 '06 #9

P: n/a
After reading the comments of Jay B. Harlow, my conclusion is: when you
create an object that is disposable, do it in such a way that you can
dispose of it.


But that has Jay no where written. You have read it without the word
*itself* implement Idisposable.

20% of all classes (and in that the most used) just implement disposable
because they inherit from Component.model. Examples of that. All classes in
control, all classes in system.data.

Be aware about what Jay than wrote as well as soon as they are overridden in
fact than they implement Idispsable itself. You can than still decide if you
want to use it. The connection by instance removes the reference to the
ConnectionString to the object (and not anything more).

Cor
May 31 '06 #10

P: n/a
Cor Ligthert [MVP] wrote:
After reading the comments of Jay B. Harlow, my conclusion is: when you
create an object that is disposable, do it in such a way that you can
dispose of it.
But that has Jay no where written. You have read it without the word
*itself* implement Idisposable.

20% of all classes (and in that the most used) just implement disposable
because they inherit from Component.model. Examples of that. All classes in
control, all classes in system.data.


The Font class is an example of a class that doesn't implement
IDisposable just because it inherits from a base class. The only thing
that the Font class inherits is actually the IDisposable interface.

If the Font class didn't need to be disposed, it wouldn't inherit the
IDisposable interface. It does so because it handles unmanaged resources
that should be disposed of properly, and as soon as possible.

If it would be left to the garbage collector to free the resources by
calling the finalizer, the programmer has no control over when this will
happen, and it will certainly not happen as soon as possible. That is
why the control is handed over to the programmer.

The Dispose method is there because it should be used. It's not like the
area of the lottery ticket that says "do not scratch". It's not a part
of the internal memory management that is accidentally exposed to the
public. It's there for a reason.

Sure, there are some classes that has a Dispose method that doesn't
really need to be disposed, but if you want to skip that call you should
be certain that the class really doesn't need it. Also, you should be
certain that the class will never need it in the future either. When
framework 3.0 comes, are you still certain that the Dispose method of
that class is not used for anything?

The advice to anyone should be to call the Dispose method if there is
one. That takes no knowledge of the inner workings of the class. To skip
the call to the Dispose method requires a lot more knowledge.

It's a bit funny that way. Writing code is hard, but not writing code is
harder... ;)
Be aware about what Jay than wrote as well as soon as they are overridden in
fact than they implement Idispsable itself. You can than still decide if you
want to use it. The connection by instance removes the reference to the
ConnectionString to the object (and not anything more).


The Dispose method of a connection object does more than that. For
instance it closes the database connection.
May 31 '06 #11

P: n/a
Goran,

Feel free to do it that way.

You probably set as well all used values at null at the end of a method?

Cor

"Göran Andersson" <gu***@guffa.com> schreef in bericht
news:e9**************@TK2MSFTNGP02.phx.gbl...
Cor Ligthert [MVP] wrote:
After reading the comments of Jay B. Harlow, my conclusion is: when you
create an object that is disposable, do it in such a way that you can
dispose of it.


But that has Jay no where written. You have read it without the word
*itself* implement Idisposable.

20% of all classes (and in that the most used) just implement disposable
because they inherit from Component.model. Examples of that. All classes
in control, all classes in system.data.


The Font class is an example of a class that doesn't implement IDisposable
just because it inherits from a base class. The only thing that the Font
class inherits is actually the IDisposable interface.

If the Font class didn't need to be disposed, it wouldn't inherit the
IDisposable interface. It does so because it handles unmanaged resources
that should be disposed of properly, and as soon as possible.

If it would be left to the garbage collector to free the resources by
calling the finalizer, the programmer has no control over when this will
happen, and it will certainly not happen as soon as possible. That is why
the control is handed over to the programmer.

The Dispose method is there because it should be used. It's not like the
area of the lottery ticket that says "do not scratch". It's not a part of
the internal memory management that is accidentally exposed to the public.
It's there for a reason.

Sure, there are some classes that has a Dispose method that doesn't really
need to be disposed, but if you want to skip that call you should be
certain that the class really doesn't need it. Also, you should be certain
that the class will never need it in the future either. When framework 3.0
comes, are you still certain that the Dispose method of that class is not
used for anything?

The advice to anyone should be to call the Dispose method if there is one.
That takes no knowledge of the inner workings of the class. To skip the
call to the Dispose method requires a lot more knowledge.

It's a bit funny that way. Writing code is hard, but not writing code is
harder... ;)
Be aware about what Jay than wrote as well as soon as they are overridden
in fact than they implement Idispsable itself. You can than still decide
if you want to use it. The connection by instance removes the reference
to the ConnectionString to the object (and not anything more).


The Dispose method of a connection object does more than that. For
instance it closes the database connection.

May 31 '06 #12

P: n/a
When someone run out of arguments, they tend to attack the person
instead. I must say that it was a pretty lame attack, though...

Cor Ligthert [MVP] wrote:
Goran,

Feel free to do it that way.

You probably set as well all used values at null at the end of a method?

Cor

May 31 '06 #13

P: n/a
"Cor Ligthert [MVP]" <no************@planet.nl> schrieb:
Feel free to do it that way.

You probably set as well all used values at null at the end of a method?


Sorry Cor, but Göran is right. It definitely makes sense to call the
'Dispose' method whenever its available because implementing the
'IDisposable' interface simply says "call the 'Dispose' method after using
the object to free unmanaged resources occupied by the object". Even if
currently no unmanaged resources are released at all inside the method's
implementation, this might be the case in a future version. There are some
rare cases where I'd not call the 'Dispose' method, but the reason for this
is mainly that I do not care about the time when the resources are released.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

May 31 '06 #14

P: n/a
Herfried,

You mean that this guy is wrong, I think that somebody has to inform him
before things go really wrong.
Because that you have seen this, than maybe can you send him a message.

http://groups.google.com/group/micro...5919344c3c556a

The only thing you can say is that the dispose is generic used in the using
statement.
But in that is as well not generic a catch, something I am not so happy
with,

Cor

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
"Cor Ligthert [MVP]" <no************@planet.nl> schrieb:
Feel free to do it that way.

You probably set as well all used values at null at the end of a method?


Sorry Cor, but Göran is right. It definitely makes sense to call the
'Dispose' method whenever its available because implementing the
'IDisposable' interface simply says "call the 'Dispose' method after using
the object to free unmanaged resources occupied by the object". Even if
currently no unmanaged resources are released at all inside the method's
implementation, this might be the case in a future version. There are
some rare cases where I'd not call the 'Dispose' method, but the reason
for this is mainly that I do not care about the time when the resources
are released.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://classicvb.org/petition/>

May 31 '06 #15

P: n/a
Goran,

There are no more arguments to give in this thread, Jay has given them all
as an analyse what is often discussed in this newsgroup, so maybe can you
read those before you write messages and answer than that thread as you need
to do that.

Cor

"Göran Andersson" <gu***@guffa.com> schreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
When someone run out of arguments, they tend to attack the person instead.
I must say that it was a pretty lame attack, though...

Cor Ligthert [MVP] wrote:
Goran,

Feel free to do it that way.

You probably set as well all used values at null at the end of a method?

Cor

May 31 '06 #16

P: n/a
One other thing,

Breaking the code by changing existing members as dispose another meaning or
something extra, is one of the last things that ever will be done. Despite
what somebody active in another newsgroup forever writes.

Cor

"Göran Andersson" <gu***@guffa.com> schreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
When someone run out of arguments, they tend to attack the person instead.
I must say that it was a pretty lame attack, though...

Cor Ligthert [MVP] wrote:
Goran,

Feel free to do it that way.

You probably set as well all used values at null at the end of a method?

Cor

May 31 '06 #17

P: n/a
Cor Ligthert [MVP] wrote:
Goran,

There are no more arguments to give in this thread, Jay has given them all
as an analyse what is often discussed in this newsgroup,
So the Mighty Jay has spoken, and there is no room for argument?

If you want to refer to something that someone else wrote, why didn't
you do that instead of trying to patronise me?
so maybe can you
read those before you write messages and answer than that thread as you need
to do that.
Need to do what? I am unable to distinguish if you are referring to
reading the "analyse", write messages or answer that thread.

Cor

"Göran Andersson" <gu***@guffa.com> schreef in bericht
news:%2****************@TK2MSFTNGP02.phx.gbl...
When someone run out of arguments, they tend to attack the person instead.
I must say that it was a pretty lame attack, though...

Cor Ligthert [MVP] wrote:
Goran,

Feel free to do it that way.

You probably set as well all used values at null at the end of a method?

Cor


May 31 '06 #18

P: n/a
Cor,
| 20% of all classes (and in that the most used) just implement disposable
| because they inherit from Component.model. Examples of that. All classes
in
| control, all classes in system.data.
I suspect higher then 20%...

I would still call Dispose on them, as you need to use a tool such as ILDASM
or Reflector to accurately determine if the dispose does anything
interesting or not... Rather then rely on implementation details that are
subject to change, I recommend simply always calling Dispose as my list
suggests.

| The connection by instance removes the reference to the
| ConnectionString to the object (and not anything more).
Which connection? SqlConnection? SqlConnection does a lot more in its
Dispose then simply removing the reference to the ConnectionString!
SqlConnection also calls its Close method & other stuff! This is easily
verified with ILDASM or Reflector...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
|
| > After reading the comments of Jay B. Harlow, my conclusion is: when you
| > create an object that is disposable, do it in such a way that you can
| > dispose of it.
|
| But that has Jay no where written. You have read it without the word
| *itself* implement Idisposable.
|
| 20% of all classes (and in that the most used) just implement disposable
| because they inherit from Component.model. Examples of that. All classes
in
| control, all classes in system.data.
|
| Be aware about what Jay than wrote as well as soon as they are overridden
in
| fact than they implement Idispsable itself. You can than still decide if
you
| want to use it. The connection by instance removes the reference to the
| ConnectionString to the object (and not anything more).
|
| Cor
|
|
May 31 '06 #19

P: n/a
| When to call Dispose?

One "exception" I forgot to list:

* Do not explicitly call Dispose on classes deriving from
System.ComponentModel.Component for instances placed on a
System.Windows.Forms.Form as Form will implicitly dispose of them when the
form is Disposed.

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> wrote in
message news:en**************@TK2MSFTNGP05.phx.gbl...
| Roland,
| In addition to the other comments: I would use a variation of your first
| method:
|
| .NET 1.x
| Dim fnt as Font = New Font(...)
| Try
| DrawString(myText, fnt,...)
| Finally
| ' assuming fnt is not nothing
| fnt.dispose().
| End Try
|
|
| .NET 2.0
| Using fnt as Font = New Font(...)
| DrawString(myText, fnt,...)
| End Using
|
| As this ensure that any unmanaged resources that Font may be exposing (as
| evidenced by the fact that Font implements IDisposable) are released in a
| timely manner. As you have pointed out. The GC may take minutes or longer
to
| release the resource, this may cause undue pressure on both the GC &
Win32.
| The GC as it is tracking a number of Finalizable objects, Win32 as you are
| using Handles longer then necessary.
|
|
| When to call Dispose?
|
| * Call Dispose when the type itself implements IDisposable
|
| * Call Dispose when the type or one of its base classes *overrides*
| Dispose(Boolean) if the class inherits from
System.ComponentModel.Component
| or System.ComponentModel.MarshalByValueComponent
|
| * Do not explicitly call Dispose on classes deriving from
| System.Windows.Forms.Control for instances placed on a
| System.Windows.Forms.Form as Form will implicitly dispose of them when the
| form is Disposed
|
| * Call Dispose on System.Windows.Forms.Form objects when Form.ShowDialog
is
| used.
|
| * Do not explicitly call Dispose on System.Windows.Forms.Form objects if
| Form.Show is used as Dispose will be implicitly called when the form is
| closed
|
| * Do not explicitly call Dispose on classes deriving from
| System.Web.UI.Control as it will be implicitly called as part of the
normal
| ASP.NET page processing
|
| I consider the second rule controversial as it relies on using ILDASM or
| Reflector to find out implementation details of a class. Its meant for
| classes such as DataSet, that have an inherited Dispose, but Dispose
doesn't
| really do anything.
|
| These rules are based on private discussions with other MVPs & discussions
| held in the newsgroups earlier in 2005.
|
| These rules apply to objects that you create, explicitly or implicitly.
| Objects that you "own".
|
| Disposable Objects that are passed to you as a parameter of a method (such
| as the Graphics object on the Paint event) should not have their disposed
| method call, as the system calls it as part of the method that raises the
| event.
|
| Objects that something else "owns" should normally be disposed of by the
| "owning" object.
|
|
|
| --
| Hope this helps
| Jay B. Harlow [MVP - Outlook]
| .NET Application Architect, Enthusiast, & Evangelist
| T.S. Bradley - http://www.tsbradley.net
|
|
| "Roland" <ro**************@skynet.be> wrote in message
| news:e2**************@TK2MSFTNGP04.phx.gbl...
|| The following issue is puzzling me:
||
|| There are 2 ways of writing the code below:
|| ...
|| Dim fnt as Font = New Font(...)
|| DrawString(myText, fnt,...)
|| fnt.dispose().
||
|| or
|| DrawString(myText, New Font(...),...)
||
|| The difference between both is that in the second case, there is no way
to
|| explicitely dispose of the object (in the example, a Font object, but
that
|| is purely circumstantial). The basic issue is:
||
|| If an object is substantiated while passed a a parameter (as above), is
it
|| inherently disposed by the called procedure (here: drawstring) or isn't
it
|| at all?
||
|| The reason for this question is that I favor using the second way of
| coding,
|| because it much less verbose, but I am not sure about the consequences.
||
|| Can anybody shed some light on that? Thanks in advance.
||
||
|
|
May 31 '06 #20

P: n/a
Cor,
No that guy is "correct", note that he states "The only difference is that
Dispose *also* clears the connection
string."

Notice the word "also" in there; using Reflector (or ILDASM) one can see
that SqlConnection.Dispose(Boolean) clears the connection string, then calls
Close. Dispose also does some pool cleanup work...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
..NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:es**************@TK2MSFTNGP03.phx.gbl...
| Herfried,
|
| You mean that this guy is wrong, I think that somebody has to inform him
| before things go really wrong.
| Because that you have seen this, than maybe can you send him a message.
|
|
http://groups.google.com/group/micro...5919344c3c556a
|
| The only thing you can say is that the dispose is generic used in the
using
| statement.
| But in that is as well not generic a catch, something I am not so happy
| with,
|
| Cor
|
| "Herfried K. Wagner [MVP]" <hi***************@gmx.at> schreef in bericht
| news:%2****************@TK2MSFTNGP02.phx.gbl...
| > "Cor Ligthert [MVP]" <no************@planet.nl> schrieb:
| >> Feel free to do it that way.
| >>
| >> You probably set as well all used values at null at the end of a
method?
| >
| > Sorry Cor, but Göran is right. It definitely makes sense to call the
| > 'Dispose' method whenever its available because implementing the
| > 'IDisposable' interface simply says "call the 'Dispose' method after
using
| > the object to free unmanaged resources occupied by the object". Even if
| > currently no unmanaged resources are released at all inside the method's
| > implementation, this might be the case in a future version. There are
| > some rare cases where I'd not call the 'Dispose' method, but the reason
| > for this is mainly that I do not care about the time when the resources
| > are released.
| >
| > --
| > M S Herfried K. Wagner
| > M V P <URL:http://dotnet.mvps.org/>
| > V B <URL:http://classicvb.org/petition/>
|
|
May 31 '06 #21

P: n/a
Jay,

The guy is writing "one of them is enough", not explitly telling which and
as I remember some more messages from him in the AdoNet newsgroup he points
more on the close than the dispose. I know that dispose does something more,
the question is if it is adding functionality and should be therefore in the
code.

I can make a piece of program like this.
\\\
For i As Integer = 0 To 1000000
dt1.Rows(i)("counter") = 1
ds.Dispose()
Next
///
It does nothing (not even spent much time). However in my opinion does it
suggest something that not is done and should therefore not be in a program.

That every dispose acts as well as a close where that should be done is
obvious. The using is (as you know) from the first day in C# and therefore
that is needed.

Just my opinion.

Cor

"Jay B. Harlow [MVP - Outlook]" <Ja************@tsbradley.net> schreef in
bericht news:eV**************@TK2MSFTNGP04.phx.gbl...
Cor,
No that guy is "correct", note that he states "The only difference is that
Dispose *also* clears the connection
string."

Notice the word "also" in there; using Reflector (or ILDASM) one can see
that SqlConnection.Dispose(Boolean) clears the connection string, then
calls
Close. Dispose also does some pool cleanup work...

--
Hope this helps
Jay B. Harlow [MVP - Outlook]
.NET Application Architect, Enthusiast, & Evangelist
T.S. Bradley - http://www.tsbradley.net
"Cor Ligthert [MVP]" <no************@planet.nl> wrote in message
news:es**************@TK2MSFTNGP03.phx.gbl...
| Herfried,
|
| You mean that this guy is wrong, I think that somebody has to inform him
| before things go really wrong.
| Because that you have seen this, than maybe can you send him a message.
|
|
http://groups.google.com/group/micro...5919344c3c556a
|
| The only thing you can say is that the dispose is generic used in the
using
| statement.
| But in that is as well not generic a catch, something I am not so happy
| with,
|
| Cor
|
| "Herfried K. Wagner [MVP]" <hi***************@gmx.at> schreef in bericht
| news:%2****************@TK2MSFTNGP02.phx.gbl...
| > "Cor Ligthert [MVP]" <no************@planet.nl> schrieb:
| >> Feel free to do it that way.
| >>
| >> You probably set as well all used values at null at the end of a
method?
| >
| > Sorry Cor, but Göran is right. It definitely makes sense to call the
| > 'Dispose' method whenever its available because implementing the
| > 'IDisposable' interface simply says "call the 'Dispose' method after
using
| > the object to free unmanaged resources occupied by the object". Even
if
| > currently no unmanaged resources are released at all inside the
method's
| > implementation, this might be the case in a future version. There are
| > some rare cases where I'd not call the 'Dispose' method, but the
reason
| > for this is mainly that I do not care about the time when the
resources
| > are released.
| >
| > --
| > M S Herfried K. Wagner
| > M V P <URL:http://dotnet.mvps.org/>
| > V B <URL:http://classicvb.org/petition/>
|
|

Jun 1 '06 #22

This discussion thread is closed

Replies have been disabled for this discussion.