imutable string!

[touchstone]

hi, while studying   string , i found a phrase like
"String is imutable ".......i want to know what is the meaning of this ?   any small example.?......is this true only for java ?

[iago]

It means a string can never be changed. Like this, for example:
String a = "abc";
a = a + "def";

the original String a is being destroyed, and a new stirng, "abcdef" is being created.  

so if you do this:
for(int i = 0; i < 100; i++) a = a + "Number: " + i " + '\n';
it's actually doing A LOT of stuff:
each loop, it's creating a new string, which has number on the end and copies everything over.  Then it creates a new string, with the number after it.  Then it creates a new string that has '\n' at the end, then it loops again and does it all again.

No, not all languages are like this; Java is especially good at it, though, because it takes care of the cleanup so you don't leak memory when this happens.

[Skywing]

Note that iago's statement is usually false.

Most JVM programs I've seen have always seemed to only garbage collect when they run out of memory or reach a (large) preset size (like 30MB or so).

[iago]

Note that iago's statement is usually false.

Most JVM programs I've seen have always seemed to only garbage collect when they run out of memory or reach a (large) preset size (like 30MB or so).

But it DOES clean itself up, at some point or other.  If the same thing happens in C++, which never even TRIES to clean itself up, you would leak memory like mad.

[Kp]

Instead you only leak copious amounts of memory out into the void that is the JVM, rather than returning it to the OS for use by other programs.  It's been my experience that anyone who willingly runs a Java application has accepted the inevitable that it will consume horrid amounts of memory, between of its tendency not to garbage collect effectively and its tendency to preallocate / post-gc-retain large amounts of memory.

[Tuberload]

Instead you only leak copious amounts of memory out into the void that is the JVM, rather than returning it to the OS for use by other programs.  It's been my experience that anyone who willingly runs a Java application has accepted the inevitable that it will consume horrid amounts of memory, between of its tendency not to garbage collect effectively and its tendency to preallocate / post-gc-retain large amounts of memory.

You do have access to the garbage collector. So couldn't you make it work to your liking?

Edit: Grammar

[iago]

My friend was doing experiments with Java's GC once.  It was on a Solaris machine, Java 1.3.1, and it would kick in at 30kb, I believe.  I can find out the exact number tomorrow.

[Kp]

You do have access to the garbage collector. So you couldn't you make it work to your liking?

Quite honestly, I never tried.  I didn't see it as being worth the time to clean up someone else's mistakes in designing a language I'm not yet required to use for anything serious.

[Tuberload]

You do have access to the garbage collector. So you couldn't you make it work to your liking?

Quite honestly, I never tried.  I didn't see it as being worth the time to clean up someone else's mistakes in designing a language I'm not yet required to use for anything serious.

That makes sense. I will do it someday and post my results.