|
emunews wrote: If And really is logical, that means that MS intentionally created a non-short-circuiting logical operator. I could be wrong, but I don't see any real reason to have a non-short-circuiting logical operator.
They did that *intentionally* for reverse compatibility with ole' VB6.
|
|
|
|
|
In:
If exp1 And exp2 Then
VB would always evaluate exp2, even if exp1 is false, which in this case does not change the result, right?
No doubt, C# does not behave like that, for obvious reasons. (Actually, C# would not even think of such an idea).
After several years, (the VB programmers needed up to VB version 7!), they found out that it was in most cases absolutelly silly to always evaluate exp2 when exp1 is false, and they 'discovered' a new operator: "AndAlso", and even a second operator: "OrElse". These would finally do the work properly, after 15 years or so of forcing every programmer of doing silly If's contructs.
Take an example:
C#:
if (Index >= 0 && Coordinate(Index) > 100) // Coordinate(Index) is evaluated only if Index >= 0.
{
...
}
VB:
If Index >= 0 Then
If Coordinate(Index) > 100 Then
...
Endif
Endif
I let you imagine yourself what the VB-code looks like if there are "Else"-cases and you do not understand what are "AndAlso" and "OrElse"...
You may say it is an irrelevant detail. Yes it is. But quality goes to the detail. So does C#, and not only in this case.
|
|
|
|
|
I found some inaccuracies.
A better comparison is found at
www.hardin.edu/USER/fmccown/www/vbnet_csharp_comparison.html
and the Microsoft whitepaper (Feb 11 2002) by May Ji
"Differences Between Microsoft Visual Basic .NET and Microsoft C# .NET
An excellent book is "The .NET Languages" by Brian Bischof
|
|
|
|
|
Great article!
I wish this were available when we started writing our VB.NET to C# and C# to VB.NET converters - one or two things you mentioned were learned the hard way!
By the way, you incorrectly stated that there wasn't an equivalent to the VB "Shadows". In C# you can use the keyword "new" in this context (as a method modifier) to produce the same effect.
Regards,
David Anton
Tangible Software Solutions
www.tangiblesoftwaresolutions.com
Home of the Instant C# VB.NET to C# Converter and the Instant VB C# to VB.NET Converter
|
|
|
|
|
beautifully written. concise. nice work.
SGarratt
|
|
|
|
|
|
In VB, it is impossible to pass an Array element ByRef to a function.
|
|
|
|
|
I'm pretty sure you can.
(Unless i have missunderstood you)
<br />
Dim a(2) As Integer<br />
<br />
Private Sub run_me()<br />
a(1) = 2<br />
a(2) = 4<br />
MsgBox(test(a(1)))<br />
End Sub<br />
<br />
Private Function test(ByRef b As Integer) As Boolean<br />
Return b + 3 = 5<br />
End Function<br />
|
|
|
|
|
FYI
VB.Net will include the using statement in Whidbey for allocating resources (like C#).
|
|
|
|
|
Is it true that when VB evaluates an If condition, it evaluates all the expressions of the instruction before to decide whether the condition is true or false?
Effectively, VB6 does it so.
Example:
<br />
If iRow >= 0 Then<br />
If vntName(iRow) = "John" Then<br />
DoSomething()<br />
Endif<br />
Endif<br />
In VB, this test has to be done in two times, or else the second test crashes when iRow < 0, although the first test is false:
<br />
If iRow >= 0 And vntName(iRow) = "John" Then<br />
DoSomething()<br />
Endif<br />
The upper code does not function when iRow < 0 (Index out of bound Error).
In C#, it would be writen like this:
<br />
If (iRow >= 0 && vntName(iRow) == "John")<br />
DoSomething();<br />
In C#, as soon as the condition cannot be true (evaluated from left to right), the program stops evaluating the condition. Efficient, concice, sharp.
This is how several programing languages behave (C, C++, Java), and shows that the language was thoughtful and well designed.
You'd say, that's not a big deal. Then, I'm sorry to tell you to go back and program the Else case...
Let's think of the Else-Case:
The poor VB-programmer (I am currently one of those, and I find it so painfull to program in VB since C# exists) must program something like this to achieve the same in C#:
<br />
If iRow >= 0 Then<br />
If vntName(iRow) = "John" Then<br />
DoSomething()<br />
Else<br />
DoSomethingElse()<br />
Endif<br />
Else<br />
DoSomethingElse()<br />
Endif<br />
The C#-Programmer programs elegantly and easthetically the following:
<br />
If (iRow >= 0 && vntName(iRow) == "John")<br />
DoSomething();<br />
else<br />
DoSomethingElse();<br />
which works perfectly, and is far more readable than the VB counterpart.
If anyone has an idea of how to get the same efficiency in VB, please tell me how, because these cases (and others) upset me each time I think of it, because I am a poor VB programer, still for the time beeing.
There are some more of those VB-annoyances, which I consider as beeing VB-language conceptual mistakes.
When it became available in 2000, I read the C# language specifications from A to Z (downloadable by Microsoft), like a roman. It was delightfull, refreshing and restored my hope over the conceptual mistakes, often taken from the burden of the compatibility. It showed me that there will be a better future in the programing.
|
|
|
|
|
If iRow >= 0 AndAlso vntName(iRow) = "John" Then
DoSomething()
Else
DoSomethingElse()
End If
Problem solved...
|
|
|
|
|
Thanks for your tip, Cory.
Its exactly the keyword that is missing in all previous versions of VB, (and also in the VB.NET help under "If Then Else"...).
|
|
|
|
|
And if you want to make it even more shorter (as a former C programmer I used to do):
IF cond1 ANDALSO cond2 THEN DoSomething() ELSE DoSomethingElse()
All in a single line.
Briga
|
|
|
|
|
Excellent comment as this article proves just a single point: vb and c# are essentially the same languages, exposing the power of a common platform thru a different syntax.
The political debate as to which language is the 'best', is more often than not discussed among naive people with rather limited horizons.
|
|
|
|
|
You can also use the OrElse keyword.
Tomer Pintel
|
|
|
|
|
I think you might be interested in checking out VB's short-circuit boolean operators, namely AndAlso and OrElse. They allow the same type of logic you are refering to.;)
|
|
|
|
|
Is it still so in VB.NET that you cannot have an instruction span over several lines without having to add this horrible "_" character at the end of every line?
If this is still the case, forget about VB (Net or not).
|
|
|
|
|
As far as I know yes.
Briga
|
|
|
|
|
In case of a multi-line instruction, how could I add a comment at the end of each line?
In all previous versions of VB, this is totally impossible but absolutelly no problem in any other C, C++, Java, C#, etc. language.
I would like to be able to do so in case, for example, where I have a function call with several parameters, and some of them need a small comment at the end:
Public Sub ActualizePersInfo(ByVal strPersID As String, _<br />
ByVal datFrom As Date, _ 'Some comment. Impossible here...<br />
ByVal datTo As Date, _<br />
ByVal blnIsImportant As Boolean)
|
|
|
|
|
I don't like such commenting (at the end/middle of the parameters) Use good parameter names that explains itself. Do refactoring. Spend some time to do this and for good names when naming params, vars, methods and classes et.al.
...Ashok
|
|
|
|
|
This thread is about how C# (and C, C++, Java and the like) easily allows multi-line instructions + commenting in between, and not necessarily commenting at the end of the line (which both VB cannot do).
I have met several cases where it would have been usefull for me to be able to put a short comment at the end of a multi-line instruction and I could not do it. I am not speaking of comments regularily put at the end of the line, which I do also dislike, as you do.
|
|
|
|
|
Yes, but you dont have to write the ";"
|
|
|
|
|
Unfortunately, yes, and I see absolutely no reason for it.
Before anyone argues that because VB.NET doesn't have block containers, the compiler couldn't figure out when a line is continued without the "_" token, I beg to differ.
Python has a similar "by-line" syntax (like VB) rather than a "by-statement" syntax (like C#), and it allows line continuations. For example, Python allows this:
<br />
def someFunction(arg1,<br />
arg2,<br />
arg3):<br />
print "I do nothing"<br />
|
|
|
|
|
Is it still so in C# that if you have an instruction that spans a single line you need to indicate this by a semicolon?
Honestly, on average if I code 100 lines of code roughly 5 lines span over more than one line.
So in C# I need 95 semicolons, in VB I need 5 underscores.
I'm not saying that VB's technique is better, but to suggest it is worse sounds a bit silly to me.
Eric Roosendaal
VB and C# instructor
|
|
|
|
|
Let me explain myself a bit more, for you to understand the problem:
In VB, have you ever tried to type something at the right side of an "_" ?
In fact, it is totally impossible (please, read my second (under-) message in this topic, about comments in code).
The semicolon ";" in all C-based languages (C#, C++, Java, etc.) solves syntatically elegantly two functions:
1) In C#: Long lines instructions can be cut in as many bits as necessary, without any special character or formating. I can also add comments wherever I want.
This is in some cases hard to achieve elegantly in VB: The number of lines per instruction is limited (VB6: limit = 15 lines). Comments: impossible (not even one).
I could almost hear you: 15 lines of code for one instruction, this is not good programming.
Sorry, but have you ever, for example, build a dynamic SQL command? I am sure you have.
That's where I reached the VB-limit for the first time...
Indeed, some SQLs can be very long, and for the sake of readability, it is so good to be able to dispatch then on several lines.
2) In C#: Several short instructions can be put on one line.
VB can do that, with the help of another character: ":"
By the way, why do differently from all the others and take ":" instead of ";"?.
But with ":", the editor performs some special formating, which is not always welcomed... (characters get lost/eaten, for example).
And if you start mixing "_" and ":", you might get into some strange editor problems... (VB6 at least, as for VB.Net, I hope to never have to figure out...).
Actually, what is disturbing in VB is that the line-ending is implicit.
Would you imagine a book author writing a book without "." to delimit sentences? No!
As for the verbose point:
If you really want to count the characters needed to programm and compare which of VB and C# are less verbose, let's go and start it!
How many times did you type the "Dim" keyword in C#? None indeed.
And what about those other VB exclusiv and useless "reserved words" over which my eyes constantly need to pass over, to try understand this silly programm I need to maintain :
- Function
- Sub
- End Function
- End Sub
- Call Sub()
- Dim, Dim, Dim, Dim (and the light goes off).
- As, As, As, As...
- Let
- Set
- Property
- And / Not / Or (not to mention the silly logic of them!)
- Nothing, Empty
- EndIf ElseIf
- Do Loop While Whend (at least one or two of them do not bring anything).
- Have I forgoten one of them?
Conclusion:
VB didn't bring anything by introducing the "_" to work-around long lines of code.
|
|
|
|
|