How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?

Question

I'm just starting my first C++ project. I'm using Visual Studio 2008. It's a single-form Windows application that accesses a couple of databases and initiates a WebSphere MQ transaction. I basically understand the differences among ATL, MFC, Win32 (I'm a little hazy on that one actually) and CLR, but I'm at a loss as to how I should choose.

Is one or more of these just there for backward-compatibility?

Is CLR a bad idea?

Any suggestions appreciated.

Edit: I've chosen C++ for this project for reasons I didn't go into in the post, which are not entirely technical. So, assuming C++ is the only/best option, which should I choose?

Leporid

Answer 1

It depends on your needs.

Using the CLR will provide you with the most expressive set of libraries (the entire .NET framework), at the cost of restricting your executable to requiring the .NET framework to be installed at runtime, as well as limiting you to the Windows platform (however, all 4 listed technologies are windows only, so the platform limitation is probably the least troublesome).

However, CLR requires you to use the C++/CLI extensions to the C++ language, so you'll, in essense, need to learn some extra language features in order to use this. Doing so gives you many "extras," such as access to the .net libraries, full garbage collection, etc.

ATL & MFC are somewhat trickier to decide between. I'd refer you to MSDN's page for choosing in order to decide between them. The nice thing about ATL/MFC is that you don't need the .NET framework, only the VC/MFC runtimes to be installed for deployment.

Using Win32 directly provides the smallest executables, with the fewest dependencies, but is more work to write. You have the least amount of helper libraries, so you're writing more of the code.

Merilee

Answer 2

Win32 is the raw, bare-metal way of doing it. It's tedious, difficult to use, and has a lot of small details you need to remember otherwise things will fail in relatively mysterious ways.

MFC builds upon Win32 to provide you an object-oriented way of building your application. It's not a replacement for Win32, but rather an enhancement - it does a lot of the hard work for you.

System.Windows.Forms (which is what I assume you meant by CLR) is completely different but has large similarities to MFC from its basic structure. It's by far the easiest to use but requires the .NET framework, which may or may not be a hindrance in your case.

My recommendation: If you need to avoid .NET, then use MFC, otherwise use .NET (in fact, in that case, I'd use C# as it's much easier to work with).

Learned

Is this comment still current? – Horizontal

For Visual Studio 2008, probably - that's a decade old now though. These days, for Windows, you're much better off using WPF. – Learned

Answer 3

As far as C++ goes, I would use WTL. It's lightweght and you will have few (if any) dependencies, making it easy to ship and install. I find it very satisfying when my app consists of a single EXE that will run on most versions of Windows, but this may not be a concern to you.

If you choose to go .NET instead, then C# is almost certainly the way to go.

More in WTL here:

http://www.codeproject.com/KB/wtl/wtl4mfc1.aspx

Hardfeatured

Would you still use WTL? There are no commits for 2016, yet. Source: SVN – Horizontal

@JanusTroelsen I would! Last release 18 March 2020 - version 10.1077! sourceforge.net/projects/wtl/files/WTL%2010/WTL%2010.0.10077 – Dorsal

Answer 4

I would be very curious as to why you would do this in C++ at all. Based on your brief description, C# sounds like a much more appropriate choice.

Just to elaborate a bit, look at the link you gave describing the C++ CLR. The top rated answer notes (accurately, in my opinion) that C++ is appropriate for "kernel, games, high-performance and server apps" - none of which seems to describe what you're doing.

MFC, ATL, etc are going to be supported in the sense that, yes you'll be able to compile your app on future versions of Visual Studio and run them on future versions of Windows. But they're not supported in the sense that there's not a lot of new development going on in the API or the language the same way there is in the CLR and C#.

Audiophile

Good question. It's part of a larger project that includes some other pieces that have to be in C++ for legacy- and vendor-related reasons. This part doesn't have to be in C++ but since there are other parts that do, and since this part is relatively small, I was planning to do it all in the same language. – Leporid

C++/CLI (/clr) can be very close to C#, if you like working in C#, but want/need to use C++. The main difference is some minor syntax things, and trying to avoid using standard C++ instead of the CLI calls. There is really no reason to avoid it. – Merilee

And that's not necessarily a bad thought process. However I still think you're best bet is to go C#, and P/Invoke into your existing libraries. If you were already an MFC guru, and this were just a small addition to your project, then yes it probably would make sense to continue in C++. Although even in that case it might make a nice opportunity to carve out some "practice time" with the .NET framework – Audiophile

@Clyde: My experience has been that the C++ interop layer is much nicer to work with, and much more expressive than trying to P/Invoke. If you're working with other C++ code, I personally use C++/CLI to do all of the interop. If the GUI layer is large, I'd probably use C# - if it was a small project, I'd probably just keep the entire thing in C++/CLI. C++ works great with the .NET framework - just as well as C# (there are a couple of things that are tougher in C++, but some things are MUCH easier in C++ than in C# when working with .NET). – Merilee

Answer 5

There is nothing wrong with CLR. Like others here I'd suggest C# but as you have reasons for sticking with C++ then using the .NET framework is several thousand times easier than messing with ATL/MFC if you're not already familiar with them (IMO).

It may be worth mentioning that if you're using C++/CLR then you're not really using C++ at all. C++/CLR compiles to CIL just like C#. I've never used it myself but I believe its purpose is to allow you to compile legacy code and make it easily available to new .NET code rather than allow new code work with old C++ executables. There are other methods of calling native code from .NET which, perhaps, you should explore.

Holster

If I have to use .NET library, I rather write in C# – Companionship

Answer 6

The modern (2021) answer to this question would appear to be to use C++/WinRT instead of C++/CLR (or C++/CLI or C++/CX... jeez Microsoft):

https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt

C++/WinRT is an entirely standard modern C++17 language projection for Windows Runtime (WinRT) APIs, implemented as a header-file-based library, and designed to provide you with first-class access to the modern Windows API. With C++/WinRT, you can author and consume Windows Runtime APIs using any standards-compliant C++17 compiler.

...

C++/WinRT is Microsoft's recommended replacement for the C++/CX language projection

It's basically standard C++ but the UI is defined with XAML.

Still though, as with the other answers, it would appear that using C# is really microsoft's favorite approach. C++/WinRT really looks like it's almost C# anyways.

Elisavetpol