[.net] changing a character in a C# string

Started by
18 comments, last by Washu 12 years, 9 months ago
changing a character in a C# string



suppose I have created a string in C# and I want to change the last character to a blank.

private static string sOldMassiveOutput;

public static string oldmassiveoutput
{
get { return sOldMassiveOutput.Trim(); }
set { sOldMassiveOutput = value; }
}
oldmassiveoutput[oldmassiveoutput.Length - 1] = ' ';

This will not work.
How do I make it work?

Advertisement
In .NET strings are immutable. You need to create a new string with the contents that you want. This can be done with dumping the string in a char array and modifying that, using a StringBuilder, using sub string and concatenation operations, etc.
String.Replace() is your friend. Also, .Trim() would automatically lop off the trailing space anyway.

In .NET strings are immutable. You need to create a new string with the contents that you want. This can be done with dumping the string in a char array and modifying that, using a StringBuilder, using sub string and concatenation operations, etc.

Dude, way too deep here. Strings are immutable but the CLR takes care of all that stuff in the background. Unless you've got a thousand page book stored in a string and are duplicating said string several times you won't really notice anything performance wise.

Moe is right about Trim taking off the trailing space.

Remove the call to Trim() and use Remove and Insert to modify the string. These will return strings so you will have to capture the result. Simply calling s.Remove(...) won't really do anything. You'll need s = s.Remove(...) followed by s = s.Insert(...). Or in your case s would be oldmassiveoutput.
Always strive to be better than yourself.

Dude, way too deep here. Strings are immutable but the CLR takes care of all that stuff in the background. Unless you've got a thousand page book stored in a string and are duplicating said string several times you won't really notice anything performance wise.

There is nothing 'too deep' about understanding that strings are immutable; it's the reason you need to remember to re-assign your string after every operation (i.e. don't just call replace without using the result). I cannot count the number of times I've seen people forget to do this and wonder why their string manipulation doesn't work. Understanding the immutable nature of strings prevents making this mistake repeatedly.

Also, mentioning usage of StringBuilder is entirely appropriate considering the example given had a string named '[color="#1c2837"]sOldMassiveOutput'. You don't need a thousand page book for performance to degrade quickly when performing many operations on a large string, such as building a couple large strings every frame of a game by concatenating a string by 1 character over and over.



Also, mentioning usage of StringBuilder is entirely appropriate considering the example given had a string named '[color="#1c2837"]sOldMassiveOutput'. You don't need a thousand page book for performance to degrade quickly when performing many operations on a large string, such as building a couple large strings every frame of a game by concatenating a string by 1 character over and over.

I did a test one time with StringBuilder, string.Concat and + sign concatenation in loops with a million iterations. While StringBuilder was slightly faster (by mere MS) at the end of the day it really doesn't matter. This is one place where micro-optimization is fail and people worry about it too much.

Also, if you keep building the same large string over and over you are doing it wrong. DRY (don't repeat yourself) applies here perfectly. While traditionally when people talk about DRY they are speaking in reference to code but it applies to data as well. If you are constantly generating the same string over and over then you should just store the entire string somewhere and check for the proper conditions with which it should appear. If it's a template string ("You inflicted x damage to y creature.") then use the .NET formatting characters and store the template string instead ("You inflixed {0} damage to {1}") and consume said template using string.Format.
Always strive to be better than yourself.

Strings are immutable but the CLR takes care of all that stuff in the background.

OK, then show me how to modify a string without creating a new one.

[quote name='landlocked' timestamp='1310480416' post='4834306']
Strings are immutable but the CLR takes care of all that stuff in the background.

OK, then show me how to modify a string without creating a new one.
[/quote]
I didn't say you could. I said the CLR takes care of it for you and unless you're storing entire tomes in a single string object that you really won't notice a performance hit doing a few concatenations. You even quoted me saying such. STFU.
Always strive to be better than yourself.

I didn't say you could. I said the CLR takes care of it for you and unless you're storing entire tombs in a single string object that you really won't notice a performance hit doing a few concatenations. You even quoted me saying such. STFU.

No, I quoted you saying that immutability is handled in the background and that you don't need to worry about it. If you truly didn't need to think about strings being immutable you should be able to show an example of modifying a string. Since you can't do so, then the fact that strings are immutable is relevant information and not "too deep". Note that my post said absolutely nothing about performance and was about the fact that you can't modify the string and need to create a new one.
The too deep part was advising the OP to use a char[] or a StringBuilder object when it's just as performant for all intents and purposes say s = s.Replace(args). You were advocating more complexity than is necessary.
Always strive to be better than yourself.

This topic is closed to new replies.

Advertisement