Assuming I am only using them for "normal" GUI programs (no COM, no ActiveX, nothing fancy), what is the fundamental difference I will see between ATL and MFC, to help me figure out which one to use?
I've done some searches on the web, but ultimately none of the answers really answered my question:
http://msdn.microsoft.com/en-us/library/bk8ytxz5(v=vs.80).aspx:
"ATL is a fast, easy way to both create a COM component in C++ and maintain a small footprint. Use ATL to create a control if you don't need all of the built-in functionality that MFC automatically provides."
Doesn't really answer my question, because:
I'm not working with COM.
Does this imply MFC isn't fast? Why/how?
"MFC allows you to create full applications, ActiveX controls, and active documents. If you have already created a control with MFC, you may want to continue development in MFC. When creating a new control, consider using ATL if you don't need all of MFC's built-in functionality."
Also doesn't answer my question, because:
I don't really even know what ActiveX is in the first place.
It looks as though Microsoft is discouraging the use of MFC, but I can't figure out why.
What exactly is MFC's "built-in functionality" that ATL doesn't provide?
In general, this doesn't answer my question because it doesn't explain the downsides and the reasons behind them.
because directly or indirectly, everything seems to link back to the previous page:
How do I decide whether to use ATL, MFC, Win32 or CLR for a new C++ project?
"ATL & MFC are somewhat trickier to decide between. [[No kidding!]] I'd refer you to MSDN's page for choosing in order to decide between them."
Obviously, this doesn't answer my question. :)
http://www.codeguru.com/forum/archive/index.php/t-64778.html
etc.
What I have currently observed (within the last couple of days, while trying to learn both):
ATL is based on templates, or compile-time polymorphism.
ATL methods tend to be non-virtual, and tend to return references.
MFC is based on virtual methods, or run-time polymorphism.
MFC methods tend to be virtual, and tend to return pointers.
But there doesn't seem to be any architectural difference between them:
Both use message maps (BEGIN_MSG_MAP vs. BEGIN_MESSAGE_MAP... big deal)
Both wrap Win32 methods into classes
Both seem to have similar classes CWnd vs. CWindow
But then, if there's no real difference except for the compile-time vs. run-time aspect, then why do both of them exist? Shouldn't one of them be enough?
What am I missing here?
I think the answer to your question is mostly historical, if you look back at how the two libraries originated and evolved through time.
The short answer is, if you are not doing anything "fancy", use ATL. It's great for simple user interfaces with COM thrown in.
The long answer:
MFC was built in the early 90s to try out this new language called C++ and apply it to Windows. It made Office like features available to the development community when the OS didn't have them yet.
[Edit embellishment: I did not work at Microsoft, so I don't know if Office was ever built on MFC, but I think the answer is no. Back in Win 3.1, Win 95 days, Office UI team would invent new controls, package them up in libraries, then the Windows and MFC teams would incorporate wrappers and API to those controls with redistributable dlls. I would guess there was a bit of collaboration and code sharing between those teams. Eventually those controls would make it into the base operating system in service packs or the next Windows version. This pattern continued with the Office Ribbon which was added into Windows as an add-on component well after Office shipped, and is now part of the Windows OS.]
At that time the library was quite primitive, both because of the C++ language and compiler being new, and Microsoft building it up over time as Office evolved.
Because of this history, MFC:
Has a fairly clunky design. It started as a light wrapper around the Windows API, but grew. There are a bunch of little 'features' that had to be invented because the compiler and language just didn't support them. There were no templates, they invented a string class, they invented list classes, they designed their own run time type identification, etc.
Encapsulates 20 years of Office and Windows evolution, which includes a whole crap load of stuff you will probably never use: Single and Multiple Document interfaces, DDE, COM, COM+, DCOM, Document Linking and Embedding (so you can embed a word document in your app if you wanted to), ActiveX controls (evolution of object embedding for the web!), Structured Document Storage, Serialization and Versioning, Automation (from early VBA years), and of course MVC. The latest versions have support for Visual Studio style window docking, and the Office ribbon. Basically every technology out of Redmond in 20 years is in there somewhere. It's just HUGE!
Has a ton of little gotchas, bugs, workarounds, assumptions, support for things that are still there that you will never use, and they cause problems. You need to be intimately familiar with the implementation of many classes and how they interact to use it on a decent size project. Delving into MFC source code during debugging is common. Finding a 15 year old tech note on some pointer being null causing a crash still happens. Assumptions on initialization of ancient document embedding stuff can affect your application in weird ways. There's no such thing as abstraction in MFC, you need to work with it's quirks and internals daily, it doesn't hide anything. And don't get me started on the class wizard.
ATL was invented as the C++ language evolved, and templates arrived. ATL was a showcase of how to use templates to avoid the run-time problems of the MFC library:
Message maps: Since they are template based, types are checked, and if you screw up the bound function, it doesn't build. In MFC message maps are macro based, and run-time bound. This can cause odd bugs, message routed to the wrong window, a crash if you have function or macro defined incorrectly, or just simply not work because something isn't hooked up right. Much more difficult to debug, and easier to break without noticing.
COM/Automation: Similar to message maps, COM was originally run-time bound using Macros, requiring lots of error handing and causing odd problems. ATL made it template based, compile time bound, and much, much easier to deal with.
[Edit Embellishment: At the time ATL was created, Microsoft's technical road map was mainly focused on 'Document Management'. Apple was killing them in the desktop publishing business. Office 'Document Linking and Embedding' was a main component to enhancing the 'Document Management' features of Office to compete in this space. COM was a core technology invented for application integration, and Document Embedding API's were based on COM. MFC was difficult to use for this use case. ATL was a good solution to make this particular technology easier for 3rd party's to implement COM and utilize document embedding features.]
These little improvements make ATL hugely easier to deal with on a simple application that doesn't need all the office like features of MFC. Something with a simple UI and some Office automation thrown in. It's small, it's fast, it's compile time bound saving you much time and headache. MFC has a huge library of classes that can be clunky, and difficult to work with.
Unfortunately ATL stagnated. It had wrappers for the windows API and COM support, and then it never really went beyond that. When the Web took off, all this stuff was sort of forgotten as old news.
[Edit Embellishment: Microsoft realized that this 'Internet Thing' was going to be big. Their technical road map changed drastically to focus on Internet Explorer, Windows Server, IIS, ASP, SQL Server, COM/DCOM in Distributed Transaction Server. So the Document Linking and Embedding was no longer a high priority.]
The huge footprint of MFC made it impossible for them to dump, so it still evolves slowly. Templates have been incorporated back into the library, as well as other language and API enhancements. (I had not heard of WTL until I saw this question. :)
Ultimately, which one to use is simply a matter of preference. The majority of the features you need are in the base OS API, which you can call directly from either library, if there is no suitable wrapper in the library.
Just my 2 cents based on using MFC for many years, and I use it now daily. I dabbled in ATL when it was first released on a few projects for a couple of years. It was a breath of fresh air in those days, but never really went anywhere. And then the Web came along and I forgot all about it.
Edit: This answer has surprising longevity. Since it keeps popping up in my stack overflow page, I thought I'd add some embellishment to the original answer I thought was lacking.
I have been told by many people who have used both that their programming experience was less painful with ATL than with MFC. Your compiled executable will also be much smaller with ATL.
I recommend you take a look at WTL, as it builds upon ATL.
What is that "extra functionality" they keep mentioning? Do I need it?
If you define your requirements, it might be easier to answer if you can avoid using MFC. Unfortunately "nothing fancy" isn't exclusive enough. Being inclusive as to which features you intend to use might be more helpful (which controls, which frameworks/technologies/existing libraries you want to use, etc).
But here's an article that describes some features in MFC that aren't directly supported by WTL/ATL.
MFC also has evolved to the point it supports a great many desirable features, such as MAPI, support for the other Windows logo requirements, sockets, documents (if you like and/or use that pattern), and compound document files. WTL has its share of cool features, but MFC is the clear feature champ. Both environments support framed main window architectures (frame window with separate view window), SDI and MDI applications, split windows, dialog-based applications, and various COM-based classes for COM support.
ATL is a set of classes meant to simplify the implementation of COM objects.
You can use it without MFC. At my job, we use ATL to expose COM interfaces to computational code. There is no GUI involved, it is for us to be able to call this computational code from eg. Excel VBA.
Look at some COM guide/tutorial to see what it abstracts.
MFC is just a set of GUI wrapper classes to the Win32 API. Look at some Win32 API tutorial to see what it abstracts.
Related
I'm interning in a company for the summer and I've to look at different ways of looking at the current codebase (C++,MFC, around 100K lines) and using state machines to model the current program.
I've been reading a couple papers and CPP2XMi looks like it may be some use to try to build sequence diagrams as a start.
The end goal is to gauge the feasibility of moving away from microsoft as an O/S and look at development (possibly in another language) on *nix.
I've also started looking at the MFC dependancies to see if we could just port the current C++ code.
I've had the program running through WINE and performance-wise, it seems acceptable but I still need to investigate other solutions as this will only work on X86 while we have other solutions running running on MIPS and ARM.
Any other ideas or caveats I could look at?
The first thing I would look at is where do I use mfc and other non portable stuff. If the only place there is mfc is in the interface layer for example you then can isolate the work.
If there is no such separation I would look at the fesablity of creating some sections of the code that are isolated and portable. Once you have a base of portability you can begin abstracting all of the services rendered by the non portable code. Any way you slice it though MFC to Nix is a big change and will require a significant amount of work. One other possibility is to see if you can run it under a windows emulator.
From reading through the wxWidgets book, it seems very similar to MFC. You might have a look at it.
I would first look into whether the GUI is separated from the rest of the application. With MFC, this includes limiting use of utility classes like CString to GUI-only code.
If the code is well-factored in this way, the easiest thing to do is probably to leave the MFC GUI code alone, and simply build a new GUI for your other platforms using the native GUI library of choice for each new platform. This will give a proper native appearance and behavior to the application that is really difficult to achieve any other way.
If the application logic is intermixed with the GUI code, it's a good time to ask whether you could devote resources to creating a proper separation, with the goal of doing the above once you've achieved separation. This is risky, from a business standpoint, because it can look like you have made a lot of effort and merely ended up back where you started. It isn't until you start work on the new GUI atop the refactored application that your sponsors see any real progress.
You can also look at portable GUI libraries like wxWidgets and Qt.
I have programmed for both MFC and wxWidgets, and they are conceptually very similar. I have never had to port code from one to the other, but I did once port from Borland's OWL to MFC, which was a similar experience. This sort of thing is not particularly difficult; it's just a grind. I can only recommend doing it when you have multiple reasons for dropping the old GUI library. For instance, perhaps you were also thinking of dropping Visual C++ entirely, or switching from Professional to Express, losing access to MFC. If you were planning on sticking with VC++ Professional (or above), it becomes difficult to justify throwing away your MFC GUI.
I once ported a big COM library from MFC to portable code. I used the STL and boost to replace all the MFC bits. For example, CString => std::string and VARIANT => boost::any.
It took forever, but it was mostly straightforward replacement and tweaking. Fortunately it didn't have any gui code-- it was a data processing library.
So, I learned C++ (fundamentals) and I want to write software, however I have stumbled upon a problem where I don't know where to get started. It seems like learning C++ was the easiest part by far when it comes to understanding the libraries for the GUI construction the concept I yet don't fully comprehend. I searched a lot and couldn't even decide been a new guy on MFC, Win32 or Qt.
Qt C++ GUI seems like a fun and easy to use software with the definitions of classes available right there quickly.
With Visual's MFC I am seeing a lot of code upfront on the pre made project file and a lot of description of classes, however getting definitions is a bit slower as I have to go to the internet.
Win32 is apparently written in C and is not updated much?
A lot of people recommend Java and C# as well, but I am not interested in learning a new language when I don't have C++ set in stone and practiced with enough yet.
Not sure how to go about this.
Go with Qt if you envision porting your program to platforms other than Windows and/or your actual UI needs are relatively straightforward. But Qt, being "fun," abstracts you away from the Windows API, so if you find yourself needing to access features of that API not offered by Qt, then you'll be up the creek. So go with MFC if you're staying on Windows and you're building an application whose complexity or Windows-specific features may require more direct access to the Windows API. MFC provides a thin abstraction layer over that API; its concepts map more or less one-to-one with the API's concepts.
What kind of GUI do you want? Any framework should be able to do any kind of GUI, but some are optimized for certain work:
MFC is optimized for making applications that edit documents, like MS Office programs Word, Excel, Powerpoint.
wxWidgets and Qt (and .NET WinForms and WPF) are optimized for any sort of app that primarily uses widgets (textboxes, buttons, menus).
SDL is optimized if you want to draw stuff, like graphs or vector artwork.
I wouldn't recommend that you use MFC since it isn't a good fit for most applications, and also doesn't use modern C++ design, it's loaded with workarounds needed for stuff that was broken in early versions of Visual C++ and now can't shake those workarounds because of backward compatibility.
The Win32 API is actually really useful to know regardless of what kind of application you want to make, because it defines the rules for how the UI interfaces to the rest of the system. Yes, it's written in C, but this is to make it usable from any programming language, not because it's an obsolete design. Win32 API is highly object-oriented and uses polymorphism extensively.
Few things you need to be aware of:
If one day you want to sell a program written using Qt you might need to purchase a license.
If you feel like GUI applications/ GUI programming is what you want to do in general, for windows platform you better learn WinForms or even better WPF (with C# of course).
If you just want to quickly put up simple GUIs for your C++ programs for learning purposes, and you don't care much about learning the frameworks and licensing issues, just go with Qt or wxWidgets.
MFC is outdated. If sticking with C++ on Windows, I recommend you to lean C++ CLI.
However I suggest you to learn c# directly since c# is the mainstream language in .Net world.
For GUI, the windows world is now dominated by WPF.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Gui toolkits, which should I use?
I've got a fair bit of C/C++ experience - mostly for writing console application for Windows/Linux, and also a fair bit of C# experience - generally for writing WinForms applications etc.
I'm extremely impressed with with ease at which I can create a window in .net, for example something as simple as
Form form = new Form();
form.ShowDialog();
is enough to get a blank form up on the screen. In fact,
new Form().ShowDialog();
is technically enough as long as we don't mind losing reference to the form after it's closed.
I've tried writing some windows-based GUI stuff in C++ using windows.h, but not only does the learning curve seem a little steep but also the syntax is extremely verbose. Creating a simple window like the above mentioned single line .net implementation can easily exceed 2 dozen lines using windows.h.
But not only that, if I were to port the application over to Linux/Max (something which I can pretty much never do with .net, with the exception of hacks like mono etc), then I would need to rewrite 95% of the GUI code.
I'm assuming this is where frameworks come in, for example QT etc... (I don't really know much about gui frameworks, I'm afraid).
What GUI frameworks do you recommend? which are the most powerful and which are the easiest to use?
How do you generally tackle the task of coding your GUI in C/C++?
The closer to the metal (so to speak) that you are programming, the more difficult things get. WinForms (provided by the .NET Framework) is a pretty outstanding abstraction over the Win32 API, considering the complexity you've already seen that it involves for the even the simplest of tasks, like getting a window to appear on the screen. All of that is still happening in the background, of course (registering a window class, creating the window, etc.), you just don't have to write the code yourself.
It's interesting that you write off Mono as a "hack", but would consider a library like Qt. I'm really not sure on what basis you make the distinction. The Mono library is widely regarded as excellent when it comes to WinForms support. The biggest detractors are the same as Microsoft's own CLR implementation, namely that it doesn't produce truly native code, which is more irrelevant to performance in the majority of situations than one might think. Beyond that, some complain that Mono applications don't conform fully to the platform's UI guidelines (that is, they don't look and behave exactly like a native application would), but I have a similar complaint about applications written using Qt.
It seems like literally everyone recommends using Qt if you want to do GUI work in C++. As I mentioned above, it happens not to be my favorite library because I'm a stickler for using fully native controls and widgets provided by the platform you're currently running on. I understand that Qt has gotten a little better at this recently, but I still don't think it's up to my standards. If you're more flexible than I am (and I'll warn you that the average Mac user is not any more flexible than I am), and true platform independence is a big concern to you, it's probably the one you should opt for. Many people praise it for its design elegance and convenience, although I seriously doubt that even it offers the same simplicity as the .NET Framework's implementation.
If sheer simplicity and terseness of code is as important as the beginning of your question makes it sound, I highly recommend sticking with C# and WinForms. Things get harder as you start to remove layers of abstraction, and if you don't need the extra levels of control that doing so affords you, there's hardly any justification for making more work for yourself. Mono's Forms implementation is a perfectly viable solution for cross-platform applications, assuming your needs are relatively modest.
Beyond that, if you want to create a truly cross-platform application in C++ the right way, I recommend that you strictly separate your data layer code from your UI layer, and then write the UI using the tools provided by each platform you want to support. In Windows, your options are relatively open: .NET WinForms is a solid choice, native Win32 is a somewhat painful though merited option, and a handful of other libraries like MFC and WxWidgets can help to ease the pain of fully native programming (though not nearly as well as WinForms does). On the Mac, the only real option is Xcode, Interface Builder, and Objective-C, targeting the Cocoa framework. Linux/Unix-based systems are hardly my forte, but I'm given to understand that Qt is about as native a library as you can get. This sounds like more work than I think it is—a well-designed library should handle 80% of the work, leaving only around 20% that you have to do in implementing the UI. Beyond using truly native controls and widgets, I think the other big advantage afforded by this approach is flexibility. Notice how Microsoft Word looks very different (despite some superficial similarities) on Windows than it does on the Mac. And iTunes has become almost a paragon of excellent UI design on the Mac platform, but sticks out like a sore thumb on Windows. On the other hand, if you rolled out something like Windows Media Player on the Mac (and yes, it's been tried by Microsoft themselves, though without much success), Mac users will dismiss it as a complete abomination and probably be somewhat offended that you even tried. Not so good for the truly cross-platform-minded developer. All of that to say, if your app is anything but the simplest of utilities, you'll probably find that an entirely different interface is justified (and even expected) on each platform that you want to support.
No matter how great Qt may be, you're not going to get that with it.
Qt, hands down.
it's the most complete, most mature, fastest framework available. and on top of it, it's seriously multiplaftorm and your choice of commercially friendly open source or paid support.
Is it true that "Nobody should be using MFC any more"
And why is that?
Arguably, no-one should ever have used MFC (speaking as someone who has been exposed to it since MFC 1.0). There were always better technologies around for GUI development, from Gupta's SQLWindows and Borland's Delphi to Microsoft's very own Visual Basic. And nowadays we have .NET or, perhaps more MFC-like, Qt.
MFC itself was a series of hacks,and often wilful misuses of the C++ language. Of course, if you have a big MFC project, you are probably stuck with it.
No, it is not true. Statements like that are always wrong, because for every project and every situation you have to evaluate the libraries and languages again. And simply discarding MFC for no good reason is wrong.
Even though MFC has been around for years and a lot of people don't want to use it anymore for new projects, it still can be the best choice depending on the project. Yes, .NET and it's UI libs are in most situations the better choice for new projects today. But if you want a small memory footprint, very fast startup time or your app has to run on very limited computers, MFC still can be a good choice.
For example, Netbooks (or whatever you want to call them) are popular, and not all of them have the .NET framework installed. And those who only have 512MB-1GB RAM, you might not want your app to use that framework.
And of course, there are other non-.NET libraries besides MFC you could use. But MFC is still a good choice.
It is just an older technology: there are newer, shinier technologies out there that are far easier to use...
It's slightly hard to see a good reason why a new project would use MFC/C++ ... unless it is the technology a dev team knows. A team experienced in C++ & MFC who jumps wholesale into .NET/WPF on a new project is going to lose a lot of time.
Joel wrote a good article on this way back (I think), but I can't find it. Basically, you need a business reason to switch technology. "It's old and ugly and we want to be cool with WPF" is not a business reason.
Some days I feel a little like Paul Bunyan in the sense that I'm swinging my MFC Ax and taking down lots of trees only to see those new fangled chainsaws show up. Everyone says how much better the chainsaw is, so i learn to use the chainsaw and I start cutting down those trees, and then the feller-buncher shows up, and everyone says how much better the feller-buncher is, so i learn to use the feller-buncher and I cut down more trees.
I'm not saying the AX is better than the feller-buncher - its not - but if you already own the ax, and you already know how to use the ax, and all you need to do is cut down a tree...
Sometimes the devil you know is better than the one you don't.
FWIW - just about the entire Windows SDK is predicated on a macro; its almost like #ifdef and #define are an entire development language in of itself.
If you watch the Project Centennial talk from Build 2015 it shows Adobe still using MFC in their Adobe products. They are using mfc100 from VS2010 to make a UWP app from Win32/COM/MFC components, so MFC is still being used.
Until Microsoft provide a C++ UI Framework with the UI elements that desktop apps use Ribbons/ToolBar/Menus/Dialog etc, then MFC might still remain popular even with all its quirky bits.
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://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.