How to destroy arrays

Scott M. <s-***@nospam.nospam> wrote:

Everything in .NET is a type (either reference or value types). All types
are managed by the Garbage Collector. There is no need to "free up memory"
as this is the purpose of the GC. There are certain circumstances though,
when you may want the object in question to fall out of scope immediately,
rather than waiting for the end of a procedure. In this case you could make
the object = Nothing.

Usually that's unnecessary, however, as the garbage collector can tell
when a variable is last used in the IL. Unless you're in a particularly
special case (eg where a variable is used in the first iteration of a
long loop, and not thereafter) it's best not to clutter up your code
setting variables to null/Nothing.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #3

Hi Jon,

Maybe this is higher English; however can you tell me where your message is
different from that from Scott?

I found Scotts message very clear and I agree completely with him in the way
he wrote it.

Cor

Everything in .NET is a type (either reference or value types). All types are managed by the Garbage Collector. There is no need to "free up memory" as this is the purpose of the GC. There are certain circumstances though, when you may want the object in question to fall out of scope immediately, rather than waiting for the end of a procedure. In this case you could make the object = Nothing.

Usually that's unnecessary, however, as the garbage collector can tell
when a variable is last used in the IL. Unless you're in a particularly
special case (eg where a variable is used in the first iteration of a
long loop, and not thereafter) it's best not to clutter up your code
setting variables to null/Nothing.

Jul 21 '05 #4

Brian Davis

In addition, VB has an Erase statement, which should deallocate memory used
for the array's elements.

Brian Davis
http://www.knowdotnet.com

"Scott M." <s-***@nospam.nospam> wrote in message
news:eS****************@TK2MSFTNGP09.phx.gbl...

Everything in .NET is a type (either reference or value types). All types
are managed by the Garbage Collector. There is no need to "free up memory" as this is the purpose of the GC. There are certain circumstances though,
when you may want the object in question to fall out of scope immediately,
rather than waiting for the end of a procedure. In this case you could make the object = Nothing.
"Sarfraz Hooda" <sh****@iqueri.com> wrote in message
news:Od**************@TK2MSFTNGP09.phx.gbl...
Hi,

I have created an array of Objects in a collection. I was wondering is

there
a way to destroy the array to free up the space in the memory ? or they

are
automatically destroyed and garbagge collected by .Net framework?

Sarfraz

Jul 21 '05 #5

I think it's about code like:

{
SomeBigObject x = new SomeBigObject();
DoSomethingWithX(x);
// x = null;
DoSomethingElseThatTakesReallyLongButDoesntUseX();
}

Now, (as far as I got him) Jon tried to explain that there's NO use in
setting "x" to null/nothing, as the GC can tell it won't get used after line
2 anyway. I didn't read that in the previous post.

Of course, this only applies to local variables.

Niki

"Cor Ligthert" <no**********@planet.nl> wrote in
news:Oq***************@TK2MSFTNGP11.phx.gbl...

Hi Jon,

Maybe this is higher English; however can you tell me where your message is different from that from Scott?

I found Scotts message very clear and I agree completely with him in the way he wrote it.

Cor
Everything in .NET is a type (either reference or value types). All types are managed by the Garbage Collector. There is no need to "free up memory" as this is the purpose of the GC. There are certain circumstances though, when you may want the object in question to fall out of scope immediately, rather than waiting for the end of a procedure. In this case you could make the object = Nothing.

Usually that's unnecessary, however, as the garbage collector can tell
when a variable is last used in the IL. Unless you're in a particularly
special case (eg where a variable is used in the first iteration of a
long loop, and not thereafter) it's best not to clutter up your code
setting variables to null/Nothing.

Jul 21 '05 #6

Hi Niki,

I think not and although Scott did not mention it, what he told can count
even more for globally used objects.

I agree with Scott and Jon that it should not be done normally, however as
Scott already stated I believe that there are circumstances that it can be
done.

Cor

I think it's about code like:

{
SomeBigObject x = new SomeBigObject();
DoSomethingWithX(x);
// x = null;
DoSomethingElseThatTakesReallyLongButDoesntUseX();
}

Now, (as far as I got him) Jon tried to explain that there's NO use in
setting "x" to null/nothing, as the GC can tell it won't get used after line 2 anyway. I didn't read that in the previous post.

Of course, this only applies to local variables.

Jul 21 '05 #7

Cor Ligthert <no**********@planet.nl> wrote:

Maybe this is higher English; however can you tell me where your message is
different from that from Scott?

I found Scotts message very clear and I agree completely with him in the way
he wrote it.

Niki's message was spot on. Setting a variable to null/Nothing is less
useful than most people think - even for long-running methods, there
are only a few situations where it's of use.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #8

Quoted from Scott M.:

There are certain circumstances though,
when you may want the object in question to fall out of scope immediately,
rather than waiting for the end of a procedure. In this case you could make the object = Nothing.
This implies that usually objects will be garbage collected when they fall
out of scope, that is, at the end of the procedure.
Strictly speaking, that's wrong for both local AND member variables: local
variables might get collected BEFORE the end of the procedure (as Jon
explained), and member variables survive the end of a procedure if they're
not set to null/nothing.

I guess Scott was aware of these facts, but nonetheless, the correction was
ok.

Niki

"Cor Ligthert" <no**********@planet.nl> wrote in
news:%2****************@TK2MSFTNGP10.phx.gbl... Hi Niki,

I think not and although Scott did not mention it, what he told can count
even more for globally used objects.

I agree with Scott and Jon that it should not be done normally, however as
Scott already stated I believe that there are circumstances that it can be
done.

Cor
I think it's about code like:

{
SomeBigObject x = new SomeBigObject();
DoSomethingWithX(x);
// x = null;
DoSomethingElseThatTakesReallyLongButDoesntUseX();
}

Now, (as far as I got him) Jon tried to explain that there's NO use in
setting "x" to null/nothing, as the GC can tell it won't get used after

line
2 anyway. I didn't read that in the previous post.

Of course, this only applies to local variables.

Jul 21 '05 #9

Hi Jon,

Constructive quoting again from you, I once gave you a sample that more
people can do that however decent people do not do that.

Leaving the message from Scott out from this makes it the same as if Scott
was telling that the Tower Bridge was in Paris.

The message you give the same answer again as Scott was saying, while you
give the idea that he did not.

Maybe this is higher English; however can you tell me where your message is different from that from Scott?

I found Scotts message very clear and I agree completely with him in the way he wrote it.

Niki's message was spot on. Setting a variable to null/Nothing is less
useful than most people think - even for long-running methods, there
are only a few situations where it's of use.

Jul 21 '05 #10

Hi Niki,

Have a look at this, and follow as well the shortlink to nothing.

http://msdn.microsoft.com/library/de...vastmerase.asp

I hope this helps?

Cor

Jul 21 '05 #11

Cor Ligthert <no**********@planet.nl> wrote:

Constructive quoting again from you, I once gave you a sample that more
people can do that however decent people do not do that.

Leaving the message from Scott out from this makes it the same as if Scott
was telling that the Tower Bridge was in Paris.
Sorry if you thought I was implying that - I certainly wasn't, and I
don't actually think anyone thought I was.
The message you give the same answer again as Scott was saying, while you
give the idea that he did not.

No, it didn't. It gave more information, notably that the GC is capable
of detecting variables after their last use within a method in most
situations - it *automatically* makes objects (where appropriate)
eligible for garbage collection before the end of the method. This is
not what Scott implied (in the way that Niki and I read it at least)
when Scott wrote:

"There are certain circumstances though, when you may want the object
in question to fall out of scope immediately, rather than waiting for
the end of a procedure."

To me, that suggests that unless you take the given action, the method
(procedure in Scott's terminology) has to end before the variable's
contents will be collected.

However, I suspect that this whole subthread isn't really about garbage
collection at all, and that you'd have praised Scott for adding extra
information if the posts had been the other way round... (And that if
it had been someone else replying to Scott, you wouldn't have posted at
all.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #12

Sarfraz Hooda

Is there anything equivalent to Erase in C#?

Sarfraz
"Brian Davis" <br***@knowdotnet.nospam.com> wrote in message
news:OL**************@TK2MSFTNGP11.phx.gbl...

In addition, VB has an Erase statement, which should deallocate memory used for the array's elements.

Brian Davis
http://www.knowdotnet.com

"Scott M." <s-***@nospam.nospam> wrote in message
news:eS****************@TK2MSFTNGP09.phx.gbl...
Everything in .NET is a type (either reference or value types). All types are managed by the Garbage Collector. There is no need to "free up

memory"
as this is the purpose of the GC. There are certain circumstances though, when you may want the object in question to fall out of scope immediately, rather than waiting for the end of a procedure. In this case you could

make
the object = Nothing.
"Sarfraz Hooda" <sh****@iqueri.com> wrote in message
news:Od**************@TK2MSFTNGP09.phx.gbl...
Hi,

I have created an array of Objects in a collection. I was wondering is

there
a way to destroy the array to free up the space in the memory ? or
they are
automatically destroyed and garbagge collected by .Net framework?

Sarfraz

Jul 21 '05 #13

Brian Davis <br***@knowdotnet.nospam.com> wrote:

In addition, VB has an Erase statement, which should deallocate memory used
for the array's elements.

I don't *believe* it does, actually. It just sets each array element to
Nothing, which is the equivalent of calling Array.Clear. That's
different from actually deallocating the memory, which is the garbage
collector's job.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #14

Brian Davis

I would tend to agree with you. What made me think otherwise is that the
MSDN documentation states that the Erase Statement is "Used to release array
variables and deallocate the memory used for their elements," so I am not
really sure. If I had to guess, I'd say that you are correct, and that MSDN
just means that it is marked as OK for deallocation by the GC rather than
actually deallocated.

As a side note, Erase isn't the same as calling Clear. Clear will set
elements of the array to Nothing, while Erase sets the array variable itself
to Nothing.

Either way, setting the array to Nothing should be functionally the same as
calling Erase, but, as you have pointed out in previous posts, that
shouldn't be necessary in most applications.

Brian Davis
http://www.knowdotnet.com

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Brian Davis <br***@knowdotnet.nospam.com> wrote:
In addition, VB has an Erase statement, which should deallocate memory used for the array's elements.

I don't *believe* it does, actually. It just sets each array element to
Nothing, which is the equivalent of calling Array.Clear. That's
different from actually deallocating the memory, which is the garbage
collector's job.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #15

Brian Davis <br***@knowdotnet.nospam.com> wrote:

I would tend to agree with you. What made me think otherwise is that the
MSDN documentation states that the Erase Statement is "Used to release array
variables and deallocate the memory used for their elements," so I am not
really sure. If I had to guess, I'd say that you are correct, and that MSDN
just means that it is marked as OK for deallocation by the GC rather than
actually deallocated.
It wasn't even marking things as OK for deallocation in my (wrong)
understanding. It was just setting things to Nothing inside the array,
which may well not make them eligible for GC, as there could be other
references.

The MSDN is unfortunately not very clear (or, I believe, accurate) on
this. Looking at the IL generated, I believe it does just set the
variable to Nothing, which certainly doesn't fit in with the docs you
quoted. Odd.

So

Erase Foo, Bar Baz

is just the same as

Foo = Nothing
Bar = Nothing
Baz = Nothing

It seems relatively useless to me, to be honest. Maybe it was more
useful in VB6.
As a side note, Erase isn't the same as calling Clear. Clear will set
elements of the array to Nothing, while Erase sets the array variable itself
to Nothing.
Yup. You're absolutely right - I had completely misread the spec.
Sincere apologies for confusing things further :(
Either way, setting the array to Nothing should be functionally the same as
calling Erase, but, as you have pointed out in previous posts, that
shouldn't be necessary in most applications.

Yup.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #16

Hi Jon,

I would have answered as well as someone else had written the message you
did, however they seldom do. (Probably the tone had been something different
because arguing between us is not something new, therefore I did leave out
the introduction.)

:-)

In my opinion Scott told it very clear. I did not read anything in your
message that would have given the OP more information when this arguing had
not been.

In my opinion there is a scene where setting an array to nothing can be good
and I do not believe that that is contradicting what Scott wrote.

In pseudo to make it language independent

Arraylist MyArray

Main
MakeNewArray

MakeNewArray
MyArray = New ArrayList
for i=0;i<5000000;i++ Arraylist.add(myobject)

Event Button1Click
MyArray = nothing

Event Button2Click
MakeNewArray

In my opinion I give the GC the change to clean up the old MyArrayObjects
before the program is ended.

Cor

Jul 21 '05 #17

Sarfraz Hooda <sh****@iqueri.com> wrote:

Is there anything equivalent to Erase in C#?

There's an equivalent to what Erase *actually* does, which is just
setting the variable to null:

object[] foo = new object[100];
....

foo = null;

This is very rarely useful, as discussed elsewhere in the thread. (See
also http://blogs.msdn.com/csharpfaq/arch.../26/97229.aspx )

Of course, setting an instance or static variable to null is slightly
different - but for instance variables, I usually find that the array
is useful for exactly the same length of time as the object itself, so
again there's rarely a point in setting the variable to null.

Note that Erase doesn't automatically make an array eligible for
garbage collection - if there's another reference to the same array, it
can't be collected until that reference has changed (to null or to a
different array) or become eligible for garbage collection itself.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #18

Cor Ligthert <no**********@planet.nl> wrote:

In my opinion Scott told it very clear. I did not read anything in your
message that would have given the OP more information when this arguing had
not been.
Really. Having read only Scott's post, when would you believe Foo was
eligible for garbage collection in the Sub below?

Public Shared Sub Test()
Dim Foo(9) As Integer

Console.WriteLine(Foo(0))
Console.WriteLine("Hello")

MessageBox.Show ("Can it be collected now?")

End Sub

If I had just read Scott's post (and didn't know anything else) I would
expect the array not to be eligible for garbage collection until the
end of the Sub. In fact (in release mode), it's eligible for garbage
collection immediately after Foo(0) has been evaluated.
In my opinion there is a scene where setting an array to nothing can be good
and I do not believe that that is contradicting what Scott wrote.

No, and that's also not contradicting anything I wrote. I didn't
contradict what Scott wrote - I added to it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #19

Hi Jon,

Really. Having read only Scott's post, when would you believe Foo was
eligible for garbage collection.
This is the message from Scott

Everything in .NET is a type (either reference or value types). All types are managed by the Garbage Collector. There is no need to "free up memory" as this is the purpose of the GC. There are certain circumstances though, when you may want the object in question to fall out of scope immediately, rather than waiting for the end of a procedure. In this case you could make the object = Nothing.

Where Scott did write about the place it was eligible for the GC?

When the method falls out of scope, it does not always mean that an (in that
method created) object is collectable for the GC, however Scott did not
write that either.

This was your answerUsually that's unnecessary, however, as the garbage collector can tell
when a variable is last used in the IL. Unless you're in a particularly
special case (eg where a variable is used in the first iteration of a
long loop, and not thereafter) it's best not to clutter up your code
setting variables to null/Nothing.

It did, at that moment you wrote it, in my opinion Add nothing to the
question of the OP:

"How to destroy arrays", your message tells in a way where an array is
destroyed by the program (not for the system).

And that was for me already clear in the explanation from Scott. Why would
it be set to nothing at the end of the procedure (method)

Cor

Jul 21 '05 #20

Cor Ligthert <no**********@planet.nl> wrote:

Really. Having read only Scott's post, when would you believe Foo was
eligible for garbage collection.
This is the message from Scott

<snip>

I notice you haven't answered my question.
Where Scott did write about the place it was eligible for the GC?

When the method falls out of scope, it does not always mean that an (in that
method created) object is collectable for the GC, however Scott did not
write that either.
No - but he did write "There are certain circumstances though, when you
may want the object in question to fall out of scope immediately,
rather than waiting for the end of a procedure."

To me, Scott was giving the impression that he believed that local
variables ensured that the objects they had references to were not
eligible for garbage collection until the end of a procedure. That is
not the case, as my reply said.

<snip>
And that was for me already clear in the explanation from Scott. Why would
it be set to nothing at the end of the procedure (method)

I wasn't talking about setting variables to nothing at the end of the
method. I was talking about setting variables to nothing in the
*middle* of the method, which is pointless if the variable is not used
after that point in the method anyway. That was not clear from Scott's
message.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #21

Hi Jon,

I notice you haven't answered my question.

I do not know what question however when you mean about that setting to
nothing,

When I have this

dim a as integer
a = 1
a = 2
a = 3

Where do you think a is set to 2?

So why would that be different with = nothing.
When you know how the GC works than you should know what this means. (It is
not a magical thing you know)

And to repeat, Scott only said that things can be set to nothing automaticly
when the procedure goes out of scope (and than be disposed to the GC when
there is no reference at all anymore to it, which Scott did not write).

Cor

Jul 21 '05 #22

Cor Ligthert <no**********@planet.nl> wrote:

I notice you haven't answered my question.
I do not know what question

The one you quoted some of but didn't answer:

<quote (from my post)>
Having read only Scott's post, when would you believe Foo was
eligible for garbage collection in the Sub below?
</quote>

(with following code, of course).

Just to clarify my meaning, I was asking when you believe the array
which the Foo variable's value was a reference to would be eligible for
garbage collection.
however when you mean about that setting to
nothing,

When I have this

dim a as integer
a = 1
a = 2
a = 3

Where do you think a is set to 2?

So why would that be different with = nothing.
Because when a is an integer, the garbage collector isn't interested in
whether or not the variable is reachable. When a is an array reference,
it is.

So, in my example, because Foo is not used after
Console.WriteLine(Foo(0))
it isn't considered a "root" for garbage collection (in release mode -
in debug mode this optimisation isn't performed as the developer may
want to look at its value.
When you know how the GC works than you should know what this means. (It is
not a magical thing you know)
It's certainly not a magical thing - but I think it works somewhat
differently to how you imagine it does.

I recommend the GC section of Jeffrey Richter's "Applied Microsoft .NET
framework programming" book - it's truly excellent.
And to repeat, Scott only said that things can be set to nothing
automaticly when the procedure goes out of scope (and than be
disposed to the GC when there is no reference at all anymore to it,
which Scott did not write).

Actually, Scott didn't write that, fortunately - because it's not
true.Variables aren't "set to nothing automatically" - they're just not
considered to be roots by the garbage collector any more. What Scott
*did* imply (IMO) is that local variables were always considered to be
"roots" by the garbage collector until the end of the method. That's
not true.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #23

"Erase x" is just a fancy syntax for "x = nothing". And neither of the
articles says anything about the GC, so, I really don't know what you were
trying to say?

However, I think you still didn't get Jon's point:
Take the following example:
{
TestClass x = new TestClass();
x.DoSomething();
GC.Collect(); // <- this will actually collect "x", although it's not
set to null!
Thread.Sleep(100000);
}

If you run that code, the object "x" will get collected BEFORE the sleep,
although there is still a valid reference!
The GC can tell that "x" is not used any more although there is still a
valid reference to it. It can actually "look down your code" and see if you
still use a variable or not.
So, there it's rarely usefull setting a local variable to null/nothing.

Niki

Cor Ligthert" <no**********@planet.nl> wrote in
news:uo**************@TK2MSFTNGP11.phx.gbl...

Hi Niki,

Have a look at this, and follow as well the shortlink to nothing.

http://msdn.microsoft.com/library/de...vastmerase.asp
I hope this helps?

Cor

Jul 21 '05 #24

Hi Jon,

Just to clarify my meaning, I was asking when you believe the array
which the Foo variable's value was a reference to would be eligible for
garbage collection.
I thought you did know that?
Because when a is an integer, the garbage collector isn't interested in
whether or not the variable is reachable. When a is an array reference,
it is.
Did you not know that as well?

So, in my example, because Foo is not used after
Console.WriteLine(Foo(0))
it isn't considered a "root" for garbage collection (in release mode -
in debug mode this optimisation isn't performed as the developer may
want to look at its value.
Why should it not be, I thought I showed you that enough I hope I made it
clear now for you?

So why would that be different with = nothing. Because when a is an integer, the garbage collector isn't interested in
whether or not the variable is reachable. When a is an array reference,
it is.
Now I see you think that the = operater is for setting objects, no it is
ment to set something, that can be 1 2 3 or nothing, depended on the kind of
receiver it acts. And when a created object has no references anymore either
way, do not make a mistake in that, (it can be also that it is referenced
itself), than it is disposable (available) to the GC.
I recommend the GC section of Jeffrey Richter's "Applied Microsoft .NET
framework programming" book - it's truly excellent.

A very good link for this to look at is.
http://msdn.microsoft.com/architectu...l/scalenet.asp
I do not agree some things in it, as by instance they write that every
control has to be disposed by hand and some other things, however for most
things it is very clear.
And to repeat, Scott only said that things can be set to nothing
automaticly when the procedure goes out of scope (and than be
disposed to the GC when there is no reference at all anymore to it,
which Scott did not write).

Actually, Scott didn't write that, fortunately - because it's not
true.Variables aren't "set to nothing automatically" - they're just not
considered to be roots by the garbage collector any more. What Scott
*did* imply (IMO) is that local variables were always considered to be
"roots" by the garbage collector until the end of the method. That's
not true.

That was the reason of my first message to you, why are you additing to
Scotts message. I nowhere readed that implyment of Scott it was only (YMO),
however had told that, than I would not have connected a message.

Cor

Jul 21 '05 #25

Hi Niki,

I did deny nothing you wrote; however, Scott did nowhere write something
else in my opinion.

However rarely set to nothing is (IMO) overdone, I never make decisions for
someone else who has cases where it is well used.

Cor

Jul 21 '05 #26

Cor Ligthert <no**********@planet.nl> wrote:

Just to clarify my meaning, I was asking when you believe the array
which the Foo variable's value was a reference to would be eligible for
garbage collection.

I thought you did know that?

I know when it's eligible for garbage collection. What I was asking was
when *you* believed it would be eligible for garbage collection, and
what you'd have thought just from Scott's article.

Because when a is an integer, the garbage collector isn't interested in
whether or not the variable is reachable. When a is an array reference,
it is.

Did you not know that as well?

Yes, I knew that before. It wasn't clear that you did, however.

So, in my example, because Foo is not used after
Console.WriteLine(Foo(0))
it isn't considered a "root" for garbage collection (in release mode -
in debug mode this optimisation isn't performed as the developer may
want to look at its value.

Why should it not be, I thought I showed you that enough I hope I made it
clear now for you?

Um, you haven't shed any light on garbage collection in this thread, as
far as I can see. What exactly do you think you've made clear, and
where?

So why would that be different with = nothing.
Because when a is an integer, the garbage collector isn't interested in
whether or not the variable is reachable. When a is an array reference,
it is.

Now I see you think that the = operater is for setting objects, no it is
ment to set something, that can be 1 2 3 or nothing, depended on the kind of
receiver it acts. And when a created object has no references anymore either
way, do not make a mistake in that, (it can be also that it is referenced
itself), than it is disposable (available) to the GC.

Not sure what you mean by "the kind of receiver it acts" but integers
themselves are never garbage collected. (Boxed versions are, of course,
but that's different.)

The = operator is for setting the value of a variable (or property),
either to a value type value or to a reference. Never to an actual
object. I think we agree on this, but I'm afraid I didn't understand
most of what you wrote above ("it can be also that it is referenced
itself" for instance)...
Actually, Scott didn't write that, fortunately - because it's not
true.Variables aren't "set to nothing automatically" - they're just not
considered to be roots by the garbage collector any more. What Scott
*did* imply (IMO) is that local variables were always considered to be
"roots" by the garbage collector until the end of the method. That's
not true.

That was the reason of my first message to you, why are you additing to
Scotts message. I nowhere readed that implyment of Scott it was only (YMO),
however had told that, than I would not have connected a message.

Scott implied it when he specified the "rather than waiting for the end
of a procedure" in my opinion. If he'd said "rather than waiting for
the last use of the variable in the IL code" then I wouldn't have
written anything. He seemed to imply that there was something special
about the end of the procedure - otherwise why mention it?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #27

"Cor Ligthert" <no**********@planet.nl> wrote in
news:%2****************@TK2MSFTNGP10.phx.gbl...

Hi Niki,

I did deny nothing you wrote; however, Scott did nowhere write something
else in my opinion.
Then you should probably read Scott's post.
However rarely set to nothing is (IMO) overdone,
Could you write that in an English sentence too?
I never make decisions for
someone else who has cases where it is well used.

Ok, this is really getting stupid:
The OP wanted to know how to free an array, so you can be damn sure that he
does not even know "where it is well used". That's why he asked a ng in the
first place.
So, the various posts (except yours) all included information on how arrays
(or objects in general) are freed.

That fact that you did not understand parts of that information does not
imply there is no information, you know...

Niki

Jul 21 '05 #28

Hi Nikki,

However rarely set to nothing is (IMO) overdone, Could you write that in an English sentence too?

Can you tell what it is wrong in it; I tried to understand your sentence and
gave an answer on it.However there it's rarely usefull setting a local variable to null/nothing,

Cor

Jul 21 '05 #29

Hi Jon,

Scott implied it when he specified the "rather than waiting for the end
of a procedure" in my opinion. If he'd said "rather than waiting for
the last use of the variable in the IL code" then I wouldn't have
written anything. He seemed to imply that there was something special
about the end of the procedure - otherwise why mention it?

Now I see what you do not understand, there is no need to force an array to
nothing when it is only used in a method. Then it goes automatically out of
scope as Scott stated. Only when you do not want to wait to the end of the
procedure, you have to set it to nothing. For me it was completely clear.
Sorry I did not understand that it was not for you.

I hope you have notified also my text about that this is as well only when
there are no references any more to that object.

Cor

Jul 21 '05 #30

Cor Ligthert <no**********@planet.nl> wrote:

Scott implied it when he specified the "rather than waiting for the end
of a procedure" in my opinion. If he'd said "rather than waiting for
the last use of the variable in the IL code" then I wouldn't have
written anything. He seemed to imply that there was something special
about the end of the procedure - otherwise why mention it?
Now I see what you do not understand, there is no need to force an array to
nothing when it is only used in a method. Then it goes automatically out of
scope as Scott stated. Only when you do not want to wait to the end of the
procedure, you have to set it to nothing.
<sigh>

You still don't get it, do you? You don't have to set it to nothing
*even if you don't want to wait until the end of the method*.

The variable is no longer taken into consideration after its last use
(in release mode). This can be *long* before the end of the method.
*That's* the bit which wasn't in Scott's message, and which you *still*
don't seem to understand.
For me it was completely clear.
Sorry I did not understand that it was not for you.
It was clear to me what Scott meant - and that it was wrong, as shown
above.
I hope you have notified also my text about that this is as well only when
there are no references any more to that object.

Well it wasn't exactly new to me...

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #31

Hi Jon,

*That's* the bit which wasn't in Scott's message, and which you *still*
don't seem to understand.

That was explicitly in Scott's message; otherwise, there was no need to
mention that it would be destroyed anyway at the end of the procedure.
However, he did that implicitly.

Cor

Jul 21 '05 #32

Scott M.

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Scott M. <s-***@nospam.nospam> wrote:
Everything in .NET is a type (either reference or value types). All types are managed by the Garbage Collector. There is no need to "free up memory" as this is the purpose of the GC. There are certain circumstances though, when you may want the object in question to fall out of scope immediately, rather than waiting for the end of a procedure. In this case you could make the object = Nothing.

Usually that's unnecessary, however, as the garbage collector can tell
when a variable is last used in the IL. Unless you're in a particularly
special case (eg where a variable is used in the first iteration of a
long loop, and not thereafter) it's best not to clutter up your code
setting variables to null/Nothing.

I said basically the same thing Jon. Another circumstance would be if an
object had code in its Dispose method and by running that code sooner,
rather than later, you could free up other resources.

Jul 21 '05 #33

Cor Ligthert <no**********@planet.nl> wrote:

*That's* the bit which wasn't in Scott's message, and which you *still*
don't seem to understand.

That was explicitly in Scott's message; otherwise, there was no need to
mention that it would be destroyed anyway at the end of the procedure.
However, he did that implicitly.

No, he didn't. Niki doesn't either - it's not just my reading of it.
Scott's message implied "If you don't set the variable to Nothing, the
array won't be eligible for garbage collection until the end of the
procedure." That's the implication which isn't true.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #34

Scott M. <s-***@nospam.nospam> wrote:

Usually that's unnecessary, however, as the garbage collector can tell
when a variable is last used in the IL. Unless you're in a particularly
special case (eg where a variable is used in the first iteration of a
long loop, and not thereafter) it's best not to clutter up your code
setting variables to null/Nothing.
I said basically the same thing Jon.

Mostly, yes. What I was making clear was that a variable stops
interfering with garbage collection significantly *before* the end of
the method - whereas your post implied (IMO) that unless you set the
value to Nothing, it would continue to prevent the object in question
from being garbage collected until the end of the method. We certainly
agree that it's very rare that it's worth explicitly setting a variable
to Nothing.
Another circumstance would be if an
object had code in its Dispose method and by running that code sooner,
rather than later, you could free up other resources.

Yup, although that won't free memory (hence the "other" in your post, I
know - but many people unfortunately believe that calling Dispose
actually frees the memory).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #35

Jon Skeet [C# MVP] <sk***@pobox.com> wrote:

That was explicitly in Scott's message; otherwise, there was no need to
mention that it would be destroyed anyway at the end of the procedure.
However, he did that implicitly.

No, he didn't. Niki doesn't either - it's not just my reading of it.

Sorry - typo there. It should have been "Niki clear doesn't think so
either - it's not just my reading of it."

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #36

Scott M.

Jon,

First, you and Cor have been busy little bees on this....

Second, my original reply (OR) and the "certain circumstances" that I was
referring to have more to do with an object's Dispose() method firing and
not so much about that object's eligibility for garbage collection.

My understanding on this (and please correct me if I'm wrong) is that when
an object falls out of scope, it will fire off its Dispose() method (if it
has one). Then, when the object is actually about to be removed from memory
by the GC (which we can't say with any certainty if and when that happens),
the object's Finalize method will fire.

My understanding has been that while an object may be eligible for garbage
collection, if it hasn't fallen out of scope yet, then its Dispose method
might not have fired yet. By setting the object to Nothing before the end
of the procedure, you can get the Dispose method to fire sooner, rather than
later. This can be very useful when the object is holding some expensive
resource open or locked. So by getting Dispose to fire sooner, the
resources can be cleaned up sooner.

Is this not correct?

-Scott
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP***********************@msnews.microsoft.co m...

Sarfraz Hooda <sh****@iqueri.com> wrote:
Is there anything equivalent to Erase in C#?

There's an equivalent to what Erase *actually* does, which is just
setting the variable to null:

object[] foo = new object[100];
...

foo = null;

This is very rarely useful, as discussed elsewhere in the thread. (See
also http://blogs.msdn.com/csharpfaq/arch.../26/97229.aspx )

Of course, setting an instance or static variable to null is slightly
different - but for instance variables, I usually find that the array
is useful for exactly the same length of time as the object itself, so
again there's rarely a point in setting the variable to null.

Note that Erase doesn't automatically make an array eligible for
garbage collection - if there's another reference to the same array, it
can't be collected until that reference has changed (to null or to a
different array) or become eligible for garbage collection itself.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #37

C# Learner

Scott M. wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message [...]
Usually that's unnecessary, however, as the garbage collector can tell
when a variable is last used in the IL. Unless you're in a particularly
special case (eg where a variable is used in the first iteration of a
long loop, and not thereafter) it's best not to clutter up your code
setting variables to null/Nothing.

I said basically the same thing Jon.

I found that your statement could've easily been misunderstood as it was
somewhat vague, and that Jon's reply to it was fair and reasonable.

Even though my opinion wasn't asked for here, I posted it anyway because
it seems that someone else is trying to hammer Jon for his reply, which
I feel is unreasonable (and getting silly).
Another circumstance would be if an
object had code in its Dispose method and by running that code sooner,
rather than later, you could free up other resources.

Jul 21 '05 #38

Scott M. <s-***@nospam.nospam> wrote:

First, you and Cor have been busy little bees on this....
:)
Second, my original reply (OR) and the "certain circumstances" that I was
referring to have more to do with an object's Dispose() method firing and
not so much about that object's eligibility for garbage collection.
Ah, right. Read on...
My understanding on this (and please correct me if I'm wrong) is that when
an object falls out of scope, it will fire off its Dispose() method (if it
has one).
No, that's not true. Dispose is only called if *something* calls it -
it's not automatic in most situations.

Now, C# has the "using" statement which *does* automatically call
Dispose at the end of the block, but that's basically just syntactic
sugar. Most finalizers call Dispose themselves, of course.
Then, when the object is actually about to be removed from memory
by the GC (which we can't say with any certainty if and when that happens),
the object's Finalize method will fire.
Assuming it has one, and that GC.SuppressFinalize hasn't been called
for that object, yes.
My understanding has been that while an object may be eligible for garbage
collection, if it hasn't fallen out of scope yet, then its Dispose method
might not have fired yet. By setting the object to Nothing before the end
of the procedure, you can get the Dispose method to fire sooner, rather than
later. This can be very useful when the object is holding some expensive
resource open or locked. So by getting Dispose to fire sooner, the
resources can be cleaned up sooner.

Is this not correct?

Nope - see above. It's certainly a good idea to call Dispose as soon as
you're able to (though no sooner, of course!) but that needs to be done
explicitly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #39

C# Learner

Jon Skeet [C# MVP] wrote:

Jon Skeet [C# MVP] <sk***@pobox.com> wrote:
That was explicitly in Scott's message; otherwise, there was no need to
mention that it would be destroyed anyway at the end of the procedure.
However, he did that implicitly.

No, he didn't. Niki doesn't either - it's not just my reading of it.

Sorry - typo there. It should have been "Niki clear doesn't think so
either - it's not just my reading of it."

It seems that Cor may have misinterpreted Scott's post, as I, too, don't
think so.

Jul 21 '05 #40

Scott M.

So then, would this make sense:

Sub Foo
Dim x as new FooFoo()
x.stuff()
'Done using x now, but don't want to wait for dispose to naturally run
x.dispose()

...some operation that will take time...
...some operation that will take time...
...some operation that will take time...
...some operation that will take time...

End Sub
Now, in this case, if there were clean up code in x's dispose method we
could control when it happens, rather than waiting for the GC to get around
to it?

-Scott

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Scott M. <s-***@nospam.nospam> wrote:
First, you and Cor have been busy little bees on this....

:)
Second, my original reply (OR) and the "certain circumstances" that I was referring to have more to do with an object's Dispose() method firing and not so much about that object's eligibility for garbage collection.

Ah, right. Read on...
My understanding on this (and please correct me if I'm wrong) is that when an object falls out of scope, it will fire off its Dispose() method (if it has one).

No, that's not true. Dispose is only called if *something* calls it -
it's not automatic in most situations.

Now, C# has the "using" statement which *does* automatically call
Dispose at the end of the block, but that's basically just syntactic
sugar. Most finalizers call Dispose themselves, of course.
Then, when the object is actually about to be removed from memory
by the GC (which we can't say with any certainty if and when that happens), the object's Finalize method will fire.

Assuming it has one, and that GC.SuppressFinalize hasn't been called
for that object, yes.
My understanding has been that while an object may be eligible for garbage collection, if it hasn't fallen out of scope yet, then its Dispose method might not have fired yet. By setting the object to Nothing before the end of the procedure, you can get the Dispose method to fire sooner, rather than later. This can be very useful when the object is holding some expensive resource open or locked. So by getting Dispose to fire sooner, the
resources can be cleaned up sooner.

Is this not correct?

Nope - see above. It's certainly a good idea to call Dispose as soon as
you're able to (though no sooner, of course!) but that needs to be done
explicitly.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #41

Scott M. <s-***@nospam.nospam> wrote:

So then, would this make sense:

Sub Foo
Dim x as new FooFoo()
x.stuff()
'Done using x now, but don't want to wait for dispose to naturally run
x.dispose()

...some operation that will take time...
...some operation that will take time...
...some operation that will take time...
...some operation that will take time...

End Sub
Yup. (Assuming that FooFoo implements IDisposable, of course.)

If you don't call Dispose yourself, it could be a *very* long time
before resources are cleaned up - especially if the object is in
generation 2 (very unlikely in this case, but speaking about a more
general situation).
Now, in this case, if there were clean up code in x's dispose method we
could control when it happens, rather than waiting for the GC to get around
to it?

Yes. IDisposable should only be implemented for types either directly
containing unmanaged resources (handles etc) or for types which wrap
other types implementing IDisposable (eg StreamWriter, which wraps a
Stream).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #42

Scott M.

Ok Joh, thanks.

-Scott
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Scott M. <s-***@nospam.nospam> wrote:
So then, would this make sense:

Sub Foo
Dim x as new FooFoo()
x.stuff()
'Done using x now, but don't want to wait for dispose to naturally run x.dispose()

...some operation that will take time...
...some operation that will take time...
...some operation that will take time...
...some operation that will take time...

End Sub

Yup. (Assuming that FooFoo implements IDisposable, of course.)

If you don't call Dispose yourself, it could be a *very* long time
before resources are cleaned up - especially if the object is in
generation 2 (very unlikely in this case, but speaking about a more
general situation).
Now, in this case, if there were clean up code in x's dispose method we
could control when it happens, rather than waiting for the GC to get around to it?

Yes. IDisposable should only be implemented for types either directly
containing unmanaged resources (handles etc) or for types which wrap
other types implementing IDisposable (eg StreamWriter, which wraps a
Stream).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Jul 21 '05 #43