A (not so) basic question.

[Roland]

The following issue is puzzling me:

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

or
DrawString(myTe xt, 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.

[Terry]

RE: A (not so) basic question.

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:
[color=blue]
> The following issue is puzzling me:
>
> There are 2 ways of writing the code below:
> ....
> Dim fnt as Font = New Font(...)
> DrawString(myTe xt, fnt,...)
> fnt.dispose().
>
> or
> DrawString(myTe xt, 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.
>
>
>[/color]

[Roland]

Re: A (not so) basic question.

Terry, thanks for replying.
1) I understand from the IDisposable.Dis pose 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.n ospam> wrote in message
news:FB1E1E45-3511-457E-8C31-3778505A8014@mi crosoft.com...[color=blue]
> 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:
>[color=green]
>> The following issue is puzzling me:
>>
>> There are 2 ways of writing the code below:
>> ....
>> Dim fnt as Font = New Font(...)
>> DrawString(myTe xt, fnt,...)
>> fnt.dispose().
>>
>> or
>> DrawString(myTe xt, 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.
>>
>>
>>[/color][/color]

[Cor Ligthert [MVP]]

Re: A (not so) basic question.

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.demeest er@skynet.be> schreef in bericht
news:eRBuUmvgGH A.3984@TK2MSFTN GP02.phx.gbl...[color=blue]
> Terry, thanks for replying.
> 1) I understand from the IDisposable.Dis pose 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.n ospam> wrote in message
> news:FB1E1E45-3511-457E-8C31-3778505A8014@mi crosoft.com...[color=green]
>> 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:
>>[color=darkred]
>>> The following issue is puzzling me:
>>>
>>> There are 2 ways of writing the code below:
>>> ....
>>> Dim fnt as Font = New Font(...)
>>> DrawString(myTe xt, fnt,...)
>>> fnt.dispose().
>>>
>>> or
>>> DrawString(myTe xt, 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.
>>>
>>>
>>>[/color][/color]
>
>[/color]

[Terry]

Re: A (not so) basic question.

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:
[color=blue]
> Terry, thanks for replying.
> 1) I understand from the IDisposable.Dis pose 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.n ospam> wrote in message
> news:FB1E1E45-3511-457E-8C31-3778505A8014@mi crosoft.com...[color=green]
> > 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:
> >[color=darkred]
> >> The following issue is puzzling me:
> >>
> >> There are 2 ways of writing the code below:
> >> ....
> >> Dim fnt as Font = New Font(...)
> >> DrawString(myTe xt, fnt,...)
> >> fnt.dispose().
> >>
> >> or
> >> DrawString(myTe xt, 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.
> >>
> >>
> >>[/color][/color]
>
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: A (not so) basic question.

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(myTe xt, fnt,...)
Finally
' assuming fnt is not nothing
fnt.dispose().
End Try


..NET 2.0
Using fnt as Font = New Font(...)
DrawString(myTe xt, 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.Componen tModel.Componen t
or System.Componen tModel.MarshalB yValueComponent

* 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.C ontrol 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.demeest er@skynet.be> wrote in message
news:e2Xu3gkgGH A.1612@TK2MSFTN GP04.phx.gbl...
| The following issue is puzzling me:
|
| There are 2 ways of writing the code below:
| ...
| Dim fnt as Font = New Font(...)
| DrawString(myTe xt, fnt,...)
| fnt.dispose().
|
| or
| DrawString(myTe xt, 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.
|
|

[Cor Ligthert [MVP]]

Re: A (not so) basic question.

Jay,

Seeing it after a longer time now, I became confused by this one.
[color=blue]
> * Call Dispose when the type itself implements IDisposable[/color]

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
[color=blue]
> * Call Dispose when the type or one of its base classes *overrides*
> Dispose(Boolean ) if the class inherits from
> System.Componen tModel.Componen t
> or System.Componen tModel.MarshalB yValueComponent
>
> * 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.C ontrol 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.demeest er@skynet.be> wrote in message
> news:e2Xu3gkgGH A.1612@TK2MSFTN GP04.phx.gbl...
> | The following issue is puzzling me:
> |
> | There are 2 ways of writing the code below:
> | ...
> | Dim fnt as Font = New Font(...)
> | DrawString(myTe xt, fnt,...)
> | fnt.dispose().
> |
> | or
> | DrawString(myTe xt, 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.
> |
> |
>
>[/color]

[Roland]

Re: A (not so) basic question.

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]" <notmyfirstname @planet.nl> wrote in message
news:OHCLpxvgGH A.4304@TK2MSFTN GP05.phx.gbl...[color=blue]
> 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.demeest er@skynet.be> schreef in bericht
> news:eRBuUmvgGH A.3984@TK2MSFTN GP02.phx.gbl...[color=green]
>> Terry, thanks for replying.
>> 1) I understand from the IDisposable.Dis pose 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.n ospam> wrote in message
>> news:FB1E1E45-3511-457E-8C31-3778505A8014@mi crosoft.com...[color=darkred]
>>> 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(myTe xt, fnt,...)
>>>> fnt.dispose().
>>>>
>>>> or
>>>> DrawString(myTe xt, 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.
>>>>
>>>>
>>>>[/color]
>>
>>[/color]
>
>[/color]

[Roland]

Re: A (not so) basic question.

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



"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @tsbradley.net> wrote in
message news:en$6PPzgGH A.4776@TK2MSFTN GP05.phx.gbl...[color=blue]
> 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(myTe xt, fnt,...)
> Finally
> ' assuming fnt is not nothing
> fnt.dispose().
> End Try
>
>
> .NET 2.0
> Using fnt as Font = New Font(...)
> DrawString(myTe xt, 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.Componen tModel.Componen t
> or System.Componen tModel.MarshalB yValueComponent
>
> * 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.C ontrol 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.demeest er@skynet.be> wrote in message
> news:e2Xu3gkgGH A.1612@TK2MSFTN GP04.phx.gbl...
> | The following issue is puzzling me:
> |
> | There are 2 ways of writing the code below:
> | ...
> | Dim fnt as Font = New Font(...)
> | DrawString(myTe xt, fnt,...)
> | fnt.dispose().
> |
> | or
> | DrawString(myTe xt, 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.
> |
> |
>
>[/color]

[Cor Ligthert [MVP]]

Re: A (not so) basic question.

[color=blue]
> 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.[/color]

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
ConnectionStrin g to the object (and not anything more).

Cor

[Göran Andersson]

Re: A (not so) basic question.

Cor Ligthert [MVP] wrote:[color=blue][color=green]
>> 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.[/color]
>
> 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.[/color]

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... ;)
[color=blue]
> 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
> ConnectionStrin g to the object (and not anything more).[/color]

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

[Cor Ligthert [MVP]]

Re: A (not so) basic question.

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" <guffa@guffa.co m> schreef in bericht
news:e9IH9NKhGH A.1204@TK2MSFTN GP02.phx.gbl...[color=blue]
> Cor Ligthert [MVP] wrote:[color=green][color=darkred]
>>> 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.[/color]
>>
>> 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.[/color]
>
> 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... ;)
>[color=green]
>> 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 ConnectionStrin g to the object (and not anything more).[/color]
>
> The Dispose method of a connection object does more than that. For
> instance it closes the database connection.[/color]

[Göran Andersson]

Re: A (not so) basic question.

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:[color=blue]
> 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[/color]

[Herfried K. Wagner [MVP]]

Re: A (not so) basic question.

"Cor Ligthert [MVP]" <notmyfirstname @planet.nl> schrieb:[color=blue]
> Feel free to do it that way.
>
> You probably set as well all used values at null at the end of a method?[/color]

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

[Cor Ligthert [MVP]]

Re: A (not so) basic question.

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:%23rJz7PMh GHA.1204@TK2MSF TNGP02.phx.gbl. ..[color=blue]
> "Cor Ligthert [MVP]" <notmyfirstname @planet.nl> schrieb:[color=green]
>> Feel free to do it that way.
>>
>> You probably set as well all used values at null at the end of a method?[/color]
>
> 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/>[/color]