No one can say languages are the same to me ever again!
-
ToddHileHoffer wrote:
So your post is pointless.
No - 'there is an option that is off by default that people who have no idea what they are doing should know to turn on' is not a viable position, IMO. Christian Graus - Microsoft MVP - C++
-
ToddHileHoffer wrote:
So your post is pointless.
No - 'there is an option that is off by default that people who have no idea what they are doing should know to turn on' is not a viable position, IMO. Christian Graus - Microsoft MVP - C++
Christian Graus wrote:
No - 'there is an option that is off by default that people who have no idea what they are doing should know to turn on' is not a viable position, IMO.
The very fact that it's off by default is a pointer to the intended target audience for that compiler. Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there! -
theRealCondor wrote:
there was an extensive amount of string concatenation using "a" + "b"
There's nothing wrong with that. This code:
string s = "a" + "b";gets compiled into:string s = "ab";and,string s = "a" + someString + "c";gets compiled into:string s = string.Concat("a", someString, "c");Alvaro
... since we've descended to name calling, I'm thinking you're about twenty pounds of troll droppings in a ten pound bag. - Vincent Reynolds
You should read some of the articles written by Microsoft and also use Reflector to see what things get compiled into. a+b+c gets compiled into exactly that, a+b+c. execution then creates a string object that represents a, creates a new object that represents a+b, creates a new object that represents a+b+c then assigns that instance to the value variable. String.Concat() is different and performs the above in a slightly more efficient fashion, but a+b+c never gets compiled into a String.Concat unless you explicitely code it that way. And you still end up with some additional objects. Now you put that into a loop that performs a+b+c 75 times and you have somewhere in the neighborhood of 250 objects flooding the gc heaps. And, I believe, that each of these objects must be Finalized() which adds further overhead to the GC operation. On the otherhand, if you perform that loop with StringBuilder and cast it to a string, then you create only 2 objects on the heap. There are 10 kinds of people in the world.
Those that read binary...
...and those who don't. -
Christian Graus wrote:
No - 'there is an option that is off by default that people who have no idea what they are doing should know to turn on' is not a viable position, IMO.
The very fact that it's off by default is a pointer to the intended target audience for that compiler. Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!Nishant Sivakumar wrote:
The very fact that it's off by default is a pointer to the intended target audience for that compiler.
Now Nish, you know there are no pointers in VB... :P Christian Graus - Microsoft MVP - C++
-
Nishant Sivakumar wrote:
The very fact that it's off by default is a pointer to the intended target audience for that compiler.
Now Nish, you know there are no pointers in VB... :P Christian Graus - Microsoft MVP - C++
LOL :laugh: There are 10 kinds of people in the world.
Those that read binary...
...and those who don't. -
theRealCondor wrote:
there was an extensive amount of string concatenation using "a" + "b"
There's nothing wrong with that. This code:
string s = "a" + "b";gets compiled into:string s = "ab";and,string s = "a" + someString + "c";gets compiled into:string s = string.Concat("a", someString, "c");Alvaro
... since we've descended to name calling, I'm thinking you're about twenty pounds of troll droppings in a ten pound bag. - Vincent Reynolds
I think you missed something - you're referring to compile time optimizations with string literals, whereas the OP is saying that all of the string concatenation is happening at runtime, all dynamically generated, so I doubt it would be able to do this, or at least not as effectively. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
-
You should read some of the articles written by Microsoft and also use Reflector to see what things get compiled into. a+b+c gets compiled into exactly that, a+b+c. execution then creates a string object that represents a, creates a new object that represents a+b, creates a new object that represents a+b+c then assigns that instance to the value variable. String.Concat() is different and performs the above in a slightly more efficient fashion, but a+b+c never gets compiled into a String.Concat unless you explicitely code it that way. And you still end up with some additional objects. Now you put that into a loop that performs a+b+c 75 times and you have somewhere in the neighborhood of 250 objects flooding the gc heaps. And, I believe, that each of these objects must be Finalized() which adds further overhead to the GC operation. On the otherhand, if you perform that loop with StringBuilder and cast it to a string, then you create only 2 objects on the heap. There are 10 kinds of people in the world.
Those that read binary...
...and those who don't.theRealCondor wrote:
You should read some of the articles written by Microsoft and also use Reflector to see what things get compiled into.
:wtf: You think I'm pulling what I said out of my ass? Evidently you're the one who needs to use Reflector. C#:
public void TESTING_STRINGS()
{
string s1 = "a" + "b";
string s2 = "a" + s1 + "c";
}IL:
.method public hidebysig instance void TESTING_STRINGS() cil managed
{
.maxstack 3
.locals init (
string text1,
string text2)
L_0000: ldstr "ab"
L_0005: stloc.0
L_0006: ldstr "a"
L_000b: ldloc.0
L_000c: ldstr "c"
L_0011: call string string::Concat(string, string, string)
L_0016: stloc.1
L_0017: ret
}Alvaro
... since we've descended to name calling, I'm thinking you're about twenty pounds of troll droppings in a ten pound bag. - Vincent Reynolds
-
You should read some of the articles written by Microsoft and also use Reflector to see what things get compiled into. a+b+c gets compiled into exactly that, a+b+c. execution then creates a string object that represents a, creates a new object that represents a+b, creates a new object that represents a+b+c then assigns that instance to the value variable. String.Concat() is different and performs the above in a slightly more efficient fashion, but a+b+c never gets compiled into a String.Concat unless you explicitely code it that way. And you still end up with some additional objects. Now you put that into a loop that performs a+b+c 75 times and you have somewhere in the neighborhood of 250 objects flooding the gc heaps. And, I believe, that each of these objects must be Finalized() which adds further overhead to the GC operation. On the otherhand, if you perform that loop with StringBuilder and cast it to a string, then you create only 2 objects on the heap. There are 10 kinds of people in the world.
Those that read binary...
...and those who don't.Reflector tries to decompile it into the original code as good as possible, that's why it translates string.Concat back to the + operator. Btw, strings don't have a finalizer. string.Concat is implemented as int num1 = (str0.Length + str1.Length) + str2.Length; string text1 = string.FastAllocateString(num1); string.FillStringChecked(text1, 0, str0); string.FillStringChecked(text1, str0.Length, str1); string.FillStringChecked(text1, str0.Length + str1.Length, str2); It just doesn't get any faster (that is, without using unsafe code to modify the string without having to call any methods). The StringBuilder would do a FastAllocateString with length 16. For each Append() call, it would check if the capacity is exceeded, if yes, the StringBuilder grows by allocating another string object and copying the content of the old one; then the new string is appended using the same code as FillStringChecked uses.
-
Nishant Sivakumar wrote:
The very fact that it's off by default is a pointer to the intended target audience for that compiler.
Now Nish, you know there are no pointers in VB... :P Christian Graus - Microsoft MVP - C++
Christian Graus wrote:
Now Nish, you know there are no pointers in VB...
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Moral Muscle The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
ToddHileHoffer wrote:
So your post is pointless.
No - 'there is an option that is off by default that people who have no idea what they are doing should know to turn on' is not a viable position, IMO. Christian Graus - Microsoft MVP - C++
Personally, I have switched to programming C#. I don't use vb.net unless I have too. However, my team in our IT department uses both languages (vb with option strict on of course) and one is not any better then the other just different. Honestly, any real programmer can use either language so what is the point of dogging vb.net all the time. It works for vb6 programmer who want to learn OOP. "People who never make mistakes, never do anything." My Blog
-
Christian Graus wrote:
Now Nish, you know there are no pointers in VB...
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Moral Muscle The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Well, perhaps there are. But what are the odds of any VB user actually using them ? :P Christian Graus - Microsoft MVP - C++
-
Personally, I have switched to programming C#. I don't use vb.net unless I have too. However, my team in our IT department uses both languages (vb with option strict on of course) and one is not any better then the other just different. Honestly, any real programmer can use either language so what is the point of dogging vb.net all the time. It works for vb6 programmer who want to learn OOP. "People who never make mistakes, never do anything." My Blog
ToddHileHoffer wrote:
one is not any better then the other just different
At the end of the day, this is kind of true. In fact, VB does some things I'd like to see in C#. However, it's true that it's easier to write bad code with VB, and that most beginners are encouraged to use VB. This is a bad combination, IMO. Christian Graus - Microsoft MVP - C++
-
theRealCondor wrote:
You should read some of the articles written by Microsoft and also use Reflector to see what things get compiled into.
:wtf: You think I'm pulling what I said out of my ass? Evidently you're the one who needs to use Reflector. C#:
public void TESTING_STRINGS()
{
string s1 = "a" + "b";
string s2 = "a" + s1 + "c";
}IL:
.method public hidebysig instance void TESTING_STRINGS() cil managed
{
.maxstack 3
.locals init (
string text1,
string text2)
L_0000: ldstr "ab"
L_0005: stloc.0
L_0006: ldstr "a"
L_000b: ldloc.0
L_000c: ldstr "c"
L_0011: call string string::Concat(string, string, string)
L_0016: stloc.1
L_0017: ret
}Alvaro
... since we've descended to name calling, I'm thinking you're about twenty pounds of troll droppings in a ten pound bag. - Vincent Reynolds
Well, I don't think you are pulling anything from anywhere. And I see no need for such violent talk. Now in comparison:
public void implement() { string s1 = "a" + "b"; string s2 = "a" + s1 + "c"; } public void doit() { string s1 = String.Concat("a", "b"); string s2 = String.Concat("a", s1, "c"); } public void longrun() { string s1 = "a" + "b"; s1 = s1 + "C" + "d"; s1 = s1 + "e" + "f"; }will generate the various results for IL
.method public hidebysig instance void implement() cil managed
{
.maxstack 3
.locals init (
string text1,
string text2)
L_0000: ldstr "ab"
L_0005: stloc.0
L_0006: ldstr "a"
L_000b: ldloc.0
L_000c: ldstr "c"
L_0011: call string string::Concat(string, string, string)
L_0016: stloc.1
L_0017: ret
}.method public hidebysig instance void doit() cil managed
{
.maxstack 3
.locals init (
string text1,
string text2)
L_0000: ldstr "a"
L_0005: ldstr "b"
L_000a: call string string::Concat(string, string)
L_000f: stloc.0
L_0010: ldstr "a"
L_0015: ldloc.0
L_0016: ldstr "c"
L_001b: call string string::Concat(string, string, string)
L_0020: stloc.1
L_0021: ret
}.method public hidebysig instance void longrun() cil managed
{
.maxstack 2
.locals init (
string text1)
L_0000: ldstr "ab"
L_0005: stloc.0
L_0006: ldloc.0
L_0007: ldstr "Cd"
L_000c: call string string::Concat(string, string)
L_0011: stloc.0
L_0012: ldloc.0
L_0013: ldstr "ef"
L_0018: call string string::Concat(string, string)
L_001d: stloc.0
L_001e: ret
}Now in the various examples a call into String.Concat() does occur. But not as frequently as if it was explicitly used. Which is probably why the performance papers state the string.Concat is slightly better performant then a+b+c. While the use of StringBuild results in the final list of code.
.method public hidebysig instance void better() cil managed
{
.maxstack 2
.locals init (
[mscorlib]System.Text.StringBuilder builder1)
L_0000: ldstr "a"
L_0005: newobj instance void [mscorlib]System.Text.StringBuilder::.ctor(string)
L_000a: stloc.0
L_000b: ldloc.0
L_000c: ldstr "b"
L_0011: -
...yes, Option Strict does a nice job. But the developer has to know it is there and then he/she has to go in and set it with each new solution. Most of these developers were either VB6 developers or COBOL coders sent in to learn a new language. So few if any knew this option existed and did not have the inquisitiveness to seek it out. And since it is off by default (a mistake on the VB teams side IMHO) it usually is overlooked until it is too late. And when you do finally turn it on, then VB has this nice way of spitting out a short list of errors and reporting: Maximum number of errors reached. At that point the error list stops as does any further compilation.
theRealCondor wrote:
And since it is off by default (a mistake on the VB teams side IMHO)
I agree. However, you can set it as a new project default. Though this doesn't work for my install of Visual Studio at work. (I'm currently working on a VB .NET project. ) For some reason the setting is not maintained, which is a pain in the butt. However, just tried it on my home VS 2003 and it works OK. Kevin
-
ToddHileHoffer wrote:
one is not any better then the other just different
At the end of the day, this is kind of true. In fact, VB does some things I'd like to see in C#. However, it's true that it's easier to write bad code with VB, and that most beginners are encouraged to use VB. This is a bad combination, IMO. Christian Graus - Microsoft MVP - C++
-
Well, I spend a lot of time on the Microsoft forums, which are flooded with newbies because of the express products. The overwhelming advice is, if you're learning, learn VB.NET. Christian Graus - Microsoft MVP - C++
-
And Microsoft even mentions that they *expressly* code their examples in VB.Net precisely to get at the widest audience, which I presume includes the newbies. And that has to have the effect of encouraging people to pick VB over say, C#. ¡El diablo está en mis pantalones! ¡Mire, mire! Real Mentats use only 100% pure, unfooled around with Sapho Juice(tm)! SELECT * FROM User WHERE Clue > 0 0 rows returned Save an Orange - Use the VCF!
-
Well, I don't think you are pulling anything from anywhere. And I see no need for such violent talk. Now in comparison:
public void implement() { string s1 = "a" + "b"; string s2 = "a" + s1 + "c"; } public void doit() { string s1 = String.Concat("a", "b"); string s2 = String.Concat("a", s1, "c"); } public void longrun() { string s1 = "a" + "b"; s1 = s1 + "C" + "d"; s1 = s1 + "e" + "f"; }will generate the various results for IL
.method public hidebysig instance void implement() cil managed
{
.maxstack 3
.locals init (
string text1,
string text2)
L_0000: ldstr "ab"
L_0005: stloc.0
L_0006: ldstr "a"
L_000b: ldloc.0
L_000c: ldstr "c"
L_0011: call string string::Concat(string, string, string)
L_0016: stloc.1
L_0017: ret
}.method public hidebysig instance void doit() cil managed
{
.maxstack 3
.locals init (
string text1,
string text2)
L_0000: ldstr "a"
L_0005: ldstr "b"
L_000a: call string string::Concat(string, string)
L_000f: stloc.0
L_0010: ldstr "a"
L_0015: ldloc.0
L_0016: ldstr "c"
L_001b: call string string::Concat(string, string, string)
L_0020: stloc.1
L_0021: ret
}.method public hidebysig instance void longrun() cil managed
{
.maxstack 2
.locals init (
string text1)
L_0000: ldstr "ab"
L_0005: stloc.0
L_0006: ldloc.0
L_0007: ldstr "Cd"
L_000c: call string string::Concat(string, string)
L_0011: stloc.0
L_0012: ldloc.0
L_0013: ldstr "ef"
L_0018: call string string::Concat(string, string)
L_001d: stloc.0
L_001e: ret
}Now in the various examples a call into String.Concat() does occur. But not as frequently as if it was explicitly used. Which is probably why the performance papers state the string.Concat is slightly better performant then a+b+c. While the use of StringBuild results in the final list of code.
.method public hidebysig instance void better() cil managed
{
.maxstack 2
.locals init (
[mscorlib]System.Text.StringBuilder builder1)
L_0000: ldstr "a"
L_0005: newobj instance void [mscorlib]System.Text.StringBuilder::.ctor(string)
L_000a: stloc.0
L_000b: ldloc.0
L_000c: ldstr "b"
L_0011:theRealCondor wrote:
Sorry if something I said upset you, that was definitely not my intent.
No problem. I just didn't appreciate you discarding what I said as if I had made it up. I did overreact and I'm sorry. Now, as far as the IL goes, your examples proved what I had said originally. The only thing you need to really watch out for is the += operator when called repeatedly (eg, inside a loop). The StringBuilder class is the way to go in that case. But the + operator is fine; as you saw, the compiler is great at optimizing it. Alvaro
... since we've descended to name calling, I'm thinking you're about twenty pounds of troll droppings in a ten pound bag. - Vincent Reynolds
-
Well, I spend a lot of time on the Microsoft forums, which are flooded with newbies because of the express products. The overwhelming advice is, if you're learning, learn VB.NET. Christian Graus - Microsoft MVP - C++
Interesting. Well, it is easier to get a program to run with the late binding and all so maybe that is why they do that. But it can and often does result in poor performance. Anyone getting paid to program should know not to program vb.net with option strict off. However, the original posters title "no one can say languages are the same" is what I consider silly vb.net bashing. They are similar if you know what you are doing. "People who never make mistakes, never do anything." My Blog
-
Interesting. Well, it is easier to get a program to run with the late binding and all so maybe that is why they do that. But it can and often does result in poor performance. Anyone getting paid to program should know not to program vb.net with option strict off. However, the original posters title "no one can say languages are the same" is what I consider silly vb.net bashing. They are similar if you know what you are doing. "People who never make mistakes, never do anything." My Blog
ToddHileHoffer wrote:
However, the original posters title "no one can say languages are the same" is what I consider silly vb.net bashing. They are similar if you know what you are doing.
They are similar, they are not the same. So, it's semantic. Christian Graus - Microsoft MVP - C++