Managed C++ (C++/CLI) vs C#/VB.NET

Question

I have worked extensively with C#, however, I am starting a project where our client wishes all code to be written in C++ rather than C#. This project will be a mix between managed (.NET 4.0) and native C++. Being that I have always preferred C# to C++ for my .NET needs, I am wondering if there are any important differences I may not be aware of between using C# and managed C++?

Any insight into this is greatly appreciated.

EDIT Looking at Wikipedia for managed C++ code shows that the new specification is C++/CLI, and that "managed C++" is deprecated. Updated the title to reflect this.

Solution 1

C++/CLI is a full fledged .NET language, and just like other .NET languages it works very well in a managed context. Just as working with native calls in C# can be a pain interleaving native C++ and Managed C++ can lead to some issues. With that said, if you are working with a lot native C++ code I would prefer to use C++/CLI over C#. There are quite a few gotchas most of which could be covered by do not write C++/CLI as if your were writing C# nor write it as if you were writing native C++. It is its own thing.

I have worked on several C++/CLI projects and the approach I would take really depends on the exposure of different levels of the application to native C++ code. If the majority of core of the application is native and the integration point between the native and managed code is a little fuzzy then I would use C++/CLI throughout. The benefit of the control in the C++/CLI will outweigh its problems. If you do have clear interaction points that could be adapted or abstracted then I would strongly suggest the creation of a C++/CLI bridging layer with C# above and C++ below. The main reason for this is that tools for C# are just more mature and more ubiquitous than the corresponding tools for C++/CLI. With that said, the project I have been working on has been successful and was not the nightmare the other pointed to.

I would also make sure you understand why the client is headed in this direction. If the idea is that they have a bunch of C++ developers and they want to make it simpler for them to move to write managed code I would posit to the client that learning C# may be less challenging then learning C++/CLI.

If the client believes that C++/CLI is faster that is just incorrect as they all compile down to IL. However, if the client has a lot of existing or ongoing native C++ development then the current path may in fact be best.

Solution 2

I've done a project with C++/CLI and I have to say it was an abomination. Basically it was a WinForms application to manage employees, hockey games, trades between teams, calendars etc, etc...

So you can imagine the number of managed controls I had on my forms: calendars / date time pickers, combo boxes, grids etc.

The worst part was to use only C++ types for my back-end, and use the managed types for the front-end. First off you can't assign a std string to a managed string. You'll need to convert everything. Obviously you'll have to convert it back...

Every time I needed to fill a grid, I serialized my C++ collections to something like a vector<std::string>, retrieve that in my UI library and then looped trough that and made new DataGridRow to add them to the grid. Which obviously can be done in 3 minutes with C# and some Linq to SQL.

I ended up with A+ for that application but lets be honest it absolutely sucked. I just can't imagine how pathetic the others app were for me to get that.

I think it would've been easier if i used List<Customer>^ (managed List of some object) in my C++ instead of always converting everything between vectors of strings. But I needed to keep the C++ clean of managed stuff.

/pissedof

Solution 3

From using all three areas (.NET, C++/CLI and C++) I can say that in everyway I prefer using .NET (through C# or VB.NET). For applications you can use either WinForms or WPF (the latter of which I find far better - especially for applications that look far more user friendly).

A major issue with C++/CLI is that you don't have all the nice language features that you get in .NET. For example, the yield keyword in C# and the use of lambda (I don't think that's supported in C++/CLI - don't hold me to that).

There is, however, one big advantage of C++/CLI. That is that you can create a bridge to allow C# and C++ to communicate. I am currently working on a project whereby a lot of math calculations and algorithms have already been written (over many years) in C++, but the company is wanting to move to a .NET-based user interface. After researching into various solutions, I came to the conclusion that C++/CLI was far better for this. One benefit is that it allowed me to build an API that, for a .NET developer, looked and worked just like a .NET type.

For developing an application's front end, however, I would really not recommend C++/CLI. From a usability point of view (in terms of developer time when using it) it just isn't worth it. One big issue is that VS2010 dropped support for IntelliSense for C++/CLI in order to "improve general IntelliSense" (I think specifically for C++). If you haven't already tried it, I would definitely advise checking out WPF for applications.

Comments

[leppie]

The only good reason for managed C++ is interop. And the fact that you can have native 'thunks' (for speed, which can be a lot faster than managed code, example encryption). IMO using C++/CLI pure mode is useless.

[codewario]

The way I envision this project moving forward, managed C++ will be used for the majority of the project, however, it could easily turn into the exact front-end/back-end scenario you just described

[Dave]

I'm serious. It was absolutly horrible. I can't imagine using/selling this app or something.

[siride]

This might be my ignorance, but my experience with doing native calls from C# has been pleasant, if, in fact, forgettable because you don't have to do much most of the time. Yes, passing managed objects might be a pain, but if you just use primitive types and structs, it's pretty straightforward. I keep seeing in this thread that native calls are easier in C++. Can you enlighten me?

[rerun]

First of all the native calls you are making are to a c api that has no concept of objects. Utilizing c++ apis from c# would be nearly impossible as the name mangling and other issues presented. Also in c++ you have direct control over memory assignment allocation strategy layout, .... Most of these thing are accomplishable in c# but with out the vast array of functions to support them you have in c++.

[siride]

yep, forgot about name mangling. That's a pain. C API is easy for sure, but I've never had to use a C++ API. Got it now.

[codewario]

Yep, no C++/CLI support for IntelliSense in 2010 is one issue I am aware of. IntelliSense isn't a requirement though, which sucks because I rely on it daily as a part of my workflow.

[codewario]

And using WPF "isn't feasible" because, as noted in another comment, the client would be required to learn it. But why wouldn't I just be able to use the Designer to throw together a quick interface as if I were using C# or VB.NET? Is it broken for C++/CLI or something?

[Samuel Slade]

@BasedAsFunk The WinForms designer seems to be the same as if used in a .NET project, so I don't see there being an issue in using it to throw together an interface prototype.

[Grhm]

Not that its going to make any real difference, but IntelliSence for C++/CLI has returned in VS2012.

[Cory Gross]

Such a nice answer I had to pretty it up some! +1

[rerun]

thanks I'm dyslexic so I always need some prettying up