C++.NET vs.C++ (traditional)

[Chris Murphy via DotNetMonster.com]

I'm curious to know if C++.NET produced a smaller & faster (performance
wise) executeable. I don't know too much about C++ and I'm only starting to
pick it up now, but given that I'm doing a lot of development with VB.NET &
C# I was going to migrate to C++.NET. As I understand it, traditional C++
compiles to a more effient binary which seem to out-perform most if not all
binaries produced by C# or VB.NET.

1. If .NET is an intermediate language, then how does C++.NET fit into the
big picture?

2. Does C++.NET strictly use the .NET framework or can it use
traditional/standard C++ templates and libraries?

3. Will I see any performance gain if I decide to port an application from
VB.NET/C# to C++.NET?

I know there are a lot of really talented developers out there who could
shed some light on this, I would greatly apprecaite it!

 

[Cor Ligthert]

Chris,

This is a myth.

The less cycles a program use to fulfil a problem the faster it is.

That can be by a C++ program easier be realized for small programs than for
programs who use a lot of methods which uses methods which uses methods.

However when it becomes a big program than the C++ program than the change
is that it becomes much slower.

The reason is than that because the programmer has to make all his program
logic by himself, that will be probably less efficient done than in programs
where a lot of classes (logic) are distributed with the language.

DotNet has an endless amount of classes and it is efficient to use them.
There are two ways to use C++ with VSNet. One is as a dotNet program
(managed code) and one is classic (unmanaged code).

However is there a part in your program that is a key part that needs
absolute speed, than it can be efficient to do it in C++ and than go around
by instance all inbuilt safety.

An example is for me in that 3D game programs, where there are part which
really depend on the most shortest way (the most less cycles) to gain a
goal.

However by instance painting the forms on screen when you don't use drawing
in dotNet is done by the OS itself, so interfering in this will give you
probably not much advantage. 3D game programs don't AFAIK seldom use forms
or are (when they are in that mode) slow.

I hope this gives an idea.

Cor

 

[Herfried K. Wagner [MVP]]

I'm curious to know if C++.NET produced a smaller & faster (performance
wise) executeable. I don't know too much about C++ and I'm only starting
to
pick it up now, but given that I'm doing a lot of development with VB.NET
&
C# I was going to migrate to C++.NET. As I understand it, traditional C++
compiles to a more effient binary which seem to out-perform most if not
all
binaries produced by C# or VB.NET.

Managed C++ is not primarily intended for development of "new" applications.
Its advantages lie in the ability to be combined seamlessly with "old" C++
code (interoperability with COM etc.). Managed C++'s runtime
characteristics are similar to those of VB.NET and C#.

1. If .NET is an intermediate language, then how does C++.NET fit into the
big picture?

C++.NET consists of a "managed" and an "unmanaged" part. The unmanaged part
is the traditional C++, the managed extensions are similar to VB.NET/C#, but
MC++ has a really ugly syntax compared to VB.NET/C#.

2. Does C++.NET strictly use the .NET framework or can it use
traditional/standard C++ templates and libraries?

Still, traditional C++ can be used, but it's not executed as managed code.

3. Will I see any performance gain if I decide to port an application from
VB.NET/C# to C++.NET?

I would say "no". Unmanaged code (traditional C++) is better suitable for
realtime applications, but you loose the advantage of a managed execution
environment.

To make a conclusion, I don't recommend to "migrate" code written in
VB.NET/C# to MC++. On the one hand, it's a lot of work, and there are no
benefits of this migration. What you can do is keeping the VB.NET/C# code
and putting it into class libraries, and use these class libraries in your
MC++ project.

 

[Chris Murphy via DotNetMonster.com]

Thanks for the clarification. I think I'll stick to VB.NET and C# for the
time being, though I will pick up C++ since I'm sure I'll enjoy the
challenge. All of the insights and suggestions were great, I'm starting to
get a better grasp of the range of .NET and it's collection of languages.