I would only use managed C++ for your project if you need to access existing
C++ libraries that do not expose COM interfaces, or if you make extensive
use of large portions of the Win32 api or other C libraries.
C# and VB.Net allow you to access COM objects through interop assemblies
(generated automatically from type libraries by Visual Studio .NET), so
including com libarires in your project is relatively easy,
However, "regular" C++ classes cannot be reliably used across language or
compiler boundaries (which is the whole reason COM was created), and
template classes do not exist at run time so you would not be able to
utilize non COM based C++ libraries from C# or from Visual Basic without
wrapping them up with a .NET Assembly written in Managed C++.
C functions, such as those in the Win32 API can be used in C# or VB.Net via
the "extern" or "declare" constructs repsectively (the C# "extern" construct
is not identical to the C++ "extern" construct, so you should read the
documentation on it if you decide to go with C#). However if you use a lot
of C functions, particularly if the take pointers to large structures as
arguments, the use of extern / declare can get to be rather tedious and you
would be better off using Managed C++.
However, Managed C++ has some restrictions on it that as a C++ program you
may find frustrating, you will more than likely have several linker realted
headaches, you will consistently have to wory about the garbage collector,
and you may have to use pointers in places your C++ design skills tell you
shouldn't require pointers.
The value semantics between the .NET CLR and C++ are different, and that
introduces several incompatibilities that will cause you to use pointers to
C++ classes rather than stack based instances as attributes of managed
types. Also, if your managed types contain pointers to unmanged data that is
owned by other managed types, you have to make sure to place a reference to
the owning managed type in the referenced managed type to be sure that the
garbage collector sees the relationship between the two managed types,
otherwise you will have dangling references lying around.
Basically, Managed C++ can be irritating, so only use it when you need to.
For the most part C# and Visual Basic.NET are identical. C# offers an
"unsafe context" where you can have pointer types and do pointer artihmetic
and other unsafe things that VB.NET doesn't support, and VB doesn't allow
you to do operator overloading. However unsafe C# is rarely ever required,
and you can get around operator overloading by creating methods.
So the primary factor in choosing between C# and VB.Net is style preference.
Because youre first language was C++, you will probably like C# better than
VB.Net.
Basically, the purpose of C# was to give C++ programers the RAD development
capabilities of Visual Basic 6, while keeping a C++ look and feel. The
equation I use to describe C#, is "VB = VB + 1" which plays on the meaning
of C++, noting that Visual Basic doesn't have a ++ operator.
