Managed C++ or The good, the bad, and the ugly.

A little while ago, in a discussion with a co-worker, I was describing some of the quirks I’d discovered while playing around with managed C++ and coined the expression ‘C+-‘ for it. He got a pretty good laugh over it. It is, however, somewhat appropriate…

This is not an indepth review of the language, just a few small observations that I’ve come up with as I’ve been playing with it. There are a lot of good reviews out there and, in general, using Managed C++ is not a whole lot different than working with C# in the .NET environment.

The Good

  • The only .NET language that can mix managed and unmanaged in the same code. This may not seem like a monster win, but it is. The .NET framework and C++ are very powerful and this combination gives you access to the classes in the framework while giving you the ability to go to as low a level as you need when performance is important. You can’t do that in C#, for example.
  • Some of the common C++ coding errors are reduced or even eliminated. I do a lot of code reviews and one of the biggest things that keeps coming up is memory leakage. An awful lot of people forget to clean up memory when they’re done and, over time, that makes the software unstable. Managed C++ won’t eliminate this, but it reduces it. If you don’t think this is valuable, being an old-school C++ guy, then you should take it up with the C++ standards committee, a similar memory management model is slated for the next for revision of the standard.

The Bad

  • Some of the language semantics are weird. For example: String^ a = gcnew String(); This gives you a “handle” to a string on the managed heap. This is compiler lazyness. There are two things that indicate that the object is on the managed heap: the ^ symbol instead of a * and the use of gcnew vs new when constructing the object. One of the two is needed, but both? After the object is created, either way, you’re going to use the same semantics in accessing their methods and members. Net effect, the compiler should be able to tell which heap has the object based on the use of ^ or the use of gcnew.
  • No bitfields in a managed class or struct. Obviously you can work around this by making the bitfield unmanaged, but there is a cost associated with mixed code. More importantly, however, the implication of this lack is that your control over memory usage is massively reduced and memory control is a big feature in C++. Basically, your control over memory packing is non-existent.

The Ugly

  • Visual Studio insists on sticking everything in the header. When I say everything, I mean everything. The project will get created with a .h and .cpp file, but the .cpp file is basically empty, containing only a #include for the header. This is simply for the compiler, everything else lands in the header file. Huh? I’m okay with simple methods being in the header, usually one liners, but massive methods are stuffed in there as well. If you’re like me, you’ll end up moving the code around, but be careful since that can mess up the IDE if you’re doing any Windows forms development.
  • Visual Studio insists on sticking the visibility declaration (public, protected, private) on every entry. While it’s not a big deal, C++ is NOT C# and it just looks ugly. I end up cleaning this up, but it’s a pain. Generally, I end up avoiding the visual designer after the initial layout just to avoid this and the previous complaint.

The Conclusion

I’m not quite the C++ purist as my aforementioned co-worker, so managed C++ (or C+- if you prefer) is not a language I’m going to avoid. There are some ups to it and some downs, but I’d rather use it than C# when it comes to .NET development. Anyways, these are just some minor thoughts that have come to me as I’ve worked with the environment, your mileage may vary.

Postscript

If you’re looking at doing Windows forms development with managed C++, be careful with x64 vs x86 and third party libraries. A lot of control libraries are written in C#, which is fine, and are compiled for “Any CPU” allowing them to be used by 32-bit and 64-bit code in .NET, but not all are done that way. If the control is explicitly compiled for x64 it will be unusable in the forms designer. You can use it, but not by dragging it on to the form in the designer, it’ll throw an error. This is because Visual Studio is a 32-bit app and can’t work with visual controls explicitly targeted to the x64 CPU. Just an FYI.

Leave a Reply