|
Is there any conditional operator in VB.net like C++ "?:"
|
|
|
|
|
There is a legacy iif (inline if?) method that resides somewhere in Microsoft.VisualBasic namespace for this purpose. Usage is:
result = iif(condition, true part, false part)
But AFAIK this must be avoided since it is not a native ternary ( ?: ) operator in language, just a method.
Hüseyin
|
|
|
|
|
There are no native ternary operators in .Net. All the operators call hidden methods in IL therefore no human will every notice a performance difference using these conventions.
|
|
|
|
|
VB9 has an "If" operator, which behaves exactly like the C# conditional ternary operator.
David Anton
http://www.tangiblesoftwaresolutions.com
C++ to C# Converter
C++ to VB Converter
C++ to Java Converter
C++ to C++/CLI Converter
Instant C#: VB to C# converter
Instant VB: C# to VB converter
Instant C++: converts C# to C++/CLI and VB to C++/CLI
|
|
|
|
|
|
(Sigh) It appears that the MSDN-2 article is also sadly in need of a refresh. I just scanned it and found, for example, it gives no indication that VB 2005 supports XML comments with ' ' '
Oh well, I guess that's why they publish books. Or something.
|
|
|
|
|
The Code Project article is quite useful, but could stand some improvement. For example, it seems to suggest that Visual Basic 2005 doesn't support generics or nullable types, while C# 2005 does.
The following language-comparison link is from Microsoft's new MSDN-2 web documentation:
http://msdn2.microsoft.com/en-us/library/czz35az4(VS.80).aspx[^]
-- modified at 2:47 Friday 2nd February, 2007
|
|
|
|
|
|
|
The XML-Comment in VB.NET are three ' like this :
'''<summary>My Summary is written here</summary>
|
|
|
|
|
[Visual Basic]
Public Class MouseEventArgs
Inherits EventArgs
Dim x As Integer
Dim y As Integer
Public Sub New MouseEventArgs(x As Integer, y As Integer)
me.x = x
me.y = y
End Sub
Public Property X As Integer
Get
Return x
End Get
End Property
Public Property Y As Integer
Get
Return y
End Get
End Property
End Class
[C#]
public class MouseEventArgs : EventArgs
{
int x;
int y;
public MouseEventArgs(int x, int y)
{ this.x = x; this.y = y; }
public int X { get { return x; } }
public int Y { get { return y; } }
}
|
|
|
|
|
...but it doesn't have to take up as much vertical space as you represent:
Public Class MouseEventArgs : Inherits EventArgs
Dim x, y As Integer
Public Sub MouseEventArgs(ByVal x As Integer, ByVal y As Integer)
Me.x = x : Me.y = y
End Sub
Public Property X() As Integer
Get
Return X
End Get
End Property
Public Property Y() As Integer
Get
Return Y
End Get
End Property
End Class
|
|
|
|
|
Actually, sometime i find the End Sub, End Class and etc kinda informative although it is verbose.
Normally, I would find it useful when i have tons of curly braces and compiler complaining for extra or lacking few curly braces (in C#) which I could missed out by accident. Although the IDE will do a good job in highlighting the opening and closing of braces (by placing the cursor after the curly brace) but thing solve quicker with End XXX sometimes.
I even sometime come to an extend to comment my closing curly braces in C# to have something like
}//end foreach (.....
Anyway, this is just me.
Sonork 100.41263:Anthony_Yio
|
|
|
|
|
I was looking for an article which would give an in depth knowledge about difference betn VB.NET and C#
Your article comparision for VB.NET and C# is a single stop for almost everthing about them
Great Job. Keep it up
|
|
|
|
|
function a(){ if (x==5) { switch(b) { 1: if (a==1) { ... }}}}}
One line of code only!
|
|
|
|
|
well....
stupid ppl write codes that not many ppl understand.
smart ppl write codes that everybody can understand.
well again, unless you're working in your own little world, tht's fine =)
why force yourself writing codes that shouldn't be in one line only?
don't you think it's kinda messy and make reader reluctant to read?
wht's your intention?
Rgds,
ksboy
hello world!
|
|
|
|
|
<br />
[C#]<br />
function a()<br />
{<br />
<br />
if (x==5) <br />
{ <br />
switch(b) <br />
{ <br />
1: if (a==1) <br />
{ <br />
...<br />
}<br />
}<br />
}<br />
}<br />
<br />
[Visual Basic]<br />
Private Function a() As Object<br />
If x = 5 Then<br />
Select Case b<br />
Case 1<br />
...<br />
End Select<br />
End If<br />
End Function<br />
<br />
If you wanted to make a point, that was a bad example.
Writing code in one line has no benefit other than low disk space (and page space) usage
on source code.
Yet a similar example to this could present a disadvantage in VB.NET
Some cases VB.NET won't return values from a function or sub directly into
your working code, thus the need of declaring variables to temporarely store the values
returned.
(i remember i was programming one day and i thought, wow i could write this in c# with a lot
less lines of code and performance issues)
|
|
|
|
|
What is the point of writing all that stuff in one line?
I personally prefer it to be nicely formatted so one can tell what is going on, regardless of the language.
I remember back in College I had an idiotic professor who used to teach us Java and would make this very long lines of code in this manner. I was young and learning and even then I still thought it was stupid and wondered why would someone would want to do that to themselves?
Juan Romero
Sr. Web Developer
|
|
|
|
|
This article compares VB to C# and most of the VB programmers here tend to say that VB is equal to C#.
So, how would you write this C# code in VB in one line of code?
|
|
|
|
|
When we compare VB to C# we talk about capabilities. How can you make a case based on syntax?
You can write two hundred instructions in one line but the resulting MIL code is [almost] the same.
Performance wise there are only minor, neglegible differences. Please take a second to read Microsoft's white paper on VB vs C#. As they state it, the difference is a matter of taste. Salary also plays a big role as for some reason statistically, C# developers are better paid than VB developers, but that is beyond the scope of this article.
Juan Romero
Sr. Web Developer
|
|
|
|
|
I disagree. We do indeed talk here about capabilities of C# versus VB.
Imagine you had the choice of communicating with somebody by using one of two languages.
Imagine that in language B, you would need twice the amount of sounds as in language A to express the same concepts (such languages do exist...).
I am sure that you would immediately choose language A to communicate!
(in case you knew language A...)
You wouldn't want to make your life harder, would you?
C# versus VB has also to do with readability and concision: '}' (closing curly brace) versus Endif, End Sub, End Function, End Case, Next, End Loop, etc, etc, etc... without talking about Dim, Dim, Dim, Redim, Function, Sub and all the useless rest.
In C#, I can see more usefull lines of code as in VB in a given height of my screen, with no compromise over the readability.
C# does not restrict me as a programmer as much as VB does. For example like I mentioned in my previous message, with lines holding several small instructions.
Here is an other example:
Casing: VB would not allow you to write a variable camel cased and another variable Pascal cased.
C# lets you do it.
If you do not understand what I mean, try to compile this in VB:
Public Class Class1
Dim count As Long
Property Count() As Long
Get
Count = count
End Get
Set(ByVal value As Long)
count = value
End Set
End Property
End Class VB cannot compile this. It would not even let you type it without messing it all up.
In C#:
public class Class1 {
int count;
public int Count {
get { return count; }
set { count = value; }
}
} And before flaming me by saying this is all useless, you must first learn that camel and Pascal casing is a way of discriminating members from properties in curly-braces languages, in some companies. It definetely has its purpose.
And VB lacks it.
Forget about VB, and use C#, C# rocks!
|
|
|
|
|
My dear friend,
In terms of readability and concision, I actually find VB to be better. While I do concede that VB is more verbose, it is this very same thing that makes it more understandable to the naked eye.
While curly braces may be more convenient in terms of length, I find them more confusing to follow, and to prove it, I will use YOUR example:
function a(){ if (x==5) { switch(b) { 1: if (a==1) { ... }}}}}
Count the curly braces at the end and you will see that you are missing an opening brace. Nevermind that, if I ask you what the 3rd curly brace closes, can you tell me without going over the code? Chances are you can't. In fact, many C# developers do this:
} // End for
} // End if
Which amounts to the same thing as VB.
Another point I forgot to bring up on my last post is that the reason why you can do this sort of thing (multiple inline statements) in C# is because of the terminating character [;]. VB's terminating character is the line break, hence, the need for multiple lines or an underline (_) to denote multiple lines of code. The compiler needs to know where to break each line. Some people find it to be a good thing, some people don't. In any event, if you want to write multiple instructions in one line in VB, you can always use the [:]. Again, a matter of taste.
As far as being able to see more lines of code in the screen, unless you still use a dinosaur in 800x600 display mode, I don't see why this should be a problem.
In terms of coding style (notation), I also find the case sensitivity fact to be an inconvenience. On this topic I can gladly say I am not alone, as this is one of the biggest complaints I have heard from C background people. You can easily make a mistake while typing and use the other one instead, or things will not compile because you have made this mistake.
VB will not let you type it without messing it up because it shouldn't. It takes care of the casing for you, which helps maintain code readability and consistence.
I personally prefer to prefix member variables with "m_" and use Camel notation. This clearly defines the scope of the variables within a class and if I am not mistaken is part of Microsoft's recommended coding standards.
Finally, with over 7 years of experience, a Bachellor's Degree in Computer Science, experience in Basic, Fortran, Pascal, Cobol, Fox Pro, C++, VB.NET and C# (and others), and after having worked in multiple big corporations (8000+ employees) I can tell you with confidence that I understand the benefits and downfalls of each, not only at the language level, but also at the compiler level. Granted, C# does have some features that I would want, but in the end in my personal opinion VB.NET has become a first level programming language with more benefits that C#, even though most of these benefits come from the IDE rather than the language itself (again, they pretty much do the same thing). The 2.0 (and consequently VS.NET 2005) version leverages on a lot of things for both languages, specially on the IDE side. It makes life easier for C# developers (which were at a loss with intellisense among other things) and it adds some important features to both languages. I think the arguments are going to be better than ever with it!
Dynamic arrays is one topic we did not discuss here but I find it to be a BIG plus in VB.NET. I wonder if v2.0 has done anything about that for C# developers? To be honest, I don't know. I haven't updated my C# skills lately.
Once again, a matter of taste in my opinion. Which weapon you choose makes little if no difference as they both fire the same bullet. I recall reading an article on this same subject in which the header went something like this:
"Choose your flavor, .NET Coke vs .NET Pepsi"
Juan Romero
Sr. Web Developer
|
|
|
|
|
Marc Greiner wrote: public class Class1 { int count; public int Count { get { return count; } set { count = value; } }}
This violates more than one good programming convention but the most glaring is that using the same name for more than one variable/object is like tossing in a bunch of "goto" statements. It is not only bad form, hard to read, harder to troubleshoot, it's just plain bad, I.E: worse than useless, its dangerous.
You can camel/pascal case in VB, with the added benefit of it not allowing you to break several good programming rules in the process.
This reminds me of those developers who love to name all their variables "x" or "myvar" and then re-use those same names all through their code for vastly different things.
|
|
|
|
|
Hi Shakti,
Why would this violate any good convention ?
You certainly did not look at the Microsoft C# naming recommendations/conventions or many others.
"Count" is indeed not the same variable in C# than the variable "count" (notice the lower casing).
This is true in every programming language based on C (C++, java and the likes).
This characteristic is used to discriminate fields from properties in languages than can handle it.
This characteristic does not exist in VB since the very V. 1, and will most probably never.
Regards,
Marc
|
|
|
|
|
Simply because something can "handle" it does not mean it is good practice.
I am familiar with the naming conventions of many languages, but they do not condone the use of the same name for multiple disparate objects no matter what the casing is; actually they say to not do that explicitly.
Directly from the MSDN :
http://msdn2.microsoft.com/en-us/library/04xykw57(VS.71).aspx[^]
"
To avoid confusion and guarantee cross-language interoperation, follow these rules regarding the use of case sensitivity:
Do not use names that require case sensitivity. Components must be fully usable from both case-sensitive and case-insensitive languages. Case-insensitive languages cannot distinguish between two names within the same context that differ only by case. Therefore, you must avoid this situation in the components or classes that you create."
From the same MSDN page :
Do not create a function with parameter names that differ only by case. The following example is incorrect.
void MyFunction(string a, string A)
Also from the same MSDN page :
Do not create a type with property names that differ only by case. In the following example, int Color and int COLOR are inappropriate property names because they differ only by case.
int Color {get, set}
int COLOR {get, set}
The list goes on and on. There is just no good use/reason for disparate objects to be named the same, differing only by case. This is a troubleshooting/readability/style nightmare.
This is like vb.net allowing you to late-bind, or turn off "option strict" in the IDE. Just because you "can" dosent mean you "should".
|
|
|
|
|