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.
Related
Are there any platforms to build GUI platform without resorting to QT or .NET using native C++ ?
QT is cool, but take a lot of time to learn, in addition it has a lot of things I don't really need and really dislike QT IDE, compared to Visual Studio (I know you can use QT within Visual Studio)
.NET suffers same problem (I am actually learning C# and WPF right now, though it looks like WPF is somewhat easier to program and you can call native C++ code from WPF)
I am looking for something that is: relatively easy learn, does not have to have advanced features, works with C++11, support C++11 multi-threading, works with Visual Studio. Planning to build some applications for Numerical analysis.
There are lots of alternatives with varying levels of support in VS.
MFC has quite a bit of direct support in Visual Studio in the form of code generators, Wizards, etc. Unfortunately, the basic design is very old and hasn't aged very gracefully at all. Quite a few programmers not only would but do cite it as a prime example of a library that's better avoided if humanly possible.
WTL is Microsoft's other class library for producing Windows applications. It's a much newer design than MFC and generally considered much cleaner and nicer. As implied by the name, it's heavily template based, which helps it produce applications that are generally considerably smaller and faster than MFC ever attempted. For better or worse, Microsoft placed it under a fairly permissive open-source license some time ago, and updates since then have been quite minimal. Despite both being from Microsoft, Visual Studio has never done much to support WTL development.
wxWidgets started as more or less a clone of Microsoft's MFC, but has continued active development while MFC has mostly stagnated. It now has quite a few features (e.g., XML-based UI design, layout managers) far beyond anything MFC ever even considered including.
Ultimate++ is a fairly unusual toolkit that has mapped its own route (so to speak) that's quite a bit different from most others. They have their own IDE (TheIDE). Code can be quite simple and short, but is enough different from most typical C++ that many people find it difficult to grasp at first (and some experienced C++ programmers don't particularly like how some thing work).
GTK+/gtkmm is less of a Windows framework than a Linux framework that's portable enough to also work under Windows. It's probably not your best choice if you're developing exclusively (or even primarily) for Windows. These are also much more purely GUI frameworks than most others (i.e., they don't include things like collections, networking, cryptography, etc., that many others do include).
FLTK is another cross-platform toolkit. Its fairly small and fast, but somewhat like GTK+, it seems (at least to me) less like a Windows toolkit, than a Linux toolkit that happens to be portable enough that it can also work on Windows (but the results don't look or feel much like most Windows applications).
Juce was originally used to develop some music software (Traktion) so it includes a lot of music-oriented functionality. It also have some fairly unusual widgets that most others don't include (especially widgets that imitate controls you'd see on all sorts of audio equipment). Nonetheless, it has a solid core of basic GUI functionality, as well as the usual "extras" like network, crypto, XML and JSON, etc. Although I haven't tried to do anything like a full review of the code, it appears to be rather better written than most.
That's not a complete list by any means, but I think it hits most of the more popular/widely used GUI toolkits (other than Qt, of course).
Some time ago I asked myself exactly that same question.
I wrote my program using C++/CLI, which was not bad (my C++ code was very well isolated from the GUI/CLI part), but sharing the executable with others was a problem: it was the typical - it runs in my PC(...only). So, I needed a light alternative to the user unfriendly command line programs in scientific calculations, which I could easily share.
I am now happy to use Nana. Please join the group of users and / or developers of Nana and... have fun!
GUI with Nana C++ Library
Nana C++ Library takes aim at easy-to-use and portable library. It
provides a GUI framework and threads for easy programming with modern
C++ methods, such as traits, metaprogramming and other template
technologies.
Since you plan to develop exclusively for Windows, I think you should stay with MS provided GUI toolkits. While third party toolkits may provide the cross platform advantage you already said don't need, they add complication and dependencies.
Complication by for example when a new Visual Studio is released, then you have to wait for the toolkit to get that new VS supported, and dependencies, which means more dlls to be installed on the target system.
Plus some toolkits do not use the native look of the operating system, like many java programs for example.
Is there any way to build graphical interfaces in the same rapid and easy way we could do in Visual Studio, but without .NET Framework? I'm looking to native Windows GUIs, so using Qt with Qt Creator is not an option (and it doesn't need to be cross-platform). Something with the Windows API using C++ would be great (not Delphi).
I mean, applications like WinSCP really have its GUIs written entirely by hand?
Given:
You don't want to use Qt
You want to use Win API
The natural option is MFC. It's basically quite a thin wrapper around the Win32 UI API, but VS has an MFC UI designer that will save you a lot of work (no need to manually set the co-ordinates of controls etc.).
My vote is still on Qt.
I suspect OP is really confusing "Native" with "deployable in a single binary". You can achieve this also with Qt by statically linking Qt dependencies. Contrary to popular belief, the LGPL does not prohibit this either.
Now if OP is looking for "deployable in a single super small binary" utorrent style, the answer would differ. A discussion around small binaries seems a good place to look. I would say there is a price to pay in increased development time though.
But I can't agree on Qt not being as native as say MFC.
Another excellent option is C++Builder with the VCL. This is very similar to WinForms (whose design it clearly inspired) and much more productive than MFC in my opinion.
As both Qt and MFC are wrappers around the native OS functions for managing windows and other OS utilities (that use Win32 API under the hood and look completely native) there is really no reason to consider the use of MFC over Qt, as it is not more native than Qt. Either your definition of "native" is broken or you haven't told us the whole story.
But there are a thousand reasons for considering Qt over MFC, as the latter is a complete pain to use, whereas the former is a cleanly designed, easy to use and still highly flexible library (that strives for nativity by any means possible).
The only way you might see MFC as more native is that it comes from Microsoft (the same company that developed Windows). But that doesn't make it more native. It's still a third party library. This third party worked for the same company as the party developing the Win32 API, but that doesn't make it specifically more tied to the Win32 API, as both were developed independently (and surely by different people).
Do Qt apps look and feel native under Windows?
You could also take a look at wxWidgets.
In addition to MFC, you might want to look into the Windows Template Library.
I am producing a piece numerical software in C++ and want to add a GUI (mainly for Windows). I know how to produce GUIs using comfortable editors in modern languages like Java or .NET. Now my question is what is the easiest and most comfortable way to add a GUI frontend for my program. In the choice of the tools am completely free (open source and portability would be nice), but please also keep in mind how much boilerplate code and interfaces that have to be maintained are required if the GUI is implemented in another language (Like C#).
Please don't suggest switching the whole project from C++! And note that the program does not require not much interaction between the C++ code and the GUI.
The statements about ISO C++ in this answer's comments are poorly edited. None of the solutions presented here would impose on the computational code a requirement of changing to a different dialect of C++. The GUI code itself might be another story.
The answers about using Windows Forms with managed C++ are probably the most practical. A lot of the UI-related code would be in a dialect (extension) of C++ where the .NET-garbage-collected pointers would be living alongside the traditional ISO C++ pointers. I haven't used this method but from what I read it might be better than what I have used.
MFC might be more practical if you don't want to invest in .NET knowledge for this task. It uses standard C++ constructs to wrap the Windows API. The Windows API uses a particular calling convention which C++ doesn't normally use, and it takes an extension to C++ to work with that, but this is no different than having a C++ program that calls some functions that are extern "C". Visual Studio has a GUI layout tool that is really good at layout of dialogs and at interfacing the dialog widgets to variables that reflect the state of the widgets. I've used this. If you can boil your GUI down to a dialog box then this would be a great option, otherwise you'd be using one of MFC's layout-managed windows.
Obviously the above options do not handle other platforms you might have in mind.
There are also various toolkits that were born on other platforms and have been decently ported to Windows. GTK, QT, FLTK, and WxWindows come to mind. I haven't used any of the dialog-layout/application designer tools that work with those, and I haven't used QT at all. When I last reviewed QT it had a special preprocessing pass for the GUI code. Other than that these portable tool kits are pure ISO C++ as far as I know.
As a really-out-there option one could program to the X Window System protocol using "libx". As far as I know this would involve no non-ISO C++ code.
Qt is a decent choice. It's stable, has a wonderful C++ interface (as opposed to MFC) and has a convenient designer tool.
The overhead of learning it from scratch might however be more that what you're willing to invest. It does have a certain learning curve.
wxWidgets would a good choice for a cross platform GUI for C++
As much as I love C++, it's difficult to build a GUI with. I'd build a quick C# WinForms application which would let you use things like Visual Studio's visual designers (Drag and drop buttons and such), and call your C++ application using P/Invoke.
C++ will often produce smoother and nicer GUIs, but it takes a bit more work out of the box.
If it's going to be just a simple GUI consisting mostly of standard controls I would do it with MFC. It may be outdated and was never really good, but it's still useful to get a native Windows GUI up and running quickly.
I have to chuckle at all the ways to skin this cat. Life is good. My response is a product I manage. XVT can do it for you. The easiest way is let us do it for you or give you a template to get there. It's just a matter of if you have more money than time. Then I'd look at us. It would be the fastest and least amount of effort on your part.
MFC Dialog Based application could answer the needs.
Depending on what you need, there's a nice imgui made by Mikko floating around that you can simply plug-in and use fairly quickly. It's done in opengl though so it won't be your standard windows-gui but it's really small and really easy to work with. You can download r'lyeh's version from here: http://code.google.com/p/colony9/source/browse/include/goo/imgui.h.
That's the easiest and most comfortable way I know, it is dependent on SDL though.
I have an application written in Delphi that compiles in Delphi 2007. I think it was originally written in Delphi 7.
Anyway, I need to convert all the core non-GUI code into C++ because I want to release a Mac version of the software.
What is the best way to do this? Any shortcuts I can take to speed up the process?
EDIT: The code compiles to native code, not .NET.
Simple answer: You simply can't port non-trivial Delphi code to C++ without a complete rewrite. C++'s object model is very different from Delphi's. It doesn't have a base class like TObject from which all other objects are derived, and it lacks support for a lot of the RTTI stuff that Delphi code often takes for granted. And there's no simple way to reimplement Delphi RTTI in C++, since a lot of it's done at the compiler level, and a lot of it's based on the fact that all Delphi classes descend from TObject.
C++ also lacks support for the concept of unit initialization and finalization sections that are so common in Delphi, and what it has instead is badly broken. (Look up the "static order initialization fiasco" for all the gory details.)
Delphi's exception handling is also much more advanced than C++'s. Part of this is the object model and part of it's compiler magic. Plus, C++ has no support for the try-finally construct.
If you want to port a Delphi project to the Mac, Free Pascal is your best solution. It's not 100% compatible with Delphi, but it's good enough for a lot of things, and you specifically mentioned that you don't need to port the Delphi GUI stuff. AFAIK the GUI area is the source of most of FPC's compatibility weaknesses, so if that's not necessary, FPC is probably pretty close to ideal for your needs, at least until CodeGear gets an OSX compiler out. (Which hasn't been officially announced, but based on various things that have been said it's not unreasonable to suppose that one will be available sometime next year.)
For converting your code from Delphi to Cpp, have a look at
http://ivan.vecerina.com/code/delphi2cpp/.
I used this to convert some of the classes and functions in SysUtils, DateUtils and StrUtils using wxWidgets functions. If you are planning to use wxWidgets for C++ have a look at http://twinforms.com/products/wxwidgets/wxvcl.php which has all the converted source.
If you want directly develop Mac OSX applications using then have a look at wxForms for Delphi - http://twinforms.com/products/wxformsdelphi/index.php
I think this would be difficult to do mechanically, so you are probably looking at a complete re-write. One thing to bear in mind is that typically Delphi uses try...finally structures for resource management, whereas C++ uses a technique known as RAII (resource acquisition is initialisation). You should read up on this and other C++ idioms before you attempt the conversion.
If your code compiles in Delphi 2007 into .NET assemblies, you may have a much easier option than trying to port from Delphi's object pascal to C++.
You could potentially compile your logic into .NET assemblies (and maybe even portions of the UI), and use Mono to run it on Mac. You could write a custom GUI around Mono, or even potentially make a single, platform independent application.
You can use also Delphi Prism. It's for .NET, but it's the last expression in Delphi language spec. It supports also Mac OSX (see the link). Also the guys from CodeGear/EMBT are in the works for a new compiler as well as for a new version of Delphi which is expected to enter in beta in April and narrow the gap between Prism and RAD studio. See their 'Beta Programs' page.
The "correct" way to do this is to rewrite it in Objective C. I find Objective C a little weird, but there are a lot of similarities with Delphi in the way objects connect and delegate.
You may be able to use Free Pascal to do it more quickly, but you should seriously consider a rewrite.
I would be in love with Embarcadero if they could release a Mac OS X version of Delphi that didn't, you know, suck like Kylix did. One can dream.
Edit: There is a great benefit to staying in Delphi, and having a separate version for the Mac in Objective C. First, it means you don't need to rewrite the version on Windows, losing the (presumably) years of investment in Delphi code. Second, Mac software operates differently than Windows, from a UI perspective. A simple port of the product is inappropriate, and hobbles the developer from using the great native features of Windows and Mac. See: older versions of MS Word for Mac, or iTunes for Windows. They look and feel wrong.
Are their any libraries which provide functionality similar to mono but for the c++ language? I know boost exists, but I like mono much more than boost.
I'm looking to do more than what's available in the base library set, like play sound more easily (crossplatform), GUI, load images, time, etc. I guess I am looking for what people might consider an engine or a large library.
Mono is a .NET implementation. Mono is NOT a library.
There is NO Mono for C++. At least, not yet.
I think you want a multi-platform framework, such as Qt
If you're wanting to work with Managed C++ a la .Net, then you would just use Mono. They have a page describing how to go about it. The only catch is that you have to compile on Windows, as there is not yet any flavor of GCC that outputs .Net CLI for C++.
To be honest, though, if you're going to use Mono, you might as well move into C#. It's a much cleaner language, IMO.
CLI is only able to host C++ compiled code on all supported platforms as long as the compiled code only contains CIL not native code.
for more detail visit
http://www.mono-project.com/CPlusPlus
I'm not sure about your precise requirements, but in terms of large multi-purpose packages: Qt has been mentioned by a few folks. wxWidgets (formerly wxWindows) is another option. GTK is multiplatform.
As you use the word "engine" (often a game-related term), you might be interested in SDL, which has been used by numerous games, professional and amateur alike. SFML is an option. ClanLib is another long-lived library I've heard of, though I'll admit to knowing little about it.
Try the STL collections...Has nothing to do with .NET, but they are a nice collection of collections (lol) and make C++ life easier.
It sounds like what you are really looking for is a C++ framework that offers the kinds of functionality found in the .NET/Mono framework. Qt is a popular choice.
On the topic of C++ interoperability, Mono has recently made some pretty big strides with CXXI.
(From this posting): The short story is that the new CXXI technology allows C#/.NET developers to:
Easily consume existing C++ classes from C# or any other .NET
language
Instantiate C++ objects from C#
Invoke C++ methods in C++ classes from C# code
Invoke C++ inline methods from C# code (provided your library is compiled with -fkeep-inline-functions or that you provide a surrogate
library)
Subclass C++ classes from C#
Override C++ methods with C# methods
Expose instances of C++ classes or mixed C++/C# classes to both C# code and C++ as if they were native code.
CXXI is the result of two summers of work from Google's Summer of Code towards improving the interoperability of Mono with the C++ language.