A (not so) basic question.

  • Thread starter Thread starter Roland
  • Start date Start date
R

Roland

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.
 
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, 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.
 
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
 
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.
 
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


| 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.
|
|
 
Jay,

Seeing it after a longer time now, I became confused by this one.
* Call Dispose when the type itself implements IDisposable
Click to expand...

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


| 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.
|
|
Click to expand...
 
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
 
Thanks Jay, for this clarification.
I will stick to the more verbose way with objects that implement
IDisposable.



Jay B. Harlow said:
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


| 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.
|
|
Click to expand...
 
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.
Click to expand...

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
 
Cor said:
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.
Click to expand...

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).
Click to expand...

The Dispose method of a connection object does more than that. For
instance it closes the database connection.
 
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
 
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 said:
Feel free to do it that way.

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

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.
 
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
 
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
 
Cor said:
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,
Click to expand...

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.
Click to expand...

Need to do what? I am unable to distinguish if you are referring to
reading the "analyse", write messages or answer that thread.
 
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


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


message | 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
|
|
| || 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.
||
||
|
|
 
Back
Top