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?
+1
A:
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.
Thomas Owens
2008-10-07 18:15:05
Exactly. You wouldn't HAVE to do anything different than the typical C# coding, but you always have the native option available.
JTA
2008-10-07 18:17:57
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).
Shog9
2008-10-07 18:26:35
+12
A:
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...
Shog9
2008-10-07 18:17:14
+1
A:
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. :)
Daniel A. White
2008-10-07 18:22:17
I've read a bit about the ribbon component. Is it fully featured similar to MS Office?
JTA
2008-10-07 18:26:53
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.
Jeff Yates
2008-10-07 18:30:41
+5
A:
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.
Jeff Yates
2008-10-07 18:29:50
+4
A:
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.
Jared Updike
2008-10-07 18:36:19
+3
A:
...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).
Motti
2008-10-07 18:44:33
+1
A:
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.
DougN
2008-10-07 19:38:37