如果不能更改不可变的字符串变量，为什么要更改它呢？

Question

This might have been asked somewhere else but I just did not see it when I did a simple search. I am taking a C# class for work and I do know that string is immutable and stringBuilder can be changed through out the code.

But why does C# let you change the string if it is immutable?

Or does it let you change the string because it take a new memory spot and creates another hole string variable and abandons the other variable address location. If this is the case and the automatic garbage collection comes through and tidies up the C# memory locations does it really matter if a person uses string or stringBuilder?

Code:

        string sss = 'abcd';
        sss = 'ghy';
        sss = 'nnnnnn';

Answer 1

That's changing the value of a variable by assigning the variable to a different value.

That is not mutating the value to which the variable refers.

Answer 2

You've basically answered the question yourself. The short answer is " C# does not let you change the string"

For various design reasons, "String" in c# is implemented as a reference-type . What you're doing is changing the what sss references - you're not changing the thing that's being referenced. 'abcd' exists separately from 'ghy' exists separately from 'nnnnnn' You're not changing one thing into another thing. You're creating a whole new thing, and then changing which one sss references.

Strings are immutable in C# to make them behave like value-types even though they're implemented as reference types . Why? Because the alternative is worse:

Consider an example where strings are reference types, but aren't immutable - and you can change 'abcd' into 'ab12'. How would that look?

string mutableString = "abcd";
string anotherRef = mutableString;

mutableString.mutateTo("ab12"); //A method that doesn't exist - for exposition only

at this point anotherRef would also be "ab12" - which seems very unintuitive.

Regarding String Builder:

StringBuilder is more of a performance thing that's used in special cases. For most string concatenation, it doesn't matter. If you have two strings like "My name is" and "Pete" and you concatenate them - then you'll end up with a new string "My name is Pete" and the old strings will probably be stuck around in memory somewhere. Not a big deal. You have the full string that you want - not a lot of time or memory wasted. Consider a more extreme case though: What if you have more words: "The" "quick" "brown" "fox" "jumps" "over" "the" "lazy" "dog" and you want to concatenate them all together:

1. "The" + "quick" yields "The quick" (a new string)
2. "The quick" + "brown" yields "The quick brown" (another new string)
3. "The quick brown" + "fox" yields "The quick brown fox" (another new string - getting longer)
4. "The quick brown fox" + "jumps" yields "The quick brown fox jumps" (another new string - each more expensive than the last!)
5. etc. . .

You can see that this method results in a lot of extra intermediate strings that you don't really care about, but they'll all be allocated - which takes time - and they'll all hang around in memory until the GC gets rid of them. StringBuilder gives you a method to do the concatenation without having to allocate every one of the intermediate results.

Note - this next part isn't strictly true, but it's close enough for this example. There is no contractual behavior for the internal implementation of StringBuilder: You can think of it as "Lazy concatenation." It can hold references to all of the component strings internally, but won't reallocate space for the final result until you call the ToString method when you're done appending strings. This lets it compute the final size that it needs to be, and reallocate enough space for the whole combined string - once instead of n times.