Is C++.Net used extensively?

Question

I am a C++ coder by tradition. Over the last 12 months or so I have been doing a lot of C# coding, and have been pleasantly surprised by C#'s pragmatic approach (once I stopped trying to code it as if it was "C++ with garbage collection").

We have recently had some graduates in and when helping one of them I realised she was using .Net within C++. After asking her why, she said she had been "told to use C++ by her manager". Obvious communication problem aside, I assume she was using .Net because that's the only framework she's been exposed to.

I then came across an old project by a senior developer who also used C++ to drive a Forms front end. Now this would have been written around the time .Net first appeared, so I assume it was a learning exercise on his part to play around with .Net. It was only a small utility app.

Having had to do some minor modification in this app, it seemed to me that using C++ to drive .Net gives you the worst of both worlds. No garbage collection or memory safety, but no similarly no real speed/optimisation opportunities since you're dealing with a managed framework.

So my question is whether people do use C++ .Net for any large stand alone (ie non-plumbing) production code, and if so what are your reasons for doing so? I freely admit I have never delved deeply into the C++ .Net extensions so I may be doing it a disservice.

Answer 1

C++.NET (or, precisely, C++/CLI) does have garbage collection, just like everything else that runs atop .NET. To achieve this while remaining compatible with C++ proper, it uses ^ syntax and gcnew for garbage-collected ('safe') pointers.

C++/CLI is considered an abomination by many, it's significantly more unpleasant to work with than either C# or C++ proper, and also more complicated than either (simply because it brings the complexity of C++ itself to the table and adds what it takes to work with .NET to the mix). Learning C# usually pays off even within the scope of a single medium-sized project. However, there is one thing it can do that neither C# nor native C++ can do: compile existing C++ against .NET and have it talk to other .NET components.

Consequently, it doesn't make much sense to use C++/CLI for a from-scratch project - anything .NET related that can be done with it can also be done in C#, with much nicer syntax and the added safety of not exposing raw pointers by default. Its most prominent raison-d'etre is porting existing codebases to .NET. A company that decides to start using .NET, but unwilling (or unable due to resource and time constraints) to rewrite every piece of software they have produced so far, can use C++/CLI to keep using their existing codebase with only minimal changes, and then rewrite components of their system in C# one by one. At least that's the theory; I have never seen it done in practice myself, so I can't tell how well it works.

Also note that C# itself can interface with native libraries, so even if you have to use existing C++ codebases, you don't necessarily have to recompile them against .NET: often, interfacing with them through COM or P/Invoke is the better solution.