C++ Builder or Visual Studio for native C++ development? - c++

I've decided I want to get more into native code development with C++. I'm trying to decide if I would be better served using CodeGear C++ Builder 2009 or Visual Studio 2008. I currently use Delphi 2007, so I'm very comfortable with C++ Builder's IDE (its the same as Delphi), as well as the VCL and RTL.
I've never been a big fan of MFC (from the first time I played around with it in the VS 6.0 days), but haven't taken a close look at it since then.
I'm interested in hearing from some experts that have experience with both IDE's, whether they are the most recent versions or not.
Right now, I'm leaning towards C++ Builder because I believe the VCL is much more robust and easier to work with than MFC --- but as I said, it's been a while since I've used MFC. I'm not interested in building programs that rely on the .NET Framework because I'm partly teaching myself native development. Is MFC still king for Windows C++? Or is WTL or ATL the big thing?
Any C++ gurus out there want to share their opinions?
EDIT: I understand MFC is not the only gui toolkit for Visual Studio. However, I'm looking for some recommendations based on GUI toolkit + IDE. For C++ Builder, there is only 1 real option, which is C++ Builder + the VCL. For VS 2008, it's VS + MFC/ATL/WTL/QT....confusing for me since I don't know much about them.

Coming from Delphi, you'll find the VCL straightforward to use with C++ Builder. There are a few oddities, like C++ doesn't hide the fact that TObjects are all really pointers (which Delphi hides from you), and some things like array properties are accessed differently.
Two or three years back, I was looking for any way out of C++Builder, but now, with recent releases (and Embarcadero's purchase of Codegear), I'm happy with the product and the direction.
You'll find the number of string types and the assorted potential incompatibilities quite painful with C++Builder, but you'll get used to it! (std::string, char[], wchar_t[], TCHAR, AnsiString, WideString, UnicodeString and String to name a few)
Personally I'd vote for C++ Builder - because of two-way RAD and the VCL, although it may not be the best way of learning modern C++ idioms.

Visual Studio and MFC are not the same. I use Studio all the time and I avoid MFC like the plague. You can use WTL, ATL, Win32 or any number of libraries to create apps without MFC.

The simple answer is that for pure C++ development it has to be VC++.
To expand: as a pure C++ development environment you simply cannot beat VC++, the debugger is better, the IDE is superior (all IMHO, of course). I've used it to develop libraries that I then use from C++Builder because of these reasons.
However once you start into UI development, or anything that you can solve using the VCL or components C++B is the better choice. Compared to the VCL, MFC or ATL are horrible by comparison, and so that leaves you to use .NET, which is probably a better option, but not
I'm not sure that I'd recommend building a new product using C++B or Delphi based on the last few years of 'direction' from the vendors. However that appears to be changing for the better, but until a little more time has passed it is hard to tell how the promises translate into reality.

If you're doing pure C++ development on Windows then it's hard to beat VS. The compiler is fast, quite standards-conforming and produces well optimised code. The debugger is the best on any platform. The IDE is OK.
It's also clearly the most widely-supported compiler toolchain on Windows. Download any open-source project/library and, if Windows is supported, it's likely to have been built and tested using VS. Its popularity also ensures that it's the most useful to have on a resume.
What does Builder give you? A reasonable GUI library. Well, that's good but there are many other decent GUI toolkits out there (wxWidgets, GTK, Qt etc). Many are open source and cross-platform.
However, these days I find it better to restructure my applications to provide an API and then build the GUI on top of it in a different language. C++'s strength is not in GUI development. At least not today...
I'd choose - and recommend - VS over Builder.

I haven't used C++ Builder for years but on the topic of C++ debugging, Visual Studio 2008 is way out in front of other IDEs and previous VS especially if you use STL containers as it makes it very easy to inspect their content.
However, on the GUI side, C++ is now very much a second-class language for Microsoft. The way of the future is WPF and C++ is not supported as a XAML-friendly language: We will continue investing in C++/CLI to enable developers to expose native C++ assets to the managed world and vice versa. We believe that pure .NET development is done best using a .NET focused language such as C# or VB. Investing in C++/CLI will be mainly in the native-managed interop areas.
So, to create a modern-looking C++ GUI, your best option may indeed be VCL - if VCL continues to make such possible ;-)

C++ Builder is far superior than MS-VS when it comes to UI based development and Database oriented application. MFC sucks!! However VS has better debugging capabilities.

I second going for C++ Builder, given that you already know Delphi. MFC has not changed much since the VS6 days, so code written using MFC still looks like shit. However, VS has changed and is now quite a good IDE.
Also, keep in mind that C++ Builder is not stable as a product line. There have times in the past where it was not maintained/its future was not clear etc. So you're taking a chance if you want to build something that lasts.

Just for the hell of it, can we throw in eclipse to the mix as well?
I just found working in eclipse to be better than working in visual studio.
Unless you are using VS2008 with winforms, the gui support is through windows templates (typically from resources) which is old hat and you probably don't want to use. So the gui support in VS2008 isn't that special.
As for gui toolkit, perhaps see What is a good GUI/widgets toolkit

Well, you can use Eclipse + MinGW + Qt4 + QT Eclipse Integration and you get all of the stuff: debugger, visual GUI designer, etc.
Mind that Qt4 is dual licensed: Open Source and commercial license.
Also you can combine Qt4 with Visual Studio (even with Express) and use all goodnes VS gives you.
For me Qt4 is the way to go and VS over Builder.

I loved C++ Builder a couple of years ago. It was fantastic. It was a way better with its VCL than VS with its crappy MFC. Then things have been changing with every year.
Builder has been going down;
1. Builder hasn't been updated with any real functionality.
2. Borland abandoned the idea of rewriting VCL in C++ for use with Kylix and Builder
3. CodeGear mess and uncertain future of Builder put many people off the product.
VS has been getting better;
1. IDE has been improved a lot
2. Compiler from the least standard-compliant one on windows platform became the most standard-compliant (not counting GCC on MinGW of course)
3. .NET emerged and there was Managed C++ and then C++/CLI to make it possible to use this framework from within C++
We got new, strong players
1. Eclipse
2. Qt Creator
and new GUI toolkits
wxWidgets
Qt4 now has also open source license
To summarize; Builder is dead because Borland
was thinking Delphi is so wonderful they don't really need anything else to earn money
has fallen into Java hype and invested too much resources in it
didn't understand great power of C++ and instead stack to pascal, which has always been academic language with no real products created with it

Try Lazarus instead. Write once, compile many. Runs on multiple platforms. Anyone coming from Delphi and Kylix background will feel extremely at home with this RAD tool. As for future, it is open source with a strong community, development will carry on without commercial constrain.

When it comes to windows development nothing really tops Visual Studio. It is very feature rich and has an excellent debugger, not to mention the vast community of users to help you with any problems you may encounter. If a company's development tools for their own operating system weren't the best for it, I'd fear their status in the software world. But if you don't need the extra features and absolutely need a RAD tool with drag & drop (besides MFC) C++ builder isn't too far behind. Using the delphi environment prior is just an advantage for you.

The one thing about last C++ Builder by CodeGear - I mean 2009 version - is that its updates can really make you hate this IDE. After having installed the 2nd update, I found out that if/else block DOESNOT WORK PROPERLY. It can enter IF statement but cannot enter else one - and it doesnot depend on the situation - this language instruction simply stopped work at all. The time it took me to figure it out was about two or three hours - and I started to develop the needed win32 app in VS, I consider it is more reliable than the CodeGear product.
The 2nd feature I dislike that you can`t switch off Unicode support and have to use ANSI versions of win32 functions EXPLICITLY (e.g. SendMessageA(...)) which is very boring.
I barely meet the deadline to finish the job using VS2008.
It s just my experience, the choice to make is yours

For native C++ development I wouldn't want to use either C++ Builder nor VS. These IDEs are all optimized for the use with their frameworks.
I would rather choose Eclipse, Code::Blocks or Codelite. These IDE's are not optimized for any framework and you can switch between several compilers on severeal platforms.

2012 is Almost ending. I was a Borland C++ user and then swithced to VC++ 6.0. Recently there was a requirement ffrom a client who wanted a GUI end for their product and didnt want the dependency on .NET framework. so I explored the Embarcadero RAD Studio XE2.
When it comes to C++ RAD development, I think not even MSVC++ comes close to it. It was like a breeze. although I found problems when compiling templates. for instance if you define a functor and want to combine the constructor with the functor call you cant do it in C++B, you have to create an object and then call the functor seperately. There were other issues also as I could not fully compile Poco library.
I found the solution by creating the DLLs in VC++ and calling them from the C++B frontend. that gives the best of both.
I hope that Embarcadero catches up with the standards soon.

Related

What do I need to know before switching from Qt to Visual C++?

I've been using Qt since I started to learn C++. It was the recommended SDK by professor so I didn't try another. Now that I want to learn to use Visual C++, it confuses me what the differences between those two SDKs are. I grew quite comfortable with all the signal and slot stuff of Qt. I wonder if I can find similar functionality in Visual C++. If for any chance, is there any tutorial that teaches you how to work with Visual C++?
Qt is a user interface library written in C++, available on multiple platforms; Visual C++ is a Windows IDE produced by Microsoft. They aren't really comparable -- in fact, I'm pretty sure that, if you felt like it, you could develop an application in Visual C++ which used Qt.
If what you are actually thinking of is the native Windows UI library, that's called MFC (Microsoft Framework Class). It's about 20 years old (!!) now, and contains a lot of historical quirks (including the STRING one which Neel Basu mentioned above); unless you specifically need to learn it, I would strongly recommend that you learn something else instead. If you want to learn one of Windows' native UI libraries, WinForms and WPF are more current, but are based on .NET, not C++. If you want to learn another C++ based UI library, you might want to try out wxWidgets; like Qt, wxWidgets is cross-platform.
Yes there is the Visual C++ help and the MS documentation on MFC and other component frameworks that MS provides

C++Builder XE2 or Visual Studio 11, from a VB application

Here where i work, we develop ERPs using Visual Basic 6 (Source Safe), MySQL and Crystal Reports 8.5, but the result isn't good as we expected.
We are planning to migrate from those tools, to C++Builder XE2 and Oracle, with github.
What reports application can we use? Anything better than Crystal Reports? C++Builder supports Oracle well?
With Visual Studio (C++ and Oracle), will i get better results?
Thanks
Both compilers and IDE's have different strength's and weaknesses. Try look at the answers in this post as well: C++ Builder or Visual Studio
I like a lot of things in C++ Builder (and for that matter Delphi, don't rule that one out if you consider C++ Builder). Basically if you need to do som GUI development and you insist on producing native windows applications, C++ Builder and Delphi has huge advantages. The VCL framework is really great, and closely tied with the IDE (which is ironically also its greatest weakness). There are obviously frameworks that provide some of the same functionality as C++ Builder, but I have yet to see one that works so well with the IDE.
The problem with this however, is that you really choose a platform, that is difficult to migrate away from. Not only does the VCL framework add some Embarcardero only language constructs (which are by the way often really nice ones if you are into that stuff). But the VCL framework is also proprietary, and an Embarcardero only product.
I have the last couple of years had some worries about the future of C++ Builder, it has started lacking behind the competitors in the interface, coding tools, and definitely the compiler which is far from the competitors.
Delphi however is a product that seems to receive much more attention from the developers, it has received a 64 bit compiler, (C++ Builder still lacks sigh). Delphi also produces native applications, works with Firemonkey so you can produce MacOS applications, and is less likey to be discontinued any time shortly (my personal guess). Besides there is a possibility to switch to the free Lazarus/Free Pascal IDE, although I have not stayed up to date on that for a while.
Basically what it boils down to is, what your requirements are. What do you need of the programming tools, for RAD development, given you need native code produced (you seem settled on C++), I would probably go for Delphi/C++ Builder. Yet I think you should try it first, and preferably give Qt/wxWidgets a shot as well to see if you can settle with that (Qt can prove to be expensive though), and perhaps get a solution that will be officially supported for a longer time.
If you find that your requirements are not as much based on the rapid aspects of the development, and you are searching for something that will give you as a coder a better toolbox for coding, and expect more of your compiler, I would not go for the Embarcardero products.
As for the database integration I cannot say much about Oracle for either of the two, but generally I find that C++ Builder/Delphi handles database connectivity and development using data aware controls, extremely well. It is really one of the key strengths of an RAD tool.
So try the two in some thought scenario as also jszpilewski mentions.
You may download the 30-days trial edition of C++Builder and check it yourself. It offers easy access to the Oracle Database (in Enterprise or Architect editions) and bundles with Nevrona Rave Reports. Hence it all should offer a similar workflow to VB6 in an environment that knows more about Vista and 7. One interesting advantage over Visual Studio would be cross-compilation for Mac if you can use the new Firemonkey framework instead of VCL.

Using Embarcadero Borland

As I'm more and more dissapointed with VS 2010 I'm trying to find some alternative and I was looking at Embarcadero's new edition of C++ env.
Is there any point of learning new (not popular I think) product when VS practically dominates market?
Thanks.
Although I'm not really a Windows programmer, I have been using Borland/Embarcadero to-and-fro during the past 10 years. Here are my personal opinions of why you should not consider it:
The general quality of Builder has dropped significantly over the years. Borland Builder 6 was the last high-quality product, from there the IDE itself has become more and more buggy. The IDE typically crashes once per 1-2 weeks of usage.
No undo in the RAD design. Yes I know, it is quite unbelievable. Even the earliest versions of utter crap like VB had this. But Builder year 2011 doesn't! If you slip on your keyboard and accidentally alter a component, you shall be punished!
The debugger is next to useless. This might have been fixed in the latest version, but in several versions you can't single step through the program without collapsing struct/class variables in the watch window, which is of course very frustrating.
Documentation is very poor, often non-existant, and may be written in Object Pascal, even though you ordered the C++ IDE. The help files also have a tendency to linger as evil ghost processes in your computer, making it impossible to shut down Windows before the ghost is busted.
Personally I'm considering switching to Visual Studio.
I've been using both the Embarcadero Borland, now RAD Studio 2010, c++ and VS2008 every day for the last 6 months. My programming philosophy has always been to use the right tool for the project, no matter what that particular tool is. So a couple of my observations/opinions are -
Advantages
The WYSIWYG screen designer is good. It acts a lot like the WinForms editor in VS2008, but for c++. In VS2008, the only package for c++ that I've used that is close is Qt. My biggest compliant is documentation, but that applies to most software, so it isn't just their problem.
For many builtin classes, they are built on TObject class. This base class functions a lot like Object in C#. The biggest advantage this gives you as a c++ programmer, if you follow a few rules, is mostly automatic memory management. It's not garbage collection, rather, list of related objects that are deleted together.
Disadvantages-
The RAD Studio 2010 C++ environment exists primarily to support Delphi. That is their real strength anyway. Nowhere does anything say this. It is just an overall feel that I've gotten from using system.
Limited support for 3rd party libraries.
It cannot link with any Microsoft compatible c++ library. This includes both Microsoft and 3rd party libraries. They use a different "name mangling" format from Microsoft. So everything has to wrapped in a c language wrapper.
We use the Boost Libraries a lot in VS2008. But in Rad Studio, it only has limited support for Boost.
I've found the overall speed of the generated code to significantly slower than that produced by VS2008.
Please remember, that these are just one person's opinions.
I would suggest that you download a demo version of the product and try it for yourself.
If you want to be 100% up-to-date, you have to use the development environment provided by the platform's vendor.
If you do not mind waiting few months/years for new things to get ported over (or your market allows for it) then you surely you can venture into the unknown.
It's not that Borland's IDEs (unlike MS' VS family) needed any advanced training to start using them and be already productive. That is the main reason why they remain popular in many niches.

How does C++ builder stack up against other RAD IDEs?

It has been a few years since I did any development for PCs (I usually do embedded software).
At that time I was highly proficient with (Borland, now CodeGear) C++ Builder. Time has moved on, C++ Builder has become extremely expensive and there are alternatives (MSVC studio, NetBeans, QtCreator, maybe even Eclipse with the right plugins). Others?
Three things concern me (in no particular order), ease of use, additional GUI components and cross-platformness.
Ease of use - I want an IDE which helps, not hinders me. Good debugger, refactoring, jump to variable declaration, usage, that sort of thing ..
GUI components - when using C++ Builder I was impressed by how easy it was to develop additional VCL components and how many were available, often for free. Thus if I wanted a standard string grid where the cells also could contain pictures, checkboxes, etc, I could probably find one, or roll my own.
I am not sure what the current state of play is with respect to add-on components. Do other systems have anything like http://www.tmssoftware.com/site/ ?
Cross-platform - I personally use Linux for everything, but realistically, the majority of my users have Windows installations. So, cross-platform is "nice to have", "all other things being equal".
Now I have to pick a solution and stick with it for the next few years. Which one, given my points above (cost plays a role, but is not make/break)?
Thanks in advance for your help.
I have used both C++ Builder and Visual Studio.
Over the years I have always preferred C++ Builder over V.S.
Builder and VCL just feels much better designed than Microsoft's products.
(Even the Borland library source code just looks cleaner than anything
that comes out of Microsoft).
The integrated debugger in Builder is truely integrated and quite intuitive to use.
I find Builder compiles much faster than Visual Studio.
Builder 5 had a problem that made it unnecessarily slow,
but at the time it was still faster than VC++
and the latest Builder versions have faster compile times.
Accellerators such as TwineCompile make Builder even faster.
I've never tried to create custom C++ controls for Visual Studio,
but it is fairly easy to do in Builder.
Last year, CodeGear released a free version of TurboExplorer
(I haven't used it myself) which includes the IDE
and RAD (although limited) http://www.turboexplorer.com/
TurboExplorer can be used for commercial apps.
I have not been happy with Java based IDE's where are always slow.
I.e. SunStudio12 which is good (and free) but the UI is slow response.
I use Code:Blocks on Linux which has reasonable usability,
but haven't done any RAD work with it.
I never used C++ Builder but used to be a big fan/user of delphi. I normally work on server apps in c++, with some java. Reciently I started writing some small productivity apps for myself originally I used java, but then moved to Qt.
Now I love it. The library feels well designed just like vcl did in delphi. The signals/slots mechanism is great, I am still surprised how often I don't have to write code to wire up a dialog box. Using qt is easy and the code you write is very easy to read and create. I haven't yet had to write my own widgets, I think qt's model/view architecture splits the roles very well making the stock widgets very powerful. For example when using a QTableView most display and editing functions can be provided by the ItemModel, more powerful control is provided by an ItemDelegate. I have found these easier to reuse than writing custom widgets although it seems easy enough from looking at the documentation.
Qt creator is basic but does 95% of what I require, integrated project, gui designer, code, debug and help. Has support for CMake as well as qmake. It doesn't have advanced features like refactoring, but the intelli sense better than VS2005. However the next version of KDevelop looks very promising and will include these. You could also use eclipse if you wanted these features, or move between eclipse and qt creator as required. But I am very happy with qt creator.
On the cross platform issue, I develop my apps on Linux at home and tend to use them on windows in work. So far everything that works on linux works just work windows and looks like it was written for it too.
The strength of C++ Builder (and also Delphi) is the VCL GUI framework, it is easy to work with, and delivers true RAD development. There are a lot of alternatives to VCL which all have their strengths and weaknesses. The strength of VCL is the close ties with C++Builder/Delphi which makes it work very well with that combination. The downside is that it is propitiatory software, which means that you are unlikely to port your code to other IDE's or platforms without official support from Codegear/Embarcadero.
There is however some free alternatives out there, one of the more interesting being the Lazarus IDE. The Lazarus IDE is an IDE for the Free Pascal language, this is very similar to that of Delphi, I must admit that I am not a Delphi guy myself, so I am unable to go into too much detail about this. Lazarus have a GUI framework much like VCL called LCL. From the brief looks I've had on it, it looks very similar. There are several good things about the Lazarus/Freepascal package especially for your case. It is free, it can compile and build for both windows, linux, and mac, it has 64 bit support. Further more the compiler seems more modern than the Delphi one.
Lazarus running on Windows 7
Lazarus running on Linux (GTK2)
Lazarus running on Mac OSX
More screenshots can be found here: http://wiki.lazarus.freepascal.org/Screenshots
The problem with Delphi/C++Builder is that the VCL is not currently crossplatform capable. Although this is planned for future versions (as far as I recall) it is not yet implemented. Having noted that, there are some considerations as to whether the C++Builder will continue to be maintained or not, in here there is some comments on this: here.
Qt has been mentioned and it is indeed a very strong GUI framework and the Qt creator is a fine tool, personally though I like to have a very close bond between the IDE and the GUI framework like it is the case with the VCL, but that is very dependent on the developer.
Edit: Just a thought I had, when comparing C++Builder to other RAD IDE's it is easy to include IDE's for the .NET languages and Java. These use languages created for this purpose. C++ used in C++ Builder does, although in Borlands version slightly modified, not. This does raise an interesting question, is using C++ for RAD applications necessary and justifiable? Why not use a tool (language) that is written for the purpose. I am aware that C++ Builder is written for RAD development, but the language behind it was not designed for this purpose. If your need is truly rapidly developed applications, I would consider looking for other languages, but if you dependent on C++ for whatever reason, could be 3rd party libraries etc. Then C++ Builder is in the C++ world an excellent RAD development platform.
Short answer is NetBeans. It is cross platform, it is easy to use, although it is made-in-java but still it is fast.
PS: If you also do or intend-to-do programming in java, it will be convenient to use/learn this one IDE for both.
You can also use wxForms for C++ Builder and use wxWidgets to create cross platform applications. It works with the existing C++Builder IDE and make use of the same form designer.

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