if you’re a c++ programmer, would you go for the Win32 API or .NET to develop GUI applications?
Share
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
if you’re a c++ programmer, would you go for the Win32 API or .NET to develop GUI applications?
Win32 is an API (Application Programming Interface). So is .NET. So is POSIX. The first two have GUI toolkits integrated into the main API, but you can use other toolkits such as Qt (as suggested by Skildrick) or wxWindows instead if you choose. For *nix, the main API is POSIX and almost all of them use X11 as the low-level graphics layer, then you need some GUI toolkit on top (none is integrated into POSIX). Depending on the type of displays you want, OpenGL is another very good highly portable GUI toolkit, though it focuses on high-speed vector graphics rather than UI widgets.
One good reason for using the Win32 API’s integrated GUI toolkit is that many of the other parts of the Win32 API use it, e.g. WSAAsyncSelect and MsgWaitForMultipleObjectsEx are non-GUI functions which are integrated into GUI message processing. A good wrapper toolkit will give you enough control to continue using these, but few do since this approach is very different with non-Windows OSes and most alternative toolkits value portability above capability.
Even .NET, which is designed from the ground up to run optimally on Windows, can’t use asynchronous procedure calls or waitable timers from a UI thread, since none of the message processing in .NET uses MsgWaitForMultipleObjects. So you end up forced to use multiple threads and a ton of yucky synchronization code.
But stay away from MFC. It is basically an academic exercise in implementing exceptions without compiler support, not the kind of framework you want for serious applications. Most of the other “features” got added after modern C++ design was much better understood but continue to use the dangerous messy style started by the early hacks on exceptions and virtual inheritance in the name of keeping things consistent. There are much better choices available today.