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

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?

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.

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).

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

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#.

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.

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://docs.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.