What are the advantages of doing 100% managed development using C++/CLI?

Question

What are the advantages (the list of possible disadvantages is lenghtly) of doing 100% managed development using C++/CLI (that is, compile with /clr:safe which "generates ... assemblies, like those written in ... C#")? Especially when compard to C# (note C++/CLI : Advantages over C# and Is there any advantage to using C++/CLI over either standard C++ or C#? are mostly about managed/unmanaged interop).

For example, here are a few off the top of my head:

• C++-style references for managed types, not as elegant as full blown non-nullable references but better than nothing or using a work-around.

• templates which are more powerful than generics

• preprocessor (this may be a disadvantage!, but macros can be useful for code generation)

• stack semantics for reference types--automatically calling IDisposable::Dispose()

• easier implementation of Dispose() via C++ destructor

C# 3.0 added auto-implemented properties, so that is no longer a C++/CLI advantage.

Answer 1

I would think that the single biggest advantage is the managed/unmanaged interop. Writing pure managed C++/CLI would (to me at least) without interoping with C# or other .Net languages seems like missing the point entirely. Yeah you could do this, but why would you?

If you're going to write pure managed code why not use C#. Especially (like nobugs said) if VS2010 drops IntelliSense support for C++/CLI. Also in VS2008 the IntelliSense for C++/CLI isn't as good the C# IntelliSense; so from a developer standpoint, it's easier to work/explore/refactor in C# than C++/CLI.

If you want some of the C++ benefits you list like the preprocessor, stack semantics and templates, then why not use C++?

Answer 2

Odd, I like C++/CLI but you listed exactly its features I dislike. My criticisms:

• Okay. But accidental use of the hat is pretty widespread, getting the value of the value type boxed without warning. There is no way to diagnose this mistake.
• Power that comes at a high price, templates you write are not usable in any other .NET language. If anything, it worsens the C++ template export problem. The complete failure of STL/CLR is worth pondering too.
• Erm, no.
• This was IMO a serious mistake. It already is difficult to avoid problems with accidental boxing, as outlined in the first bullet. Stack semantics makes it seriously difficult for any starting programmer to sort this out. This was a design decision to placate C++ programmers, that's okay, but the using statement was a better solution.
• Not sure how it is easier. The GC.SuppressFinalize() call is automatic, that's all. It is very rare for anybody to write a finalizer, but you can't avoid the auto-generated code from making the call. That's inefficient and a violation of the 'you don't pay for what you don't use' principle. Add to this that writing the destructor also forces a default finalizer to be auto-generated. One you'd never use and wouldn't want to be used if you forgot or omitted to use the destructor.

Well, that's all very subjective perhaps. The death-knell will come with VS2010, it will ship without IntelliSense support for C++/CLI.

Answer 3

You can have enums and delegates as generic constraints in C++/CLI, but not in C#.

https://connect.microsoft.com/VisualStudio/feedback/details/386194/allow-enum-as-generic-constraint-in-c

There is a library to simulate these constraints in C#.

http://code.google.com/p/unconstrained-melody/

Answer 4

One could imagine the following requirements for a hypothetical product:

1. Quick time-to-market on Windows
2. Eventual deploy to non-Windows platforms
3. Must not rely on Mono for non-Windows

In such a scenario, using eg C# for 1 would stymie you on 2 and 3 without a rewrite. So, one could develop in C++/CLI, suitably munged with macros and template shenanigans to look as much like ordinary C++ as possible, to hit reqt 1, then to hit reqt 2 one would need to (a) reimplement said macros and template shenanigans to map to pukka C++ and (b) implement .NET framework classes used in pukka C++. Note that (a) and (b) could be reused in future once done once.

The most obvious objection would be "well why not do the whole thing in native C++ then?"; well maybe there's lots of good stuff in the vast .NET class library that you want to use to get to market asap.

All a bit tenuous I admit, so I very much doubt this has ever been done, but it'd be a fun thing to try out !

Answer 5

In C++/CLI you can define functions outside of classes, you can't do that in C#. But I don't know if that is an advantage

Answer 6

I agree on what you have mentioned and as an example of preprocessor use point to: Boost Preprocessor library for generating a set of types based on a list of basic types e.g. PointI32, PointF32 etc. in C++/CLI

Answer 7

Like others here, I can't think of any general cases where a clear advantage exists, so my thinking turned to situational advantages -- are there any cases where there is an advantage in a particular scenario?

Advantage: Leverage the C++ skill set of technical staff in a rapid prototyping scenario.

Let me elaborate ...

I have worked quite a bit with scientists and (non-software) engineers who aren't formally trained programmers. Many of these people use C++ for developing specific modules involving high-end physics/mathematics. If a pure .NET module is required in a rapid prototyping scenario and the skill set of the scientist/engineer responsible for the module is C++, I would teach them a small amount of additional syntax (public ref, ^ and % and gcnew) and get them to program up their module as a 100% managed C++/CLI DLL.

I recognize there are a whole heap of possible "Yes, but ..." responses, but I think leveraging the C++ skill set of technical staff is a possible advantage of C++/CLI.