Jump to content
  • Advertisement
Sign in to follow this  
athono

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

This topic is 2562 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.


Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

[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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!