Would you use C++/CLI if supported like C# & VB.NET?

I've always had a thing for C++/CLI. Maybe because not many developers use it... or just because it's different.

Suppose Microsoft fully supported C++/CLI as they do VB.NET and C# (ie. LINQ, WPF, etc.). Would you use it?

If not, why?

From stackoverflow JTA

• Perhaps...but I'm not entirely clear on what C++/CLI offers that C# does not. Pointers, perhaps? I've done all of my .NET programming (the little I've done) in C#, and I'm starting to learn F#, but if it was fully supported and well documented, sure, I would give it a go.

  JTA : Exactly. You wouldn't HAVE to do anything different than the typical C# coding, but you always have the native option available.

  Shog9 : If you need to interact with non-managed code, IJW is *huge*. I'm still shocked that the error-prone, VB-style P/Invoke carried through into C# and VB.NET, but C++/CLI provides a way around it, allowing the use of the Platform SDK headers (or whatever other native API headers you might have).
  From Thomas Owens

• I do use it. Even with the relative lack of tool support, it still beats raw P/Invoke for dealing with Win32.

  As for LINQ, i don't really care to see too much more hacked into the C++ language. LINQ is usable enough as-is - if they're gonna enhance the compiler, they should work on C++ 0x support...

  From Shog9

• I am mixing C++/CLI with MFC to take advantage of the WPF and XAML, but I am using the new C++ 2008 feature pack -- free ribbon components. :)

  JTA : I've read a bit about the ribbon component. Is it fully featured similar to MS Office?

  Jeff Yates : You need to agree to Microsoft's license before you use it, which includes a non-compete clause. It's free inperpetuity, but you should be aware that you are restricted by that license, even if you use the MFC implementation.
  From Daniel A. White

• It's all about using the right tool for the right job. I use C++/CLI for platform interop work because it's much easier to get the marshaling correct. I use C# for almost all other .NET work, with some VB.Net (I like the inline XML). I admit I haven't learned IronRuby, IronPython, F#, or any other .NET language yet, but I'm seriously considering it just to increase my programming arsenal.

  To answer the question, I don't think I'd use it anymore than I already do because I feel I already use it for the jobs it fits best. C# is still the best .NET language as I see it because it was specifically designed for that platform, rather than shoehorning an older language to fit it. Adding better support for C++/CLI would only decrease my development time, rather than sway my usage from another language.

  From Jeff Yates

• C++/CLI delivers very effectively on the promise of uniting Managed and Unmanaged code. It lets you expose what feels like a perfectly native C# library with 100% access to native C++/libraries "on the inside". It's not an exercise in elegance but in the history of practical programming tools what compares?

  If you need LINQ and WPF, just use C#. That's the beauty of C++/CLI: write your Managed wrapper and then go back to C#. I don't see C++/CLI intending to replace C# for day to day use.

  From Jared Updike

• ...but I'm not entirely clear on what C++/CLI offers that C# does not. -- @Thomas Owens

  One huge benefit (in my book) is RAII (see the answer given by Adam Wright to my question regarding RAII in .NET).

  From Motti

• I would not use it because I don't want to be tied to a huge run-time. And I don't like all those ^ pointer thingys :)

  I do like/miss the great library that .NET offers though.

  From DougN