Unmanaged C++ in .net

can someone please tell why , Great Microsoft that created C# language and now we're in C# 4.0 , dont have an important feature that C++\CLI has !!,which is to directly compile and li开发者_开发技巧nk with un-managed c++ ??

C# is a different language. It doesn't have to include all the features of any other language in order to be useful to its user community. In particular, the emphasis in C# 4.0 has been to move in exactly the opposite direction to C++ by absorbing features from dynamic (scripting) languages instead. Also where C# shares features with C/C++ (e.g. pointers) they are segregated in a special "unsafe" mode to indicate that they are usually undesirable.

Furthermore, as .NET is a multi-language platform, it isn't necessary for every language to include all the features of every other language in order for them to interoperate. They can call each other very easily anyway.

Note that C++ and C# fundamentally disagree with each other on the meanings of many keywords and operators. For example:

class C { }

(Leaving aside whether this should have a semi colon (optionally preceded by a comma-separated list of variable declarations) after it or not, which is going to be tricky to unify.)

Should C be a native C++ class that can be allocated with unmanaged memory and passed to other native code without having to be pinned in the GC? Or should it be a .NET class that can be passed to other .NET libraries?

Or how about:

C c;

Should that declare a reference to C, or create an instance of C?

Or how about:

new C()

Should that allocate on the native C++ heap or on the GC .NET heap?

In C++/CLI all these questions have to be resolved. Learning from the mess that occurred in previous versions, Microsoft clearly separated the two worlds within C++/CLI, by using different keywords, such as gcnew instead of new.

If you attempted to allow C# to compile C++ as it is today, you'd have to rename many operations that are already fundamental to C#, breaking compatibility with all existing C# programs.

What would be the point?

Because C# is a managed language and intended to be used to write managed code, and C++/CLI already exists to bridge the gap for people who need to directly link unmanaged C/C++ code?

I'm not sure why you would want more native interlink support beyond DllImport/PInvoke. Anything more and you'd just be re-creating C++/CLI with minor syntax differences.

You can call C++ code with PInvoke even if, yes, it's not the same.

Because managed and unmanged code is kept separate. Manged code executes in the CLR, while unmanaged doesn't. You can link you managed code with unmanaged code with P/Invoke.

Eseentially this is to help you marshal information to and from the managed world.

You can call unmanaged C++ from managed code, and you can call managed code from unmanaged C++. See PInvoke and C++/CLI