Destroy Objects How ?

  • Thread starter Thread starter Abhishek
  • Start date Start date
Tom Shelton said:
Calling dispose, sure - set to nothing no. If it's a local resource.
IMHO,
you should always call dispose if it is implemented.


I only mean Nothing (null) from a memory managment perspective - there are
definate algorthmic situations where setting an object to nothing makes
sense.
I'm only refering to the setting of nothing in regards to memory
managment.
The runtime is smart enough to know if a local object is not read again
during
a methods execution, then it is safe to clean it up.


Absolutely true... The 1% is basically, for logic and non local
resources.
From a memory management perspective, a local variable never has to be set
to
nothing for the GC to do it's job - though I still recommend calling
dispose
when an object implements IDisposable...
Click to expand...

I have been following this and think I have found a situation where settinga
variable to nothing is required. I am using the datarepeater (winforms)
from MS and one of the controls in the template is a picturebox. In an
attempt to get memory consumption under control I am getting the binding
list for the datarepeater and if it is already set I go thru the items
disposing the image for the picturebox (it will be in a list of objects).
Now if I get the objects again (using Linq which will cache them) and the
image has been disposed, there is no IsDisposed that I can get VB to
understand for the image so I had to do a dummy attempt to get a property
from the image which if it failed meant that the image was disposed. By
setting the image to nothing that makes for a much simpler , faster since it
has no try / catch to indicate the dispose.

LS
 
Lloyd Sheen said:
I have been following this and think I have found a situation where
settinga variable to nothing is required. I am using the datarepeater
(winforms) from MS and one of the controls in the template is a
picturebox. In an attempt to get memory consumption under control I am
getting the binding list for the datarepeater and if it is already set I
go thru the items disposing the image for the picturebox (it will be in a
list of objects). Now if I get the objects again (using Linq which will
cache them) and the image has been disposed, there is no IsDisposed that I
can get VB to understand for the image so I had to do a dummy attempt to
get a property from the image which if it failed meant that the image was
disposed. By setting the image to nothing that makes for a much simpler ,
faster since it has no try / catch to indicate the dispose.

LS
Click to expand...

There are limited occasions when explicit assignment to Nothing / Null can
help

So using Nothing isn`t always bad behavior however assigning a variabel to
Nothing can also have negative performance implications. It is easy to
accidentally extend the life of the variable when the compiler worked out
it didn't need it anymore.

That is why i liked Stephany`s answer so much ( included in my second post )
as it states between the lines that you should only use it if you know what
you are doing .

Regards

Michel
 
Tom Shelton said:
Calling dispose, sure - set to nothing no. If it's a local resource.
IMHO,
you should always call dispose if it is implemented.


I only mean Nothing (null) from a memory managment perspective - there are
definate algorthmic situations where setting an object to nothing makes
sense.
I'm only refering to the setting of nothing in regards to memory
managment.
The runtime is smart enough to know if a local object is not read again
during
a methods execution, then it is safe to clean it up.


Absolutely true... The 1% is basically, for logic and non local
resources.
From a memory management perspective, a local variable never has to be set
to
nothing for the GC to do it's job - though I still recommend calling
dispose
when an object implements IDisposable...
Click to expand...

Well i guess we share almost the same opinion , however i would go one step
furter with Dispose

IDisposable is a interface ( "Contract" ) , if the coder implemented
IDisposable you may asume that there is a reasson why he implemented this
"contract" in his code so seeing from that light you "should" call the
dispose method

Failing to Dispose an object which implements IDisposable typically results
in the object going into the finalization queue . The results of this is
that an object's memory that might have otherwise been
freed in generation 01 be freed until a later generation collection.

About that Nothing thingy wel it is confusing as the official Core
reference guide says

"page 201 of the VB.Net core reference

Because .Net objects don`t have real destructors , Well designed classes
should expose a method to let well behaved clients manually release any
resource such as files database connections and system objects as soon as
they do not need them any longer -- that is , just before setting the
reference to Nothing rather than waiting for for the subsequent garbage
collection .


"
This means

Foo.Close ' if implemented
Foo.Dispose ' if implemented
Foo=Nothing ' Always ?

I understand why people still use the Nothing pointer , and i do not really
see a bad thing about it except that it might be confusing but if the
documentation is already confusing us regarding this mather it isn`t strange
that you get a mix of opinions and styles .

regards

Michel
 
Well i guess we share almost the same opinion , however i would go one step
furter with Dispose

IDisposable is a interface ( "Contract" ) , if the coder implemented
IDisposable you may asume that there is a reasson why he implemented this
"contract" in his code so seeing from that light you "should" call the
dispose method
Click to expand...

I definately agree here - dispose/close should always be called.
Failing to Dispose an object which implements IDisposable typically results
in the object going into the finalization queue . The results of this is
that an object's memory that might have otherwise been
freed in generation 01 be freed until a later generation collection.
Click to expand...

I agree.
About that Nothing thingy wel it is confusing as the official Core
reference guide says

"page 201 of the VB.Net core reference

Because .Net objects don`t have real destructors , Well designed classes
should expose a method to let well behaved clients manually release any
resource such as files database connections and system objects as soon as
they do not need them any longer -- that is , just before setting the
reference to Nothing rather than waiting for for the subsequent garbage
collection .


"
This means

Foo.Close ' if implemented
Foo.Dispose ' if implemented
Foo=Nothing ' Always ?

I understand why people still use the Nothing pointer , and i do not really
see a bad thing about it except that it might be confusing but if the
documentation is already confusing us regarding this mather it isn`t strange
that you get a mix of opinions and styles .
Click to expand...

I have no problem with people setting local variables to nothing, as long as
they realize it isn't really doing anything :)
 
Tom,
I have no problem with people setting local variables to nothing, as long
as
they realize it isn't really doing anything :)
Click to expand...

As I read this reply of you then I get the idea that you never have done any
maintenance.
I know that this idea is wrong, however,

As in a program is invoked dispose then it means for me:
that it is a method inherited from compenents and not an own build one
that the object contains unmanaged resources
that in whatever way IDisposable is implemented and that it is not a
simple empty inherited dispose method.
that disposing of the unmanaged resources is not implemented in an other
way either by 'using' or by close.

If in a program a reference is set to nothing then I assume that is done
with a reason, not beause once somebody, who did not understand it, has
written that it is good practise. As you probably know means the phrase
"Good practise" to me: "The one who uses that does not know where he is
talking about, because he assumes that it does not hurts". Do in that
situation think about what Armin has written in this thread about disposing
by instance the pens from a paint object, while busy in a paint event. I
never realized me that, but it was for me very good information.

Seeing your other contributions in this thread, I in fact assume that you
agree with me.

Cor
 
Cor Ligthert said:
Tom,


As I read this reply of you then I get the idea that you never have done
any maintenance.
I know that this idea is wrong, however,

As in a program is invoked dispose then it means for me:
that it is a method inherited from compenents and not an own build one
that the object contains unmanaged resources
that in whatever way IDisposable is implemented and that it is not a
simple empty inherited dispose method.
that disposing of the unmanaged resources is not implemented in an
other way either by 'using' or by close.

If in a program a reference is set to nothing then I assume that is done
with a reason, not beause once somebody, who did not understand it, has
written that it is good practise. As you probably know means the phrase
"Good practise" to me: "The one who uses that does not know where he is
talking about, because he assumes that it does not hurts". Do in that
situation think about what Armin has written in this thread about
disposing by instance the pens from a paint object, while busy in a paint
event. I never realized me that, but it was for me very good information.

Seeing your other contributions in this thread, I in fact assume that you
agree with me.

Cor
Click to expand...




Well Cor i use the phrase "Good coding practice" for what it says in
English, in my homble opinion good coding practice is the standard defined
by the industry so in that light seen the one who doesn`t use good coding
practice is mostly the amateur / wannabe coder.

regards
Michel
 
Back
Top