C++/CLI : Advantages over C#

Question

Is there any major advantage of managed C++/CLI over C#. Definitely not the syntax I suppose as the following code in C++/CLI is real ugly,

C++/CLI code:

[Out]List<SomeObject^>^% someVariable

Compare above with C# Code:

out List<SomeObject> someVariable

Just out of curiosity, is there an even uglier syntax in C++/CLI as compared to the above.

Answer 1

The advantage of managed C++ is that it is easy to mix managed and unmanaged code. But if all (or almost all) of your code will be managed, then C# should definitely be used (and you can still invoking unmanaged code from C# using the DllImport attribute).

Answer 2

Easier interoperation with native C++ code is the one advantage.

Whether it's a major advantage is subjective.

Unless you want to mingle with existing native C++ code, you're probably much better off with C#.

Answer 3

Using C++/CLI it is much easy to interact with native C++ code

Answer 4

you just turn to c++\cli when you have to, if you can meet you requirement using c#, why bother go c++\cli

Answer 5

Generally, I think the main advantage of C++/CLI is simply familiarity for C++ developers. If you're not coming from a C++ background then go with C#.

Answer 6

It's almost exclusively an interopability language - both for allowing .Net code to access legacy C++ libraries, or for extended existing (native) C++ code bases with access to .Net libraries (and some variations on these themes).

While it is possible to write fully fledged applications solely in C++/CLI, and it even gives you some language features not available in pure C++ (such as garbage collection), I doubt there are many people who would actually do this. If you're already moving away from pure C++ and don't have the goal of interop with .Net there are probably more natural choices (such as D or Scala, for example - depending on which direction you want to go in).

Similarly, moving from pure C# to C++/CLI could arguably bring the advantages of C++ templates, but it's rare that this need would lead to you taking that step.

Answer 7

I can think of 3 main reasons to use C++/CLI:

1. You already have a large C++ project and want to use .NET in it (whether you want to migrate it completely in the future or not)
2. You want to use a library written in C or C++. For simple libraries, you can use C#/PInvoke, but e.g. if the libary comes with a complex type system, you might be better off creating C++/CLI wrappers instead of recreating the type system in C#
3. Parts in your project are best written in C++. E.g. if you're doing speech recognition or image processing, C++ might simply be better suited for the task.

Answer 8

unmanaged c++ applications do not need a framework to run, c# will only run on machines with dotnet framework 1, 2, 3 or 4. it surprising how many machines still run without these framework.

Answer 9

Being a predominantly C# programmer, I was finding myself having to use C++/CLI with a bit of pain. However, as an interop language, it FAR outweighs C# for having to work with native code. The C++/CLI IDE in Visual Studio lacks a lot of the features in the C# flavor.

Overall, it has its place and will remain viable as long as native code exists. I wouldn't want to have to create WinForm apps from scratch with the C++/CLI IDE if I didn't have to.

Answer 10

Being able to use native headers files directly is a huge advantage, but not the only one.

Stack semantics are so much better than anything C# has to offer for IDisposable management. C++/CLI has one uniform syntax for correctly managing variables which are IDisposable and those which aren't, both as local variables and as member fields. Comparison:

ref class MyClass
{
   FileStream fs;
}

vs

class MyClass : IDisposable
{
  FileStream fs;

  void IDisposable.Dispose() { Dispose(true); }
  ~MyClass() { Dispose(false); }

  public virtual void Dispose(bool disposing) { if (disposing) fs.Dispose(); }
}

Now which language is looking ugly?

Then there are templates, interior_ptr, #define, native DLL exports, pointer-to-member, and probably several other things I've forgotten.