|
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.
|
|
|
|
|
I personally like both VB and C#
In C# if you have a block of code like this one:
function a()
{
if (x==5)
{
switch(b)
{
1:
if (a==1)
{
...
}
}
}
}
}
In VB it would look like
Function a()
If x=5
Select Case b
Case 1
If a=1 then
Endif
End Select
End If
End Function
Placing a line place in the wrong block is less likely as each block is clearly named.
Also, the VB syntax is slightly more robust as it syntaxically check what the block us.
Finally, the vb code is more compact, I personally don't think that lines containing a single character { add any meaning
|
|
|
|
|
How would I type this in VB?
function a(){ if (x==5) { switch(b) { 1: if (a==1) { ... }}}}}
One line of code only! Freedom of C#. No chains and limits of VB-scripting dialect syntax.
|
|
|
|
|
Test for an object variable that does not refer to an object:
The correct VB.Net syntax is
obj Is Nothing
|
|
|
|
|
"The VB.NET parts of Visual Studio .NET compiles your code in the background."
Is it possible to turn this off?
|
|
|
|
|
No... This is part of what makes VB, well, VB.
|
|
|
|
|
I came across one C#/VB.NET difference that actually became cricial for the project.
Being close to its predecessor, VB.NET allows you to
create (COM) objects even if you do not have a COM wrapper.
In short, I had to send an e-mail from C# code using CDO, and
I could not use either CDO itself or its type library.
VB.NET allows you to
iMsg = CreateObject("CDO.Message")
iConf = CreateObject("CDO.Configuration")
and, more importantly, does not object when you call methods
on these objects, which are - here is the trick - unknown to the
compiler, like:
Flds = iConf.Fields
' set the CDOSYS configuration fields
With Flds
.Item("...") = cdoSendUsingPort
' . . . <whatever is necessary>
.Update()
End With
and (assuming that strings ToWhom, From, Subject and strHTML are
filled in properly):
With iMsg
.Configuration = iConf
.To = ToWhom
.From = From
.Subject = Subject
.HTMLBody = strHTML
.Send()
End With
The point is that VB, as opposed to C#, did not require
CDOSYS.dll's RCW (run-time callable wrapper) and accepted
iMsg.Subject and others happily.
One may consider this as a drawback (type safety is the victim)
or a plus (feel free to program whatever you want as long as
you know what you are doing), I let the readers decide for
themselves.
|
|
|
|
|
For what it's worth, you can still late binding in C#, you just have to use reflection. Things can be made a bit simpler by using the Microsoft.VisualBasic reference from C#. I saw a blog post on this: http://swigartconsulting.blogs.com/tech_blender/2005/03/c_late_binding.html
Nonetheless, it's still a lot easier to do in VB.
|
|
|
|
|