IS C++ converted into MSIL?

Question

I have been a long time C# and .Net developer, and have been playing with the idea of learning c++.

One of the primary reasons I have been thinking about this, is how much faster C++ can be over apps using the .Net framework. But am I right in assuming that if I write a C++ app in Visual Studio, and/or reference .Net libraries in a C++ application that, that C++ is converted in MSIL (just like C#) - and therefor I'd loose any benefit from coding in it?

So my question is really this: are C++ components of an application referencing .Net assemblies compiled in the "traditional" way, or comiled into MSIL?

Answer 1

This is a pretty good (if dated) discussion of managed vs unmanaged C++.

In a nut shell, C++ can be either managed (compiled to MIL) or unmanaged (compiled to native code).

Answer 2

Well it's a bit more complicated than that. There are actually two totally different versions of .NET-supporting C++.

The old one, Managed Extensions for C++, was the only option available in Visual C++ 2002/2003. It's available in newer compilers under the option /clr:oldSyntax. It's kinda clumsy as it tries hard to integrate with standard C++, so all new keywords (and there's lots of them) are prefixed with double underscores, etc. Code generated by this compiler is a mixture of native and MSIL code, dubbed IJW "it just works".

The new one, called C++/CLI, is a clean new language available in Visual C++ 2005 and newer. Most importantly, it supports several modes of code generation. The /clr option again generates a IJW mixture of native and MSIL code. /clr:pure results in a managed-only assembly, although it may translate native types into corresponding .net structures. The code therefore may not be type-safe and can use pointer arithmetic, pretty much like C# with /unsafe. And the strictest of options is /clr:safe, which produces type-safe, verifiable MSIL-only assembly, exactly like C# compiler does (without /unsafe, that is).

For differences between MC++ and C++/CLI, see wikipedia.

For description of the compiler switches, see MSDN.

PS. The .NET byte-code is called either MSIL (Microsoft Intermediate Language) or CIL (Common Intermediate Language). MIL can stand for Media Integration Layer, the undocumented low-level library used by WPF and Vista Desktop Window Manager.

Answer 3

Regardless of your reasons for wanting to learn C++ it is always good to know more languages because it broadens your mind so learning C++ is a valuable lesson in itself.

With C++ you can either run it as a .NET application C++/CLI or native. It is just a compiler switch in Visual Studio however there are quite a lot of syntax differences between the two. I personally think learning both flavors is useful.

Which to choose in your projects depends a bit on the requirements e.g. if your program needs to interact other managed modules like modules written in C# it is preferable to use C++/CLI to avoid some overhead switching between managed and unmanaged code.

Answer 4

It's probably a good idea to keep the concepts separate.

First, C++ is a language, and it doesn't specify anything about what platform should be targeted. In principle, straight C++ code could be compiled to native x86 assembler, Java bytecode, MSIL or anything else you care to think of. I believe Adobe recently made a C++ compiler which generates Flash bytecode.

Second, with typical indecisiveness, Microsoft has created two C++-derived languages targeting .NET. First, they made the "managed extensions for C++". Then they decided it sucked, ditched it and tried to pretend it never existed.

Now their best bet for .NET-style C++ is called C++/CLI, but it is not C++. It extends and changes the language in a number of nonstandard ways. (And I believe the C++ standard committee requested that they change the name to avoid confusion. But they didn't)

Visual Studio 2005 and newer supports C++/CLI. (in "Add project", they're listed under Visual C++ -> CLR)

However (you didn't think it was that simple, did you?), Microsoft has done it again. After specifying C++/CLI, which is actually a reasonably well-designed attempt at integrating C++ with CLI, they realized that virtually no one uses it! Turns out that even C++ programmers generally prefer to use C# when they're working in .NET, and proper, native C++ otherwise.

So now, they're focusing on making interop between native C++ and .NET simpler and more powerful. However, C++/CLI isn't likely to go away. It works, and in some cases it's useful. It's just not the C++-killer they originally hoped for.

Visual Studio (since forever) also supports native C++ applications, compiled to x86 machine code, untainted by .NET. These are listed in the "Add Project" dialog under Visual C++ -> Win32.

So if you want to learn C++, you have two choices: Learn C++/CLI, which limits you to a MS-only language which yes, generates MSIL instead of native machine code, and requires .NET to run, and generally isn't worth the bother because if you're going to take a dependency on .NET anyway, why not write in C#?

Or learn proper C++, which is completely separate from .NET and can't directly reference .NET assemblies.

The key takeaway point is that they're separate languages. Either you compile as C++/CLI, which means the compiler will allow you to reference .NET assemblies, and will generate MSIL code, or you compile as C++, in which case the .NET world doesn't exist.

And finally, a note of caution. Despite my wording above ("proper C++" and "untainted by .NET"), C++ isn't "better". In many cases, it is not faster either. C++ has the potential to be faster, but it depends a lot more on the programmer.

The C# compiler will turn pretty much anything into reasonably efficient code. C++ on the other hand, is full of pitfalls that will make your code slower than the equivalent C#.

http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx and the blog posts it references are worth a read for anyone curious about the performance of similar code written in the two languages.

There is only one area where C++ applications will be consistently faster, and that's in startup time. a .NET application may have to load the .NET framework and JIT the MSIL code, where a native application... just starts.

But other than that, it is probably a mistake to assume that C++ will be faster. It can be, because it gives you a bit more control. But usually, that just means the compiler is less able to save you from the inefficiencies you create in your code.

Answer 5

C++ components cannot easily reference .Net assemblies ( you need to use COM) . Managed C++ is compiled into CIL and has the same performance profile to C#.

C++ is about 10% faster for the same level of optomization for most code however C# takes half the time to write and Debug so for the same amount of time i would argue the optomizations you can put in place would make C# faster...