No one can say languages are the same to me ever again!
-
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: -
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++
-
...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
-
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++
-
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.