A (not so) basic question.

microsoft.public.dotnet.languages.vb

28 May 2006 11:17 AM

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.

28 May 2006 3:05 PM

Terry

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

Show quoteHide quote

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

29 May 2006 8:26 AM

Roland

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.

Show quoteHide quote

"Terry" <Terry@nospam.nospam> wrote in message
news:FB1E1E45-3511-457E-8C31-3778505A8014@microsoft.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.
>>
>>
>>

29 May 2006 8:48 AM

Cor Ligthert [MVP]

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

Show quoteHide quote

"Roland" <roland.demees***@skynet.be> schreef in bericht
news:eRBuUmvgGHA.3984@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" <Terry@nospam.nospam> wrote in message
> news:FB1E1E45-3511-457E-8C31-3778505A8014@microsoft.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.
>>>
>>>
>>>
>
>

31 May 2006 6:57 AM

Roland

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

Show quoteHide quote

"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
news:OHCLpxvgGHA.4304@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" <roland.demees***@skynet.be> schreef in bericht
> news:eRBuUmvgGHA.3984@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" <Terry@nospam.nospam> wrote in message
>> news:FB1E1E45-3511-457E-8C31-3778505A8014@microsoft.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.
>>>>
>>>>
>>>>
>>
>>
>
>

31 May 2006 10:28 AM

Cor Ligthert [MVP]

> 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

31 May 2006 11:15 AM

Göran_Andersson

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.

31 May 2006 11:59 AM

Cor Ligthert [MVP]

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

Show quoteHide quote

"Göran Andersson" <gu***@guffa.com> schreef in bericht
news:e9IH9NKhGHA.1204@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.

31 May 2006 1:05 PM

Göran_Andersson

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:
Show quoteHide quote

> 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

31 May 2006 4:58 PM

Cor Ligthert [MVP]

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

Show quoteHide quote

"Göran Andersson" <gu***@guffa.com> schreef in bericht
news:%23$HphLLhGHA.1208@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

31 May 2006 9:50 PM

Göran_Andersson

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.

Show quoteHide quote

>
> Cor
>
> "Göran Andersson" <gu***@guffa.com> schreef in bericht
> news:%23$HphLLhGHA.1208@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
>
>

31 May 2006 5:01 PM

Cor Ligthert [MVP]

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

Show quoteHide quote

31 May 2006 3:07 PM

Herfried K. Wagner [MVP]

"Cor Ligthert [MVP]" <notmyfirstn***@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/>

31 May 2006 4:54 PM

Cor Ligthert [MVP]

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/microsoft.public.dotnet.framework.adonet/msg/515919344c3c556a

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

Show quoteHide quote

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> schreef in bericht
news:%23rJz7PMhGHA.1204@TK2MSFTNGP02.phx.gbl...
> "Cor Ligthert [MVP]" <notmyfirstn***@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/>

31 May 2006 11:04 PM

Jay B. Harlow [MVP - Outlook]

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]" <notmyfirstn***@planet.nl> wrote in message
news:esaocKNhGHA.4864@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/microsoft.public.dotnet.framework.adonet/msg/515919344c3c556a
Show quoteHide quote

|
| 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]" <hirf-spam-me-here@gmx.at> schreef in bericht
| news:%23rJz7PMhGHA.1204@TK2MSFTNGP02.phx.gbl...
| > "Cor Ligthert [MVP]" <notmyfirstn***@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/>
|
|

1 Jun 2006 6:17 AM

Cor Ligthert [MVP]

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

Show quoteHide quote

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@tsbradley.net> schreef in
bericht news:eVNHhaQhGHA.4252@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]" <notmyfirstn***@planet.nl> wrote in message
> news:esaocKNhGHA.4864@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/microsoft.public.dotnet.framework.adonet/msg/515919344c3c556a
> |
> | 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]" <hirf-spam-me-here@gmx.at> schreef in bericht
> | news:%23rJz7PMhGHA.1204@TK2MSFTNGP02.phx.gbl...
> | > "Cor Ligthert [MVP]" <notmyfirstn***@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/>
> |
> |
>
>

31 May 2006 10:58 PM

Jay B. Harlow [MVP - Outlook]

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

Show quoteHide quote

"Cor Ligthert [MVP]" <notmyfirstn***@planet.nl> wrote in message
news:%23Kr26yJhGHA.4656@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
|
|

29 May 2006 1:48 PM

Terry

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

Show quoteHide quote

"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" <Terry@nospam.nospam> wrote in message
> news:FB1E1E45-3511-457E-8C31-3778505A8014@microsoft.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.
> >>
> >>
> >>
>
>
>

29 May 2006 3:23 PM

Jay B. Harlow [MVP - Outlook]

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

Show quoteHide quote

"Roland" <roland.demees***@skynet.be> wrote in message
news:e2Xu3gkgGHA.1612@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.
|
|

29 May 2006 6:25 PM

Cor Ligthert [MVP]

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

Show quoteHide quote

> * 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" <roland.demees***@skynet.be> wrote in message
> news:e2Xu3gkgGHA.1612@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.
> |
> |
>
>

31 May 2006 7:19 AM

Roland

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

Show quoteHide quote

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_***@tsbradley.net> wrote in
message news:en$6PPzgGHA.4776@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" <roland.demees***@skynet.be> wrote in message
> news:e2Xu3gkgGHA.1612@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.
> |
> |
>
>

31 May 2006 11:01 PM

Jay B. Harlow [MVP - Outlook]

| 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

Show quoteHide quote

System.ComponentModel.Component
Show quoteHide quote

| 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" <roland.demees***@skynet.be> wrote in message
| news:e2Xu3gkgGHA.1612@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.
||
||
|
|