string and Stringbuilder confusion 2

[GabeC]

I am creating a DLL in C# but I don't understand completely when I should use a string variable or a StringBuilder object in this situation. I want to hold a variable that is a string and be able to update it and retrieve it via a property of the dll.

Which should I use, a string or a StringBuilder and if possible why?

namespace Mine
{
public class MyDLL
{
private string myString;

public UseString
{
get { return myString; }
set { myString = value; }
}
}
}

OR

namespace Mine
{
public class MyDLL
{
private StringBuilder myString = new StringBuilder();

public UseString
{
get { return myString.ToString(); }
set { myString.Replace(myString.ToString(), value); }
}
}
}

 

[chiph]

"string" is good for string values that don't change very much. The .NET CLR will allocate exactly enough space for the string, and no more. When you add onto it, the CLR must allocate new space and copy over the contents, plus whatever you're adding on. Very inefficient.

"Stringbuilder" is good for when you're changing the value of a string a lot, or are building up a string by concatenation. The .NET CLR will allocate more space than originally needed to allow room for growth. This helps prevent memory fragmentation, and is generally faster. If you know you'll be adding a lot, you can set a property ahead of time to tell the CLR to allocate more memory than it's default.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[GabeC]

Thanks for your response Chip.

I'm not positive why you referred my to the FAQ. Is it my subject line that needs improving, the actual question needs improving, you feel this question has been answered already or something else? I would appreciate the feedback.

Now back to my question.

Your explanation of the difference between the string and StingBuilder is detailed in a short description. I like it.

I understand the difference between the string and StringBuilder and I have searched for examples on the web and in this forum where the StringBuilder is used to hold the value of a property in a dll.

I feel that a StringBuilder is better suited for this situation but I have been having a little trouble with it and thought maybe I was doing something that really wasn’t prudent. I will continue to push forward. Thanks for your help.

Gabe

 

[dragonwell]

Don't feel bad, he refers everyone to that FAQ But what chiph said is right on the money. Basically, it boils down to:

StringBuilder s = new StringBuilder();
s.Append("This ");
s.Append("is ");
s.Append(" a sentence.");

is much more efficient than

string s = "This ";
s+="is ";
s+="a sentence.";

but in THIS case:

class MyClass{
    string _myString;
   
    public MyClass(string myString){
        _myString = myString;
    }
}

you might as well just use a string type.

HTH

 

[chiph]

Gabe -
I wasn't specifically referring you to the FAQ -- it's part of my signature. Several of us here try and get people to recognize others for their help, and this is just a little reminder.

Glad my answer was of some help to you, if a little terse. I tend to type that way as I know all of us here are really busy people, so I try not to insert too many wasted words. ;-)

Dragonwell is correct - no sense having a public method or property accept a StringBuilder, especially if the call will be marshalled, or might be in another assembly. The overhead of the marshalling (it has to convert the StringBuilder to a String for the remote call), and/or being runtime safety-checked eats up any potential savings.

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[GabeC]

Thanks dragonwell.

I think it just clicked (I hope). In nutshell, StringBuilder is preferrable when I am manipulating portions of a string while string is preferrable when working with the entire value such as setting the entire string to a new value as you have shown here.

Thanks to both for your assitance.


Gabe