Please, describe you experience of using Microsoft C++/CLI

Question

C++/CLI is very powerful language. It's the only CLR language where you can seamlessly combine managed and unmanaged code. How many software developers (on this site) are using this language? In what kind of projects do you use it? Is it an adapting of legacy code or creation of an original software? Can you compare old Managed C++ with new C++/CLI? What do you think about the current quality and about the future of C++/CLI?

Answer 1

I have used C++/CLI for a simulation project. My simulation engine that does the actual computation was an existing code base written in C++. I needed to have a GUI front-end for it, which I successfully coded in C++/CLI.

In my view, the language is just as easy to code in as C# albeit with a slight syntactical awkwardness. However, that said, the syntax is far simpler than that Managed Extensions thing that Microsoft came up with earlier.

One of the most powerful feature of C++/CLI has to be the ability to simply recompile your existing native C++ code into MSIL. Of course there can be hiccups, but for most applications it should be a trouble-free exercise.

As for the suitability of C++/CLI, I think it will remain strictly a language for interoperability with C++. If you are writing an altogether new app, there's absolutely zero reason to pick C++/CLI over, say, C#. As I said, it is a little bit more awkward to use than the latter.

Answer 2

C++/CLI was excellently simple for bringing the CLR into FreeSWITCH. Much easier than dealing with the hosting API or using Mono.

The last time before this I used managed C++ was in 2003 or so. I remember it being somewhat of a pain and not working as seamlessly.

Answer 3

I've used it to write thin layers of integration between managed and native code. That's all though.

The best known unique feature of it is the ability to seamlessly delve into unmanaged code and modify (or accidentally corrupt) any bit of writeable memory in the entire process - that's not an advantage in general programming, but when you need it, it's great. But I think I'm going to need it less and less. You can compile C++/CLI with a /pure flag, but then it really becomes a completely new language.

There are two other big unique features though:

• Destructors that do something useful. In C# a destructor is a finalizer. In C++ it is a proper deterministically-called destructor. This means that C++/CLI has the most complete infrastructure for working with IDisposable. C# only helps clients (through the using statement), but only C++/CLI helps implementors as well. I'm hopeful that perhaps one day C# will absorb this feature.

• Duck-typing templates, which can be used along with CLI generics. Another thing that would be very useful in C#, although it could be made a lot more seamlessly without the historical baggage.

But C# is good enough without the last two things that I'm not tempted to use C++/CLI generally.

Answer 4

We use C++/CLI extensively. We have used it to drag an aging MFC application into the .Net age so we can now write most new functionality in C# and integrate that with the legacy MFC code using C++/CLI, by both wrapping native classes and also writing new managed business objects. In our old assemblies, we're still writing new functionality in C++/CLI as well.

I have no experience with "managed C++" but C++/CLI is a joy to use compared to MFC and Visual C++. .It has a much cleaner syntax than either managed C++ or Visual C++ and we have had no issues at all getting even junior devs up to speed with it.

There are a very few interesting behaviours in C++/CLI like when you pass a native object into a method on a managed class, it puts a thin managed wrapper around the native object (invisible to the developer) just for the purpose of making the call, but that shim is private to the assmebly so cannot be called from outside. There are ways around this, as always, but it caught us out a couple of times early on.

We use Visual Assist X for refactoring support (acceptable), MbUnit/Gallio for unit testing the managed classes and NMock or RhinoMocks for our mocking framework.

Overall, I'd say that the language has saved our product and allows us to take advantage of all the new exciting stuff going on in the development world. If we were still using solely Visual C++/MFC then we'd have difficulty recruiting devs and be far more limited in out COTS choice than we are using .Net.