C++ or C#

[danutz_plusplus]

Hi. Up until now I've had a pretty general experience in C++ and I've recently started learning C#. But now I feel like I don't know what to choose. I'm really attracted by the speed development that C# offers, but I heard that it's slower than C++. I don't know what to choose. Or would it be possible to go along with both, or is it a waste of time? Anyway, I thought that maybe you guys could tell me your opinions on this matter, and if you were in a similar position what did you choose and why. I'm mainly looking to developing windows programs and maybe graphics programs(either directx or xna). Thanks, and I'm looking forward to your opinions.

[TheCPUWizard]

There have been a few good (and sometimes long) threads on this subject. Search is your friend. :)

[danutz_plusplus]

There have been a few good (and sometimes long) threads on this subject. Search is your friend. :)

I've tried that before starting this thread, but the search function said that the keywords(C#, C++, choose, etc) I provided are too general. I tried other keywords but no such luck. I'll have to search the threads manually. :(

[spoulson]

Let's ignore C# for a moment and compare native vs. Managed. C++ compiled to native binary will likely be faster than compiled as Managed C++. Native binary means it generates machine language that the CPU understands. Managed code is only understood by the .NET CLR, which is a virtual machine overtop the CPU.

So what do you need? The fasted, most optimized code? The fastest development cycle? Do you code that integrates with other .NET based software? The .NET Framework takes a lot of guesswork out of development by giving you about all the tools you need. Straight C++ with only the standard library will likely require more work and expertise.

C# is merely a C++like language that compiles easily into the way .NET works. Many C++ features are missing from C# for added simplicity.

[danutz_plusplus]

From everything I've read I've decided to go along with C++, as I can do anything C# does in C++/CLI, I get the added power of ISO/ANSI native C++ and I know C++ better than I do C#. But I wonder if C++ will ever have support for xna, as this is the only downside of C++ up until now.

[Vanaj]

From everything I've read I've decided to go along with C++, as I can do anything C# does in C++/CLI, I get the added power of ISO/ANSI native C++ and I know C++ better than I do C#. But I wonder if C++ will ever have support for xna, as this is the only downside of C++ up until now.

This is true, but I believe MS views/steering group is trying to move developers into C# and .NET, that is their ultimate goal...If anyone knows different and has published proof to the contrary, please post it as I'm a die hard C/C++ type.

[TheCPUWizard]

Native binary means it generates machine language that the CPU understands. Managed code is only understood by the .NET CLR, which is a virtual machine overtop the CPU.


Managed code generates MSIL. When the executable starts running this is convert (as a one time deal) to native code by a process known as JIT. As an alternative you can use NGEN to completely generate a native image.

This actually has a major advantage. If you compile to native, and then distribute to many different processors, then you have to use the "least common demonator" or manually code for all the variations.

My distributing an MSIL image, it will be converted to native code on the actual machine that it is being run on, and is optimized to use all of the features of that processor to the best advantage (e.g. differing execution pipeline depths, advanced hardware vector instructions, etc).

Even if a new class of processor comes out after you ship, this will still happen (provided MSFT updates the runtime). This is completely impossible to accomplish if you ship native code.

----------

There *are* other valid comparitive decisions between the two environments, but this is one very common mis-conception, so I stayed up past my bedtime to write this post :wave:

[danutz_plusplus]

My distributing an MSIL image, it will be converted to native code on the actual machine that it is being run on, and is optimized to use all of the features of that processor to the best advantage (e.g. differing execution pipeline depths, advanced hardware vector instructions, etc).


Then why is managed code slower than native code? Is it because it has to go through the CLR and then it gets in touch with the OS?

[SuperKoko]

Then why is managed code slower than native code? Is it because it has to go through the CLR and then it gets in touch with the OS?
AFAIK, Managed C++ code slower than pure C++ code because there is a costy (in CPU cycles) interface between binary code and MSIL code.
Moreover, integration of a garbage collector in a partially-GC'ed environment may also be a factor that complicates and slow down things.
The factor is not huge.

And, C# is slower than pure C++ code, for a simplier reason... You won't program the same way in C++ than in C#.
In C#, you'll use classes having reference semantics, and thus, there will be a lot of indirection, and a lot of small memory blocks allocated on the heap (so, even if the garbage collector is very fast, there will be much more heap to handle than in C++).
C# has been designed to be not too slow, and has things like structs to reduce those penalties, but most of your classes will not be structs as structs are much less flexible.

Moreover, MSIL can't be optimized as much, for specific platforms, than source code, because it's too low level, and that Microsoft don't want that this just in time compilation take 2 hours, so it's far from being optimal.

[spoulson]

Great points. In addition to the above comments, be aware that the CLR is stack based. This is in contrast to CPUs, which are register based. When you want to do something with two values, the CLR wants them on the stack, whereas a CPU wants them in two registers (e.g. eax and ebx). These two models vary quite a bit and thus MSIL code will not be as optimized when converted to binary (via NGEN or JIT) compared to natively compiled C/C++.

[Zaccheus]

There are at least four alternatives here:

(a) Native C++
(b) Mixed - native C++ and .net C++/CLI
(c) C++/CLI (/clr:safe)
(d) C#

I see the native vs managed question in a similar way as the old assembler code vs C/C++ debate. There are a few things you will want to make as fast as possible, but most things can be achieved better at a higher level of abstraction.

As far as .net is concerned, I prefer C++/CLI over C# because I like many of the language features which C++/CLI inherited from C++. Compiling with (/clr:safe) ensures that only safe IL code is generated and produces fully verifyable assemblies just like C# does.

I completely agree with what TheCPUWizard said in his post. Because IL is a kind of binary source code from which the JIT compiler will generate the actual machine code, a .net application can be optimised in ways that a native application developer can only dream of. A pure .net application can, for instance, run in native 64-bit mode on Windows 64.