If StringBuilder has the ability to Insert and Remove then why not EndsWith
and StartsWith? Hell, why not even something like Substring and Split which
would return strings(or even stringbuilders)
To me this class seems to be the most useless class?
I'm building up a very large string from network data by appending text data
together. Once that is done I want to parse the text. Using StringBuilder
only seems to help in one respect while using a string only in the
other(well, it does both but slow on appending). Surely there is something
that has the best of both worlds.
Do I need to convert the StringBuilder into a string after I do the
appending? (I'm worried about performance impact of this when it seems there
is no real reason for it)
(I just don't see why they couldn't have added more functionality to
StringBuilder)
Thanks,
Jon
Jon Skeet [C# MVP] - 19 Mar 2008 08:38 GMT
> If StringBuilder has the ability to Insert and Remove then why not EndsWith
> and StartsWith? Hell, why not even something like Substring and Split which
> would return strings(or even stringbuilders)
>
> To me this class seems to be the most useless class?
Interesting, as many people find it very useful indeed...
> I'm building up a very large string from network data by appending text data
> together. Once that is done I want to parse the text. Using StringBuilder
> only seems to help in one respect while using a string only in the
> other(well, it does both but slow on appending). Surely there is something
> that has the best of both worlds.
Just call ToString() and then parse.
> Do I need to convert the StringBuilder into a string after I do the
> appending? (I'm worried about performance impact of this when it seems there
> is no real reason for it)
Calling ToString on a StringBuilder has no performance implications at
all *so long as you don't then append to the StringBuilder again*.
StringBuilder holds a string internally - they're mutable as far as
mscorlib is concerned. ToString() just returns the string and remembers
that it has been made public and therefore can't be changed any more.
> (I just don't see why they couldn't have added more functionality to
> StringBuilder)
Single responsibility, I guess. StringBuilders are used for *building*
strings, not parsing them.

Signature
Jon Skeet - <skeet@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk
Peter Duniho - 19 Mar 2008 08:39 GMT
> If StringBuilder has the ability to Insert and Remove then why not
> EndsWith
> and StartsWith? Hell, why not even something like Substring and Split
> which
> would return strings(or even stringbuilders)
Well, at the risk of trying to reply to someone who seems to already have
cemented their opinion...
IMHO, the answer is that doing so would encourage people to use
StringBuilder as if it were an actual string class, which it's not.
> To me this class seems to be the most useless class?
If you understand the class's purpose, which is to build strings (hence
the name), then it is far from useless.
> I'm building up a very large string from network data by appending text
> data
[quoted text clipped - 3 lines]
> something
> that has the best of both worlds.
Sure. Use StringBuilder for its intended purpose, which is to build the
string. Then call ToString() on that instance and get an actual String
instance from it. Then you can use whatever String class methods you want.
> Do I need to convert the StringBuilder into a string after I do the
> appending? (I'm worried about performance impact of this when it seems
[quoted text clipped - 3 lines]
> (I just don't see why they couldn't have added more functionality to
> StringBuilder)
Well, you can always write your own extension methods if you like. It
shouldn't be too hard to implement methods like "EndsWith()" and
"StartsWith()". It's not that the StringBuilder class is write-only. It
just doesn't contain methods that aren't directly related to mutating
strings.
It's funny...I just saw a Slashdot reference in which the usual crowd of
Microsoft-haters were lambasting .NET for having too _much_ in it. And
yet, in reality I think .NET is often very good as following the general
"make the class do just one thing well" rule (which is actually a pretty
good rule to try to follow). This being a classic example of such.
Pete