Good information, SR. I'm coming from a VB6 background, so I also have a
preference for VB.Net -- I think the IDE is a bit better with intellisense
and background compilation.
Only one question -- why do you believe that C# is better for API calls?
AFAIK, every API call runs equally well with VB.Net. (I've run a few
without any problems, although I try to avoid them unless necessary.)
Hi
There is a major difference between the terms
managed/unmanaged and unsafe.
<B>Managed code</B> is that code which executes under the
supervision of the CLR. The CLR is responsible for various
housekeeping tasks, like:
managing memory for the objects
performing type verification
doing garbage collection
Any code that targets the CLR to make use of these
features in Managed Code and can be written in any
language like C#, VB.Net, MC++, Fujitsu Net Cobol, Eiffel
etc...
On the other hand, <B>unmanaged code</B> is that code
which executes outside the context of the CLR. The best
example of this is our traditional Win32 DLLs like
kernel32.dll, user32.dll, and the COM components installed
on our system. How they allocate memory for their usage,
how memory is released, how (if any) type verification
takes places are some of the tasks that are undertaken by
them on their own. A typical C++ program which allocates
memory to a character pointer is another example of
unmanaged code because you as the programmer are
responsible for:
calling the memory allocation function
making sure that the casting is done right
making sure that the memory is released when the work is
done
If you notice, in the managed world, all this housekeeping
is done by the CLR, as explained above, relieving the
programmer of the burden.
<B>Unsafe code</B> is a kind of cross between the managed
and unmanaged codes
It executes under the supervision of the CLR, just like
the managed code, but lets you address the memory
directly, through the use of pointers, as is done in
unmanaged code. Thus, you get the best of both worlds. You
might be writing a .NET application that uses the
functionality in a legacy Win32 DLL, whose exported
functions require the use of pointers. That's where unsafe
code comes to your rescue
So
a) Both VB.Net and C# produce IL and IL is definitely run
under the managed context.
b) In the case of win32 or COM they run outside the
managed environment.
c) Unsafe code can be written in C#(using unsafe blocks)
but NOT in VB.Net. this is the only difference btwn the
two in this context
d) Unsafe Code also runs inside the managed environment
(remember UnSafe Code is written inside a C# program and
C# code always runs as managed code), but as a deviation
from a normal managed code, it allows use and manipulation
of pointers, which makes it powerful(and dangerous if u
dont know wat u r doing). As you use direct manipulation
of pointers, you normally pin(fix) the memeory location of
the variable inside unsafe code(lest the CLR mess up with
the reference during GC and heap compact operation and u
ask "who moved my cheese"
)
Now back to the original question. Though i have worked
on java for quite some time and C# was easy for me to use
(semantics-wise), i still remain(n honoured to be) a VB
Buff. lets map the technical capabilities to the
requirements now..
a) Learning Curve : If ur developers are with VB
background, then stick to VB.Net(forget those holier-than-
thou guys who smirk at VB programmers...) But if ur dev
base is java familiar go ahead with C#(its as good, after
all MS made both the languages
)
b) COM Interop & Late Binding : If you are using COM, one
thing tht might need in your programs is the concept of
late binding. If so VB.Net is the way to go as it fully
supports late binding, whereas achieving it in C# is a
pain in the butt
c) UI : Somehow i always feel that UI designed in VB.Net
is more user-friendly(and aesthetic) than a form designed
in C#. Probably this is just coz im nostalgic, but still
my feeling is strong in this regard
d) UnManaged Code : If you are going to call UnManaged
Code like Win32 APIs(NOT COM components, as COM interop is
supported in both C# and VB.Net), then C# is th way to go
e) Unsafe Code : As explained C# is the way to go
hth
regards,
sr