No one can say languages are the same to me ever again!
-
Option Strict '--8<------------------------ Ex Datis: Duncan Jones Merrion Computing Ltd
...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.
-
I just finished a grueling 15 system code review. Sheesh. But interesting of all is that there was quite a mix of VB.NET as well as C#.NET. There were two things that caught my eye in these reviews right away: 1) when the developer got a row from the database but did no casting whatsoever (to populate a string field) VB.NET compiled the code without complaint. It then resulted in IL that called GetValueFromObject that then was passed into StrObj.StringFromObject. 2) when a developer accessed a method inside a dll that was referenced but no using statement given, VB.NET compiled the code without complaint. The IL it puked out was LateBinding creation of the object and LateBindingCall into the method. ...and the reason for all of this review was to find out why the applications are running so slow. In looking at the IL from the C# code, not once did I have a cast from object or a late binding call in any of the code. Simply because C# would not allow these common faux paxs to occur. So no one could ever tell me that VB.NET generates exactly the same IL as C# does. Now----> before anyone begins the counters ---> a well written VB.NET program (I did encounter 1) will generate the same code in C# as in VB.NET. As long as the developer is not lazy, checks the object types he/she is working with, and makes certain to always add a Imports statements every time a reference is added. Also -- some of the C# code was not all that pretty and there was an extensive amount of string concatenation using "a" + "b" + ... as well as excessive object casting and creation. But that just shows a bad developer can write bad code in either language. But I now understand what one Microsoft engineer (off the record) meant when he stated that 'even a good developer can easily write bad code in VB.NET'. -- modified at 13:48 Wednesday 15th March, 2006
Heh. A while back, we ended up using two different wrappers for MSXML in our software, one generated by the VC6 wizard, the other generated at compile-time via the
#importextension. Fundamental difference? The VC6-generated wrapper did everything through IDispatch. Guess which one performed significantly better when callingsetAttribute()in a tight loop... ;) Moral of the story? If you don't know what your program is really doing, you're gonna have a hard time making it do what it needs to do faster.---- Scripts i've known... CPhog 0.9.9 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.1 - printer-friendly forums
-
theRealCondor wrote:
The IL it puked out was LateBinding creation of the object and LateBindingCall into the method.
You mean it used Reflection? Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
The Ultimate Grid - The #1 MFC grid out there!Well....I did not expand the logic that is inside Microsoft.VisualBasic.dll ...but it actually creates a call to LateBind(object name) and LatBindingCall(latebound object, object method name) It did not directly use Reflection. In fact within several of the functions like GetStringFromObject the Microsoft.VisualBasic.dll logic does not do a straightforward obj.ToString() call. Instead it does about a 15 statement switch statement based on the objects type. -- modified at 14:01 Wednesday 15th March, 2006
-
theRealCondor wrote:
The IL it puked out was LateBinding creation of the object and LateBindingCall into the method.
You mean it used Reflection? 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:
?
Yes, if you forget to specify the type of a variable in VB, every member access on it will use Reflection.
-
Heh. A while back, we ended up using two different wrappers for MSXML in our software, one generated by the VC6 wizard, the other generated at compile-time via the
#importextension. Fundamental difference? The VC6-generated wrapper did everything through IDispatch. Guess which one performed significantly better when callingsetAttribute()in a tight loop... ;) Moral of the story? If you don't know what your program is really doing, you're gonna have a hard time making it do what it needs to do faster.---- Scripts i've known... CPhog 0.9.9 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.1 - printer-friendly forums
Yup, in total agreement here. That is why I chose to evaluate all programs by using Reflector against the IL instead of reviewing the developers' straight source. (though I reviewed that as well) I wanted to make sure I reviewed all systems based upon what is being done under the covers rather than what was visually happening.
-
I just finished a grueling 15 system code review. Sheesh. But interesting of all is that there was quite a mix of VB.NET as well as C#.NET. There were two things that caught my eye in these reviews right away: 1) when the developer got a row from the database but did no casting whatsoever (to populate a string field) VB.NET compiled the code without complaint. It then resulted in IL that called GetValueFromObject that then was passed into StrObj.StringFromObject. 2) when a developer accessed a method inside a dll that was referenced but no using statement given, VB.NET compiled the code without complaint. The IL it puked out was LateBinding creation of the object and LateBindingCall into the method. ...and the reason for all of this review was to find out why the applications are running so slow. In looking at the IL from the C# code, not once did I have a cast from object or a late binding call in any of the code. Simply because C# would not allow these common faux paxs to occur. So no one could ever tell me that VB.NET generates exactly the same IL as C# does. Now----> before anyone begins the counters ---> a well written VB.NET program (I did encounter 1) will generate the same code in C# as in VB.NET. As long as the developer is not lazy, checks the object types he/she is working with, and makes certain to always add a Imports statements every time a reference is added. Also -- some of the C# code was not all that pretty and there was an extensive amount of string concatenation using "a" + "b" + ... as well as excessive object casting and creation. But that just shows a bad developer can write bad code in either language. But I now understand what one Microsoft engineer (off the record) meant when he stated that 'even a good developer can easily write bad code in VB.NET'. -- modified at 13:48 Wednesday 15th March, 2006
-
I just finished a grueling 15 system code review. Sheesh. But interesting of all is that there was quite a mix of VB.NET as well as C#.NET. There were two things that caught my eye in these reviews right away: 1) when the developer got a row from the database but did no casting whatsoever (to populate a string field) VB.NET compiled the code without complaint. It then resulted in IL that called GetValueFromObject that then was passed into StrObj.StringFromObject. 2) when a developer accessed a method inside a dll that was referenced but no using statement given, VB.NET compiled the code without complaint. The IL it puked out was LateBinding creation of the object and LateBindingCall into the method. ...and the reason for all of this review was to find out why the applications are running so slow. In looking at the IL from the C# code, not once did I have a cast from object or a late binding call in any of the code. Simply because C# would not allow these common faux paxs to occur. So no one could ever tell me that VB.NET generates exactly the same IL as C# does. Now----> before anyone begins the counters ---> a well written VB.NET program (I did encounter 1) will generate the same code in C# as in VB.NET. As long as the developer is not lazy, checks the object types he/she is working with, and makes certain to always add a Imports statements every time a reference is added. Also -- some of the C# code was not all that pretty and there was an extensive amount of string concatenation using "a" + "b" + ... as well as excessive object casting and creation. But that just shows a bad developer can write bad code in either language. But I now understand what one Microsoft engineer (off the record) meant when he stated that 'even a good developer can easily write bad code in VB.NET'. -- modified at 13:48 Wednesday 15th March, 2006
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
-
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: