What is the point of C++/CLI?
I am wonderin开发者_如何学Pythong 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?
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
C++/CLI has a few interesting things that C# does not have:
Strongly-typed boxing. If you box an
int
to anobject
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 callDispose
. In C++/CLI, you just chuck the cleanup code in the destructor (which automatically gets compiled into aDispose
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 theinternal
andprotected 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.
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.
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 ..
精彩评论