There are some fairly big differences although they are not huge.
example: VB.NET will not let you reimplement an interface ... C# will this
is important when dealing with serialization of certain classes (namely
datatables). There are a ton of other things but here is a partial list.
C# has pointer operations
VB is case insensitive. In C# MyA and myA are differnt variables
VB supportd late binding and optional parameters, C# does not
C# doesn't support optional paramters
------------------------------------------------------------
VB supports automatic variable conversion between types (you can assign Long
to Integer without conversion)
VB has richer IntelliSense and better automatic formatting
VB better supports compilation while you type.If you misspelled keyword and
move to another line
the error will appear in the Task List.
=============== =============== =============== ===
Productivity
============
- C# is as equally suited to application program development as VB.NET
- Productivity between the two languages is comparable
- Execution speed of programs written in both languages is comparable
- VB offers improved as-you-type checking, but inferior compile-time
checking (relying on runtime checks instead)
- Both languages have advanced Intellisense features (resolving case
issues in C#) with the VB Intellisense being slightly more advanced
for Booleans and Enums
- Comparable statements can be up to 266% shorter in C# - with or
without Intellisense
Ease of use
===========
- C# has half the number of reserved words to learn
- Both languages have identical class, method, and function names (the
Framework)
- To be used properly, both languages require knowledge of object
orientation, event driven programming, and exception handling
- Both languages are not immediately accessible to non-programmers
Technology
==========
- C# is fully object orientated, ie 'int.Parse(x)' whereas VB uses
some legacy non-OO function calls
- VB supports as-you-run modifications
- C# supports XML commenting
- C# is supported by other platforms (Borland C#Builder, and 'Mono' on
Linux
http://www.go-mono.com)
Knowledge-reuse
===============
- Knowledge of VB is useful for programming Office and VBScript
- Knowledge of C# is useful for programming Javascript, Jscript, PHP,
Perl, Java, C and C++ (currently the dominant language for native-code
development on both Windows and non-windows platforms)
from Marco Bellinaso article
What C# has that Vb does not
=============== ============
1.Unsafe code:
with C# you can write blocks of unsafe code, that is,
code that can use pointers and directly access memory, use low level
system calls and do the sort of things that are not verified by the CLR.
Use of this feature should be avoided to limit the possibilities of
runtime errors, but it may turn out to be an important feature when
writing code for algorithms that must have good performance, or need to
interface with the operating system (of course, operating system
portability would be lost by doing so).
2. Operator overloading:
C# allows the developer to define a custom
implementation for many mathematical, unary, binary and comparison
operators that a class may support, such as +, -, *, /, true, false, ==,
!=, >>, <<, !, ~. For example, say that you have a class Matrix: you
can redefine the meaning of the + operator for this class, so that if
you have three instances of Matrix - m1, m2 and m3 - you can do m3 = m1
+ m2;. While this is certainly a very cool feature, you must be aware
that if you later use the Matrix class from a VB.NET client, you won't
be able to use the overloaded + operator to sum two matrixes, since the
operator overloading feature is not part of the CLS. If you're 100% sure
that all your code will be in C#, good, you can safely overload the
operators and assign them the meaning you want. Otherwise, you should
provide instance or static methods such as Add, Subtract etc., so that
all the possible operations are accessible to VB.NET too.
3. XML documentation: (Whidbey will have it)
in C# code comments can be added in XML-like
format--with a /// prefix instead of the usual single-line // comment
prefix--within tags such as <summary>, <para>, <returns> and so on. At
compile time you can specify to extract all the XML comments and save
them to an XML file, so that it will be easy to write a XSL
transformation file to create HTML documentation. If you program with
Visual Studio .NET, under the Tools menu you find a Build Comment Web
Pages item, that generates the help files without requiring you to
manually write a XSL file and leave the IDE. Once the developer gets
used to writing their comments between these tags, they will soon
realize that they already have good documentation of their classes,
separated from the source code and thus easier to read and consult. This
powerful and helpful feature unfortunately is not present in VB.NET.
Hopefully it will be added in a future release, but I'm pretty sure
someone will soon provide an add-in to support this feature in any
language, if it doesn't already exist.
4. Unsigned integers:
the uint, ulong and ushort data types. Unsigned
integers may be useful in some situations, when you want to handle just
positive values, but I wouldn't say it's a vital feature. Also, as for
the operator overloading, unsigned integers are not part of the CLS, so
if you define a method that requires an argument of this type, you won't
be able to call it from VB.NET. You can safely use them within the
method's body though, without compromising the compatibility with other
languages, the important thing is just that they are not exposes in
public methods' signatures.
5. The using statement:
defines a block of validity for an object
variable. As soon as the execution goes outside this block the object is
destroyed and disposed. This is good when the developer uses limited
resources, and wants to free them as soon as possible.
6 The checked and unchecked statements:
specify whether the expressions
and constants within the defined blocks raise compile-time errors or
runtime exceptions in case of an overflow.
7 The ? : conditional operator:
this is a ternary operator, used in the
form of op1 ? op2 : op3, that evaluates and returns the result of the
second operand if the evaluation of the first operand returned true,
while evaluates and returns the result of the third operand otherwise.
This is really useful when you want to return a value or set a variable
with a different value according to some condition. In VB6 you have the
IIf operator that does the same--in VB.NET the IIf operator is still
available, but only in the Visual Basic compatibility assembly, so it's
not really part of the language itself or the framework library, and its
use should be avoided. Personally, this is something I'd be very glad
to have built-in in the VB.NET language, I miss it when I program with
VB.NET!
8. The ++ and -- operators:
these operators increment or decrement a
variable by one. For example, instead of writing x += 1 (the += is
supported by both C# and VB.NET) you can write x++. While they may be a
little bit clearer to use the more verbose syntax in single statements,
they are particularly handy to use in for blocks to increment/decrement
the index variable.
9 add/remove accessors and the EventHandlerLis t class:
just like the
get/set accessors for properties, C# also has the add/remove accessors
for events. As you can easily guess, they are used to add fine-grained
control to the addition/removal of event listeners. You can use them in
conjunction with the EventHandlerLis t class, that represents a list of
key/value pairs, where the key is an object that identifies an event,
and the value is a delegate. This class in often used in components and
controls that expose a lot of events, because they avoid having an event
member for each class event, thus making a more efficient use of memory.
There is no VB.NET counterpart to the add/remove accessors, so the
EventHandlerLis t class is of little use in VB.NET. This is a significant
defect if you are a class/component/controls developer.
10. Non-serializable events:
when you serialize an object (an instance of
a class marked by the Serializable attribute) you'll also serialize all
the objects that are references. If your class exposes events, this is
a problem, because its listener objects are actually referenced by the
object (since the events are implemented through delegates), and thus
the serialization mechanist tries to serialize them as well! If the
listener is a serializable class you'll "simply" end up serializing more
objects than you really want, but if the listener is a Windows Form you'll
get no less than a runtime exception, because forms aren't serializable.
C# has a very elegant way to solve the problem: you just need to apply
a [field: NonSerialized()] attribute to the event declaration, and the
event will not be serialized. Unfortunately, VB.NET does not support the
"field" target for the NonSerialized attribute. Check out the article
at
http://archive.devx.com/devxpress/gu...X8968461X94458 for more
information and a couple of proposed workarounds for VB.NET.
11. C# has been submitted to the ECMA committee to become a standard.
This also means that
other vendors will be able to develop and sell their own compilers and
IDEs for C#, while
this won't be possible with VB.NET, as it is Microsoft-proprietary. If
the .NET Framework
will ever be successfully ported to other operating systems
=============== =============== =============== =====
What VB.NET Does Have That C# Doesn't
1. As in VB6, with VB.NET you can still use the CreateObject function to
create an object
instance of a class defined in a COM component with late binding. In C#
instead, you necessarily need to create a .NET wrapper assembly and
reference it, or
use reflection to access the wrapper assembly if you want some sort of late
binding. It is
of course much easier in VB.NET, even though you should avoid the
CreateObject function
if you want to write code can than be easily translated to other
..NET-compliant languages.
2. If in C# you want to handle events raised by some objects, you
necessarily need to use
delegates to programmaticall y and explicitly associate a custom method
to the class instance, and say that that's the event handler procedure for
some
method. This technique is possible in VB.NET too, but VB.NET also allows you
to declare object
variables with the WithEvents keyword, that hides the use of delegation to
associate a
custom method to the object instance, and instead allows to write a method
and directly
associate it to the proper object instance by means of the Handles keyword,
that specify the
event that the procedure handles. This really makes it faster to write code
to handle
events, especially if you use Visual Studio .NET because it lets you select
the event name
from a drop-down list, and autogenerates the required code.
3. VB.NET supports optional arguments, with a default value if they are
not passed to the method. While this may be useful at times, this is not a
CLS-compliant
feature, and C# clients won't be able to take advantage of the default value
for the
optional arguments and will always need to pass all the arguments. If you
think there is
the possibility that your classes will be called by C# clients the best
practice is writing
overloaded versions of the same methods, with a different number of
parameters, to simulate
optional parameters. Here's an example, instead of writing:
Public Sub DoSomething(Opt ional ByVal arg As Integer = -1)
' ...
End Sub
You can write these two overloads for the DoSomething method:
[Overloads] Public Sub DoSomething(ByV al arg As Integer)
' ...
End Sub
[Overloads] Public Sub DoSomething()
' call the version that takes one argument, and pass in the default
value
DoSomething(-1)
End Sub
Overloads is between square brackets in the code above because it's
optional, but if you use it in one declaration, then you must use it in the
other overloaded
versions as well. This way, C# clients will also be able to call the
overloaded method
with a variable number of arguments.
However, there is one case in which this feature is very, very handy--when
you use COM Interop to access COM components that expose a lot of methods
with
optional parameters.
If you do a lot of add-in programming, this point might be enough to make
you choose VB.NET!
In addition, note that you can't write VS.NET macros in C# as you do with
VB.NET, and
this makes it much more difficult to run and test snippets of code--you
have to
compile the full add-in and debug it. Alternately, if you want to test a
piece of VB.NET code,
you can just extract and save it as a macro and run it. Try to compile,
register and
run everything dozens of times just to find and fix one bug in a routine,
and you'll
really appreciate what VB.NET offers in the add-ins development field!
4. VB.NET's With...End With block executes a set of statements on the
defined object. Practically, if you're settings a lot of properties or
calling a lot of
methods of the same object, you declare a With block for that object, and
within the
block you access its members without writing the object name, but only with
a dot (.) prefix.
This is a nice feature that can make your code lines a bit shorter and
faster to write.
You'll also have is a slight performance benefit, because when you use the
With syntax
you have a temporary reference to the bottom-level object which can speed
things up.
5. VB.NET still supports modules (defined within a ModuleEnd Module
block, and not identified by a .bas file as in all the previous releases of
VB) to
define application-level variables and global routines/functions. C# doesn't
support modules, but you can do the same with static class members. In
VB.NET you have both
options, but modules are good because the caller code doesn't need to prefix
the
procedure name with the module name, as it must do with a static class's
members instead. C#
callers will see the module as a class with static members (at a lower
level modules are
implemented that way, in fact), so the compatibility is fully preserved.
6. VB.NET's ReDim statement allows you to change the dimension of an
existing array and to maintain the current values. This is not directly
possible with C#--you
should create a new array with the new size and then copy the values from
the old array
to the new instance. Or you could use an ArrayList and when you're done
adding
elements you can use its ToArray method to get a real array.
7. VB.NET's Select statement is more flexible than C#'s switch statement,
in that it allows you to specify intervals of values (Case 1 To 50) or
other
conditions (Case Is >10), while C# only allows you to use simple constants
(you have to use
the if statement if you need more flexible conditions). C#'s case blocks
must also end with
an explicit break statement.
8. VB.NET's Catch statement of a Try...Catch...F inally block is more
flexible than the C#'s counterpart, in that it allows you to specify a
further condition
that must be met to have the exception being handled by that Catch block.
For example, you
can have something like the following in VB.NET:
9. VB.NET fully supports the structured exception handling, like C#, it
is even more flexible as explained in the previous point. However, it also
still
supports the infamous On Error statement. Although it has a bad reputation,
it may actually be
useful in certain situations, when you need to resume the execution after
the statement
that caused the exception, and not just after all the statements of a
Try...Catch...F inally
block. This is not to suggest using the On Error option, structured
exception handling
is a better solution (in terms of performance as well) in many cases, just
not
always. The choice is always yours, and personally I like to have one more
option than one less.
10. VB.NET has the ^ operator to do operations with exponents, while C#
doesn't have a counterpart for this operator. You necessarily must use the
Math.Pow
static method. Ok, this is not a very important feature, but it may make
your code a bit
shorter in math-intensive algorithms.
11. In VB.NET you can declare and create a new object instance with a
single statement: Dim o As New MyObject, while in C# you must first declare
a new object
variable, and then instance it (even if you can still do this in the same
line, as in
MyObject o = new MyObject();). The VB.NET's way is faster to write, and
keeps the lines
shorter.
12. This point concerns VB.NET programming with Visual Studio .NET, so it
is not really about the VB.NET language itself, but I feel it's a quite
important
point. When in C# you add a method to an existent class, you must recompile
the project before
seeing that new method in the list that the Intellisense pops up when you
write the
class instance name followed by a dot. Instead, in VB.NET the new member is
immediately
available in the list. Similarly, when you write invalid code in C#--such as
referring to an
invalid variable name, calling a non-existent method or passing a wrong
number of
arguments--the error is signaled only at compile time. Instead, in VB.Net
the invalid code is
immediately underlined in red, and you can correct it before compiling. This
is
because the VB.NET is compiled in background while you write it. This is
very, very useful,
but it also makes the code editor much slower than in C# because of the
background work...
so you must have a fast machine to really appreciate this feature,
otherwise you'll be
bothered by the slow editor!
13. VB.NET has the CType function and other casting operators that you
can use instead of
the Convert class, and that make the casting easier.
14. Instead of importing/including the same list of common namespace in
all your source
files, as you do in C#, in VB.NET you can define this list at project
level, and add just
the file-specific imports in the source files. This is very handy when
you realize that
you can remove an unused namespace or you have to add another one.
However, I must say
that if you need to import a certain source file later into another
project, you might
find yourself spending time wondering which project-level imports you
need in the new
project. This issue does not present in C#, of course, where all the
imports are declared
at the top of each file.
15. In a VB.NET Windows Forms project where you have a lot of forms you
can set the startup
forms from the project's Properties dialog, or set a Sub Main procedure
as startup object.
In C# you don't have this possibility, the startup form is always
created and launched
from a static Main procedure defined somewhere, typically in the first
form class added by
VS.NET. When you have a lot of forms and don't remember where the Main
function is
defined, and you want to change the startup form, you first have to find
the Main
procedure, and then you have to edit it, and possibly move it to an
external class or the
startup form class, if you want your code to be well organized.
16. VB.NET still supports the Declare statement you're used to from the
previous version.
C# doesn't have it and you must declare the signature of the API
routine/function
and then
link it to its implementation using the DllImport attribute. VB.NET
developers can use
this attribute as well (and they should), but still keep the other
possibility, which is
useful especially when you're porting to .NET from existing VB code.
17. VB.NET still supports many VB functions, such as AppActivate, Shell,
PrevInstance,
StrComp and others, that either don't have a direct .NET counterpart, or
provide a quick
shortcut to something that would require more code in C#.
"Saga" <an******@somew here.com> wrote in message
news:Oy******** ******@TK2MSFTN GP12.phx.gbl...
Hi all, I just read the thread by the same name posted on Jun 15, 9:45 AM,
but
I am looking at it from a different point of view. I came across this
question in
terms of functionality. Are VB and C# (.NET) really functionally
equivalent?
I had read that although they are very similar, C# does extend
functionality further than VB.NET; however, when I searched for pages regarding this,
I could not find any.
Any recommendation where I read about this further?
Thanks all!
Saga
