How would you code it?
-
And don't forget ...
value==null?"null":value.ToString()...PIEBALDconsult wrote:
And don't forget ...value==null?"null":value.ToString()...
How do you handle that with format specifiers?
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
-
Shog9 wrote:
which of the above paragraphs do you prefer?
1! :-D
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
Surprise surprise! ;P
every night, i kneel at the foot of my bed and thank the Great Overseeing Politicians for protecting my freedoms by reducing their number, as if they were deer in a state park. -- Chris Losinger, Online Poker Players?
-
malharone wrote:
Performance: string concat. is heavy, which does not happen in the string.format
That's what I thought as well. Although the OP stated that the concat. approach was more efficient, but I'm not so sure I buy his reasoning for it. I think he's fishing for "5" votes. ;) BDF
string.Concat is the fastest way to concatenate strings. StringBuilder is not faster than string.Concat; only multiple Append calls to the same StringBuilder are more efficient than multiple calls to Concat for building a single string.
-
Here's a simple code snippet (in C#):
string hello = "Hello";
string cp = "CP";
DateTime today = DateTime.Today;// Desired result: "Hello CP! Today is Friday";
string option1 = string.Format("{0} {1}! Today is {3:dddd}", hello, cp, today);
string option2 = hello + " " + cp + "! Today is " + today.ToString("dddd");
Vote 1 if you prefer option1. Vote 5 if you prefer option2. I prefer option2 since it's 1. More readable 2. Less error-prone (note the subtle error in option1 which the compiler won't catch) 3. More efficient (no CPU cycles spent scanning the format string looking for matching curly braces). Cheers!
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
Al Beback wrote:
1. More readable
Entirely and completely subjective.
Al Beback wrote:
2. Less error-prone (note the subtle error in option1 which the compiler won't catch)
Perhaps. But you do have unit tests and system tests correct? If so then why are they not testing that code?
Al Beback wrote:
3. More efficient (no CPU cycles spent scanning the format string looking for matching curly braces).
If that is an actual performance bottleneck in your system then you have a very unusual system. Nothing in the above suggests an actual valid reason to choose either. As such it is a matter of personal choice. One real reason for choosing the Format version is because it support internationalization where the other does not. That of course is dependent on whether the application does have an international market and whether the multitude of other areas required for internationalization are actively being worked. And I can only note that actually moving this into a resource to support internationalization has many other possibilities for errors so one really better be testing everything.
-
string.Concat is the fastest way to concatenate strings. StringBuilder is not faster than string.Concat; only multiple Append calls to the same StringBuilder are more efficient than multiple calls to Concat for building a single string.
Thanks. That makes sense. Do you think it's even an issue in the very simple cases shown in the start of this thread? That's creating a string with a few concatenations versus String.Format. BDF
-
PIEBALDconsult wrote:
Well, if/when you use a Console.WriteLine(), would you use the format string and parameters?
No. I would still use concatenation for the same reasons (readability, stability, and efficiency).
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
Well consistency is good too.
-
Only for small numbers of strings. If I remember correctly it is <= 3. Anyway, performance shouldn't be much of a concern with either method.
This blanket smells like ham
It's <= 4. For more strings, it's still a single call to Concat(string[]), which means a temporary string array is created. This is still better than creating a temporary StringBuilder object, which creates multiple String objects when it needs to make the string larger. I only use StringBuilder when it is not possible to use a single call to string.Concat - e.g. in a loop like this: StringBuilder b = new StringBuilder(); foreach (SomeClass c in list) { b.Append(c.Text); b.Append(','); } return b.ToString(); The algorithm is O(n), with multiple string.Concat calls it would be O(n^2). Somehow the advice that StringBuilder should be used in those cases became the urban legend "StringBuilder is always faster in a loop". The advice only applies if the loop is appending to a single string; in cases where one would need multiple StringBuilder objects (or where one would re-use a StringBuilder object after calling ToString() on it), string.Concat is faster: string[] ConcatPairs(string[] a, string[] b) { string[] c = new string[a.Length]; for (int i = 0; i < a.Length; i++) { c[i] = a[i] + b[i]; } return c; } And String.Format is a real performance killer: not only is it required to parse the format string, it also puts all arguments in a temporary object[] array (value types are boxed if required), tries to cast all arguments to IFormattable, then calls ToString() on them (a virtual method call, or interface method call if the object implements IFormattable). And in the end it uses StringBuilder for the concatenation (since string.Format contains a loop appending to the same string), which even alone is slower than a single string.Concat call.
-
Here's a simple code snippet (in C#):
string hello = "Hello";
string cp = "CP";
DateTime today = DateTime.Today;// Desired result: "Hello CP! Today is Friday";
string option1 = string.Format("{0} {1}! Today is {3:dddd}", hello, cp, today);
string option2 = hello + " " + cp + "! Today is " + today.ToString("dddd");
Vote 1 if you prefer option1. Vote 5 if you prefer option2. I prefer option2 since it's 1. More readable 2. Less error-prone (note the subtle error in option1 which the compiler won't catch) 3. More efficient (no CPU cycles spent scanning the format string looking for matching curly braces). Cheers!
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
-
Chris Maunder wrote:
No Option #3: Use a StringBuilder?
No. StringBuilder is suitable for appending to an existing string. In my example I append a bunch of strings to create a new one.
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
-
PIEBALDconsult wrote:
And don't forget ...value==null?"null":value.ToString()...
How do you handle that with format specifiers?
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
It's not so much the format string. But in Option2 it makes determining the result even harder and it needs to be enclosed in parentheses or it'll eat the rest of the line. (Won't it? The + having precedence over the ?: )
-
Dave Kreskowiak wrote:
I don't buy it. I just don't see how any variant of Dim sqlUpdate ...
I don't see how any variant of that is not subject to sql injection attacks. Consequently it isn't clear to me that that particular example proves anything.
You're missing the point. Forget that it's SQL. Imagine writing that for output to a line printer.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Oh, well for that you need parameters anyway.
Forget that it's SQL. Imagine writing that for output to line printer.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Dave Kreskowiak wrote:
can possibly be considered "easier to debug".
I never mentioned debugging. When you debug this, you step over that statement and look at the resulting string. It's the same when using Format.
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
Debugging takes many forms. You implied it when you said "less error-prone". Say the output on a report isn't correct. Go through that line and find the one or two spaces, or some other formatting or data accuracy issue, where the problem is occuring. Sorry, but I don't see how reading that line is easier than
Dim sqlUpdate As String = String.Format("UPDATE {0} SET OrderItemRetailPrice = {1}, " & _
"OrderItemSalePrice = {2} WHERE OrderItemPartNum = {3}, " & _
"OrderItemSource = {4}, OrderType = {5}", _
"ls_orderitems", PartRetailPrice, PartSalePrice, _
PartNum, PartSource, "Ron Ayers MotorSports")A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Forget that it's SQL. Imagine writing that for output to line printer.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007I'm in the Option1 camp.
-
It's <= 4. For more strings, it's still a single call to Concat(string[]), which means a temporary string array is created. This is still better than creating a temporary StringBuilder object, which creates multiple String objects when it needs to make the string larger. I only use StringBuilder when it is not possible to use a single call to string.Concat - e.g. in a loop like this: StringBuilder b = new StringBuilder(); foreach (SomeClass c in list) { b.Append(c.Text); b.Append(','); } return b.ToString(); The algorithm is O(n), with multiple string.Concat calls it would be O(n^2). Somehow the advice that StringBuilder should be used in those cases became the urban legend "StringBuilder is always faster in a loop". The advice only applies if the loop is appending to a single string; in cases where one would need multiple StringBuilder objects (or where one would re-use a StringBuilder object after calling ToString() on it), string.Concat is faster: string[] ConcatPairs(string[] a, string[] b) { string[] c = new string[a.Length]; for (int i = 0; i < a.Length; i++) { c[i] = a[i] + b[i]; } return c; } And String.Format is a real performance killer: not only is it required to parse the format string, it also puts all arguments in a temporary object[] array (value types are boxed if required), tries to cast all arguments to IFormattable, then calls ToString() on them (a virtual method call, or interface method call if the object implements IFormattable). And in the end it uses StringBuilder for the concatenation (since string.Format contains a loop appending to the same string), which even alone is slower than a single string.Concat call.
Good to know, the last info I saw on it was in the 1.0 days, when concat was only used for short strings of +'s after that it handled it as coded. It's good to hear that C# is getting smarter.
Daniel Grunwald wrote:
And String.Format is a real performance killer
I've still never seen that in a real world application even ASP.NET pages handling hundreds of requests per second.
This blanket smells like ham
-
Here's a simple code snippet (in C#):
string hello = "Hello";
string cp = "CP";
DateTime today = DateTime.Today;// Desired result: "Hello CP! Today is Friday";
string option1 = string.Format("{0} {1}! Today is {3:dddd}", hello, cp, today);
string option2 = hello + " " + cp + "! Today is " + today.ToString("dddd");
Vote 1 if you prefer option1. Vote 5 if you prefer option2. I prefer option2 since it's 1. More readable 2. Less error-prone (note the subtle error in option1 which the compiler won't catch) 3. More efficient (no CPU cycles spent scanning the format string looking for matching curly braces). Cheers!
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
Glaring misconception or a deliberate misguiding in the forum. String concatenations are always heavy. Always use either string.Format or StringBuilder. The compiler and runtime would love you for the kindness and friendliness.
Vasudevan Deepak Kumar Personal Homepage Tech Gossips
-
Good to know, the last info I saw on it was in the 1.0 days, when concat was only used for short strings of +'s after that it handled it as coded. It's good to hear that C# is getting smarter.
Daniel Grunwald wrote:
And String.Format is a real performance killer
I've still never seen that in a real world application even ASP.NET pages handling hundreds of requests per second.
This blanket smells like ham
Well, performance is relative. I think I saw a benchmark where string.Concat was fastest, StringBuilder was 5% slower and string.Format was 400% slower (of course these results are highly dependent on the length of the strings you are testing with). But if you are calling string.Format less than a 100000 times per second, you probably won't see the difference. The only thing that can really hurt the performance is using multiple string.Concat calls to append to the same string. Where this loop: List input = /*1 million chars*/; StringBuilder b = new StringBuilder(); foreach (char c in input) { b.Append(c); } copies ca. 4 MB in RAM. (1 char = 2 bytes, some chars copied multiple times when the buffer needs to be resized), this loop: string b = ""; foreach (char c in input) { b += c; } copies 2 bytes on the first iteration, 4 bytes on the second iteration, etc... => total: about 1 Terabyte is copied!
-
Glaring misconception or a deliberate misguiding in the forum. String concatenations are always heavy. Always use either string.Format or StringBuilder. The compiler and runtime would love you for the kindness and friendliness.
Vasudevan Deepak Kumar Personal Homepage Tech Gossips
Vasudevan Deepak Kumar wrote:
String concatenations are always heavy. Always use either string.Format or StringBuilder.
This is a huge misconception/urban legend. See my posts above.
-
Glaring misconception or a deliberate misguiding in the forum. String concatenations are always heavy. Always use either string.Format or StringBuilder. The compiler and runtime would love you for the kindness and friendliness.
Vasudevan Deepak Kumar Personal Homepage Tech Gossips
Vasudevan Deepak Kumar wrote:
Glaring misconception or a deliberate misguiding in the forum.
No, you're mistaken.
Vasudevan Deepak Kumar wrote:
String concatenations are always heavy.
String concatenations to an existing string, yes. String concatenations to create a new string, no. My concatenation example boils down to a simple call string.Concat, which is many times more efficient than string.Format. String.Format has to spend time parsing the format string, converting the object parameters to strings, and then piecing all back into a new string. It's very inneficient compared to string.Concat.
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
-
Vasudevan Deepak Kumar wrote:
Glaring misconception or a deliberate misguiding in the forum.
No, you're mistaken.
Vasudevan Deepak Kumar wrote:
String concatenations are always heavy.
String concatenations to an existing string, yes. String concatenations to create a new string, no. My concatenation example boils down to a simple call string.Concat, which is many times more efficient than string.Format. String.Format has to spend time parsing the format string, converting the object parameters to strings, and then piecing all back into a new string. It's very inneficient compared to string.Concat.
Man is a marvelous curiosity ... he thinks he is the Creator's pet ... he even believes the Creator loves him; has a passion for him; sits up nights to admire him; yes and watch over him and keep him out of trouble. He prays to him and thinks He listens. Isn't it a quaint idea. - Mark Twain
Al Beback wrote:
converting the object parameters to strings
In Option2 you do that manually, but it still has to be done, and that time/effort still has to figure into your benchmarking. Plus there is (in my opinion) extra time spent maintaining each of those conversions.