i dont understand the termSystem.String is immutable plz help

There stuff going on that is not that obvious. The System.String class is a reference class. In the C# language, as in most .NET languages, objects of a reference class must be allocated with the new keyword. The String class is special though, you don't have to use new. Both the C# compiler and the CLR work together to automatically create new string instances, without you having to use the new keyword.

They do this automatically, guided by the design principle that a string allocated on the garbage collected heap cannot be changed. This gives the string type some very desirable properties, it behaves like a value type. Some examples:

string s = "12345";

This invokes an implied new, the character string "12345" is allocated on the heap, the "s" variable references it.

string t = s;

This does *not* allocate a new string, the "t" variable simply references the "12345" string allocated on the heap. This makes creating "copies" of a string very cheap.

s = s + "678";

This looks like it mutates the string "12345" to "12345678". It doesn't, the runtime automatically invokes an implied new and creates the character string "12345678" on the heap. The "s" variable is changed to reference that new string. Note that the "t" variable is still referencing the old one, it doesn't change. The heap now contains two strings. If there wasn't an assignment to "t", the old string "12345" would be garbage.

test(s);

void test(string arg) {
arg = "abc";
}

Here, some of the characteristics of immutability come to life. We're calling a method test and are passing a reference type as an argument. If you'd do this with a normal reference type, changes made to the referenced object in the method actually changes the object. Not so for a string. The implicit new operator is used to create a new string on the heap and the "arg" variable is change to reference it, the original string object (s) does not change. That's big. It makes passing strings to a method very cheap, just like it is for any reference type. But there is no need to have to make a copy of the original string to preserve its value, just like a value type.

All of this makes working with strings cheap and natural. The guiding principal for their behavior here is immutability, enforced and implemented by the compiler and the CLR without you having to do any work.

Do note that there's a price. Working with strings can create a lot of garbage, necessarily so because every modification to a string requires a new string on the heap. That kind of garbage is almost always cheap because it will be collected by a gen #0 collection, but it can be quite noticeable due to the poor cache locality. That's why there is StringBuilder, a class that can store a string that is mutable.

---

Hans Passant.

When you call any instance methods of String class, like Substring, Insert etc..., the actual instance is not modified, but the new instance of the string class is created.

---

Vitaliy Liptchinsky http://dotnetframeworkplanet.blogspot.com/

Immutability basically means that you can't modify or mutate the object.

---

Mattias, C# MVP

In other languages such as C or C++ when you have the string '12345' which sits at a specific address in memory you are allowed to change a byte at thatmemory location to change the string to 'A2345' so you are 'mutating'/changeing the string, this is not allowed in C#, when you want to do the same change you'd do sometihng like

string s = "12345";
s = "A"+s.Substring(1);

This will allocate 5 new bytes to hold s, The A will be placed and the other 4 characters copied after which the memory that holds the old value of s '12345' will be freed.

There stuff going on that is not that obvious. The System.String class is a reference class. In the C# language, as in most .NET languages, objects of a reference class must be allocated with the new keyword. The String class is special though, you don't have to use new. Both the C# compiler and the CLR work together to automatically create new string instances, without you having to use the new keyword.

They do this automatically, guided by the design principle that a string allocated on the garbage collected heap cannot be changed. This gives the string type some very desirable properties, it behaves like a value type. Some examples:

string s = "12345";

This invokes an implied new, the character string "12345" is allocated on the heap, the "s" variable references it.

string t = s;

This does *not* allocate a new string, the "t" variable simply references the "12345" string allocated on the heap. This makes creating "copies" of a string very cheap.

s = s + "678";

This looks like it mutates the string "12345" to "12345678". It doesn't, the runtime automatically invokes an implied new and creates the character string "12345678" on the heap. The "s" variable is changed to reference that new string. Note that the "t" variable is still referencing the old one, it doesn't change. The heap now contains two strings. If there wasn't an assignment to "t", the old string "12345" would be garbage.

test(s);

void test(string arg) {
arg = "abc";
}

Here, some of the characteristics of immutability come to life. We're calling a method test and are passing a reference type as an argument. If you'd do this with a normal reference type, changes made to the referenced object in the method actually changes the object. Not so for a string. The implicit new operator is used to create a new string on the heap and the "arg" variable is change to reference it, the original string object (s) does not change. That's big. It makes passing strings to a method very cheap, just like it is for any reference type. But there is no need to have to make a copy of the original string to preserve its value, just like a value type.

All of this makes working with strings cheap and natural. The guiding principal for their behavior here is immutability, enforced and implemented by the compiler and the CLR without you having to do any work.

Do note that there's a price. Working with strings can create a lot of garbage, necessarily so because every modification to a string requires a new string on the heap. That kind of garbage is almost always cheap because it will be collected by a gen #0 collection, but it can be quite noticeable due to the poor cache locality. That's why there is StringBuilder, a class that can store a string that is mutable.

---

Hans Passant.

yes your reply is helpful........but i dont understand that, is it a fault of .net or plus point........?

thanks

Hi,
I think it is a plus point for .net, by the way, this article shows something about string intern in .net, hope it can help you to find your need.

Thanks,
Eric

---

Please remember to mark helpful replies as answers and unmark them if they provide no help.