Managed C++.NET vs VB.NET vs C#.NET

D

Dave

I'm at a point where I would really like to focus in on learning .NET but am
having a hard time deciding which language to use. I learned to program in
C++ but have spent quite a bit of time using VB6. I need to get started on
developing a new application and would like to know what the advantages are
of using managed C++ .NET over VB.NET or C#? My application will involve
some, data acquisition, storage, data plotting, statistical analysis over
multiple sets of test data ( 20,000 - 30,000 double values per set), and
report generation.

Any thoughts on the subject would be greatly appreciated.

Dave
 
W

William DePalo [MVP VC++]

Dave said:
I'm at a point where I would really like to focus in on learning .NET but am
having a hard time deciding which language to use. I learned to program in
C++ but have spent quite a bit of time using VB6. I need to get started on
developing a new application and would like to know what the advantages are
of using managed C++ .NET over VB.NET or C#? My application will involve
some, data acquisition, storage, data plotting, statistical analysis over
multiple sets of test data ( 20,000 - 30,000 double values per set), and
report generation.

<Warning this reply drips with personal opinion/>

If VB confers any advantages then I don't know what they are. :)

Managed C++ is the only .Net language of MS' that allows a developer to mix
almost seamlessly managed and unmanaged code in the same application or even
the same module. It also brings with it much (but not all) of C++'s
complexity and a few little twists of its own.

C# is a new language, developed especially to target .Net. It is less
powerful and less general purpose than C++ but it is a nice, simple and
elegant language.

In short, I'd eliminate VB out of hand. If you need to target .Net as well
as Win32 or if you think that your .Net application will make substantial
use of the Win32 API I'd use MC++. If you target .Net exclusively, I'd use
C#.

Regards,
Will
 
S

Scott Wisniewski

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.
 
S

Shawn B.

If VB confers any advantages then I don't know what they are. :)
...
In short, I'd eliminate VB out of hand.

Regards,
Will

Of course, by posting to this NG you're going to get someone against VB and
in favor of primarily MC++... try posting to
microsoft.public.dotnet.languages.csharp and you'll get people against MC++
and VB.NET. Post to microsoft.public.dotnet.languages.vb and you'll get
people with all the reasons why you should do it in VB and not C# or MC++.
It's all subject. One can only hope to know how to discern through the
pointless bias and instead see the real points to subjectively compare the
various features of the languages available against the needs of the project
and skillset.

In short, C# is probly your best bet. Depends on how much performance you
need and low-level interfacing will be required, MC++ may be another bet.
Even better yet, do you low-level, direct-hardware interfacing in mixed
MC++/unmanaged C++ and put it in an assembly, and do the rest in C# just
referencing it...


Thanks,
Shawn
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top