tags:

views:

235

answers:

4

Hello, I am wondering what the uses of C++/CLI is. It seems to me that it is basically C++ running on .Net, am I wrong in this thinking? What is it good for? Why not just use C# or some other truly managed language instead?

+9  A: 

Here are a couple of advantages of C++/CLI over simply C++ or say C#

  • It's a great language for writing a large component which interops between native and managed code.
  • Provides a fast(er) conversion path from a purely native C++ code base to a purely managed one. Without C++/CLI your best option would be a rewrite
JaredPar
+1 by contrast look at the hoops you have to jump through with java to talk to gnarly bits of the OS - JNI is a real pain. I know they have improved it recently but its still not easy
pm100
and there are some DLLs that have really complex signatures that cannot be called via p/invoke, so then you have to write a wrapper in c++/cli
pm100
>that cannot be called via p/invoke< - if you are fine with unsafe code, you can consume ANY native method with P/Invoke.
logicnp
+3  A: 

A few reasons for C++/CLI:

  • it allows integration/mixing of managed and unmanaged code at a much finer level than other .NET languages
  • Managed C++ wasn't particularly successful; C++/CLI was an attempt to make the .NET paradigm fit in better with existing C++ idioms
  • While I don't think anyone thought it would overtake C# in popularity, I imagine that there were people who thought it would have a higher level of success than it has. Then again, for all I know it's very successful. I haven't done anything except toy stuff with it - but when the Visual C++ Team Blog indicated that VS2010 wouldn't have IntelliSense for C++/CLI there was a bit of a firestorm of push-back. Much more than I expected (I'm not sure what MS expected).

Microsoft did do some things in C++/CLI that I think are interesting even if you have no interest in .NET: the way they handled adding new keywords in a way that would least impact existing C++

  • multi-word (or 'spaced') keywords (I think this technique is patented or patent-pending by Microsoft)
  • contextual keywords
  • 'namespaced' keywords

See Sutter's article for more details.

Michael Burr
I doubt the technique is patented, and I doubt it will be -- it would be fairly difficult to distinguish from COBOL, which had reserved words with embedded spaces 50 years ago or so (e.g "after advancing NNN lines").
Jerry Coffin
Michael Burr
@Michael, I'm really bet if it was tried, it would definitely be thrown out in court due to many many prior-works.
Earlz
I'm not really commenting on the validity of the patent one way or the other, just mentioning that it's there. However, I do think the use of multiple words as a keyword (permitting the individual words to be used as normal identifiers) is interesting, regardless of whether it should be patentable or not.
Michael Burr
+6  A: 

C++/CLI has a few interesting things that C# does not have:

  • Strongly-typed boxing. If you box an int to an object in C#, you lose any information about what the original type was. Not the case in C++/CLI.

  • A distinction between destructors and finalizers. In C# you have to manually implement IDisposable and remember to call Dispose. In C++/CLI, you just chuck the cleanup code in the destructor (which automatically gets compiled into a Dispose method), and put the managed-only cleanup code in the finalizer.

  • A distinction between stack and heap semantics for variables. Stack is the default, and stack-allocated reference types will automatically be destroyed (disposed) - you don't have to remember to delete them, just let them go out of scope. To make a long story short, it's a lot easier to deal with unmanaged resources in C++/CLI than any other .NET language.

  • Function pointers. This is less of a distinction now with anonymous delegates and lambda syntax in C#, but back in 2005 this was kind of a big deal.

  • Access to all of the access modifiers implemented in the CLR. You can explicitly specify public, protected or private for both the same assembly and external assemblies. All you have in C# (other than the obvious public, protected, private) are the internal and protected internal modifiers, the former meaning "public internally, private externally" and the latter meaning "public internally, protected externally". In C++ you can make a class "protected AND internal", which means that the member is only accessible to derived classes in the same assembly.

  • Value classes. Weird, but probably useful to someone!

There's a more detailed explanation of all this and more here. To make a long story short, other managed languages - C#, VB.NET, F#, and so on - do not actually give you full access to everything that the CLR can do, more like 90% of it. C++/CLI lets you do pretty much anything you want that's in the CLR spec.

Aaronaught
There's still no allocation of reference types on the stack, they always exist on the heap. What you get are stack semantics, i.e. variables that are cleaned up AS IF they were on the stack. Automatic invocation of Dispose for member variables is another place this works, though the name "stack semantics" isn't very description of that.
Ben Voigt
@Ben Voigt: Yes, you're right, I wasn't really sure how to write that. I guess "stack semantics" is as good as any, I'll change that.
Aaronaught
"stack semantics" is also the term the compiler team uses, which is the only reason I use the phrase (since it isn't at all suggestive of member variables).
Ben Voigt
+1  A: 

Gosh, I've used C++/CLI loads when you need to do something high performance (e.g. Image processing with SIMD), interop with native C++ (e.g. OpenGL code, existing legacy C++ code) or just look clever.

ok ;) Maybe not the last one

Dropping support for it would be a great loss IMO ..

Andrew Burnett-Thompson