No one can say languages are the same to me ever again!
-
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++
-
Well, perhaps there are. But what are the odds of any VB user actually using them ? :P Christian Graus - Microsoft MVP - C++
-
-
They probably depend a lot on whether you're CG or not... ;)
Now taking suggestions for the next release of CPhog...
Yep - I was going to say 'read my image processing articles to find out' ... 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++
And the 'Groaner of the Day' award goes to... cheers, Chris Maunder
CodeProject.com : C++ MVP
-
If you're developing using Compact Framework (1.0, haven't checked 2.0 very thoroughly yet) and you need to P/Invoke something even vaguely complex, you need to know your way around
unsafecode,fixedbuffers, and pointers. 'Complex' in this context means structures containing strings or pointers to strings. Do it the same way you would on the desktop and you just get aNotSupportedException. The Compact Framework 1.0 marshaller is very weak. Stability. What an interesting concept. -- Chris Maunder -
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
-
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
There is two things that I find slightly annoying with vb... 1) can't customize for loop much 2) methods that return a value create a variable for it automatically I suspect that #2 will be resolved soon, and the for loop in vb is actually advantageous over the cish one in some cases. Most cases its fine, but in others you have to implement a little work-around with while loops. (not as icky as some java work-arounds during debugging ;P) Anyway, basing your argument on disliking an option isn't too good... I personally can't stand implicit code... and I like verbosity. As such, my default language of choice is vb ;P The fact of it being off is possibly because its Visual Beginner's All-Purpose Symbollic Instruction Code? As in, its configured by default for ease of use for people learning, and more advanced users can manipulate the options to fit them better :rolleyes: Options are good. What you do with them is what makes the difference ;) One should not attempt to counter bias with counter-bias. Countering bias with bias does not cancel out the bias, but increase it.