I'm curious what the general thoughts are on MFC for C++ GUI (dialog) projects are? Good/Bad? Advantages/Disadvantages?
Is it even recommended for creating GUI applications or would you go with the Win32 API instead without MFC?
I'm curious what the general thoughts are on MFC for C++ GUI (dialog) projects are? Good/Bad? Advantages/Disadvantages?
Is it even recommended for creating GUI applications or would you go with the Win32 API instead without MFC?
Stay away from MFC like fire.
The original problem with Windows programing back then was that the API (WinAPI) was no intuitive enough. you really programmed something only make sense to the OS and not to the developer.
for example , in order to create a red window you should:
1. register a class name (about 10 lines of code)
2. prepare a general callback for every event that maybe be fired from the window (who does it these days?) with extremly obfuscated types like HWND, LPARAM, WPARAM
3. create a window
4. extract something mystical named "HDC" on the magical switch-case call WM_PAINT
5. use that mysterious "HDC" in specific time on a specific functions.
developing production product with WinAPI is hell.
so microsoft decided to wrap WinAPI with C++ classes to make everything more clear.
...aside that they did it *awefully*!
nothing became more clear with MFC, you still have to deal with obfuscated types like HWND,HDC, LPARAM, only you do it inside obfuscated classes like CWND..
so you get all the problems you had with WinAPI with the complexity of 1992-style-of-programing-C++.
why would you want it? there is awsome platforms out there with are also cross platform (the code can be compiled for every OS) like QT, wxWidgets, Juce and many many more.
I've never written an application using Juce but I've been involved with large projects (as well as my own smaller ones) using both Qt and wxWidgets and they really are a pleasure to work with (despite some oddities which all APIs and frameworks are bound to have). Both are great, but my current preference is QtOriginally Posted by Dave11
I used to enjoy wxWidgets, but because it was designed for pre-standard C++, it had issues that inhibited my ongoing development. I've since moved on to Qt, which seems to evolve with the standard a lot better.
What can this strange device be?
When I touch it, it gives forth a sound
It's got wires that vibrate and give music
What can this thing be that I found?
Nobody should be using MFC or Win32 directly any more. It's arcane and doesn't expose the full feature set of Windows in a usable way. I wouldn't use C++ in any form for UI code on Windows, it's just going against the current for no good reason.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Why not though? If I want something smaller in codesize then Qt or any other cross-platform framework is not going to be great, especially when I don't plan for platform scalability. Also, wxWidgets is worse than MFC IMO being that it's horribly documented and other reasons I've read on various articles. I'll source them later if requested. The problem I have with Qt is the amount of functionality it gives you, even if you only plan on using 10% of it. I'm not looking for a fancy UI either, just something that works, but I don't want to end up with having to carry a shared library around or have it statically linked and my program being over 1Mb for some small program functionality.
If you cared about code size you'd be using .NET
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
I already use .NET for specific projects but why would .NET be a solution for code size? Yes the frameworks exist on the Windows machines, but that means managed code and JIT-compilation unless you use .NET native. Additionally, the output size still isn't as small as I can get it with my native executables written in C or C++, and the performance of my non-.NET programs all have outperformed my .NET tests.
Last edited by cstryx; 11-03-2015 at 11:23 PM.
If performance is important (games, financial and scientific software), that's fine, but a basic "click here to do this tedious task automatically" type of program hardly needs to be concerned with performance. And with basically every computer being made with hard drives 1TB or bigger these days, size is virtually irrelevant.
What can this strange device be?
When I touch it, it gives forth a sound
It's got wires that vibrate and give music
What can this thing be that I found?
But MFC doesn't really save you in this regard, does it? To my limited knowledge MFC is a library that is contained in a .dll file or can be statically linked into your program. This dll (of the correct version) is not necessarily going to be on a target machine.but I don't want to end up with having to carry a shared library around or have it statically linked and my program being over 1Mb for some small program functionality.
Jim
It's more likely than Qt though to be on the target Windows machine IMO. Also my program is down to ~100kb after some configuration and modification.
Windows API has horrible complexity and takes lots of code just to do something simple. Don't use it.
Qt is also horrible because of their license. If you don't want to release the source, you'll just have to bundle all those hundreds of megabytes of Qt DLL files. Awful.
For those who say file size doesn't matter - well, I don't agree. First off, not everyone sits on 250 mbps down broadband connections. Some people even have old 56k modems. Tell them to downloads several hundred megabytes for a program. They're not going to do it. They're going to ignore your program. Period. Second of all, storage disks are not infinite. Yes, you're probably thinking of old hard drives which can be several terabytes. But a lot of computers these days store their programs on an SSD. These SSDs are typically 128 or 256 GB, but low-end computers have even less. There are models with 16/32 GB - pretty much just enough for Windows and nothing else! How do you think these people will react when your simple program takes up a lot of their space? Space matters!
For GUIs, if you're a windows person, I'd just use C# and target .NET 3.5 or so. It's included in W7, so only those who stubbornly sticks to XP/Vista have to download a dependency. I know of no good WYSIWYG GUI library for C++.
Last edited by Elysia; 11-05-2015 at 10:37 AM.
This topic should likely be in Windows Programming rather than general C++.
Your recommendation for new coders to go with C# Elysia makes sense. The only issue I take somewhat of an exception too is when some coder states that a goal of his/her's is to not have dependencies, and to produce executables of small size and fast load times, and then everybody jumps in and says 'whatever you do, don't use the WinApi because...blah, blah, blah', which, in terms of the user's stated goals, should be an obvious choice.
If the main arguement against the WinApi is complexity, I'd have to say in my opinion that's a bit subjective. I first learned C and the WinApi back in the 90s. Then I taught myself C++ and tried to learn MFC. I've got a whole bookshelf of books on MFC from all the top guns of that topic. I spent a good bit of time on it only to abandon it. I thought it was horribly complex. It seemed that not only did one have to understand the WinApi, but one had to integrate that knowledge within the context of C++ classes and complicated inheritance chains. And at that time there was something like a 1.4 MB MFC dll dependency. I eventually abandoned MFC, adopted C++ for my Windows SDK based application programming in lieu of C, and developed a bad taste for Class Frameworks in general.
Later I checked out wxWidgets, and seem to recall there was something like a 900 K dependency on that. Never looked into it any further, but have always been favorably impressed by the fact that Code::Blocks was coded with it (think I'm right on that).
I have given this issue a good bit of thought, and by 'this issue' I mean the apparent antagonism current C++ coders such as yourself have for coding directly against the Windows Api, and the conclusion I have come to is that newer C++ coders, who at least in the past were given a good browbeating about the superiority of OOP and classes to procedural coding, are not recognizing C based OOP when they encounter it in the Windows Api. When doing OOP in C one generally has a creation function to create an object based on some struct. That is what CreateWindow() in the WinApi is all about. In all function calls on the object the returned pointer to the object - for the Windows Api a previously mentioned HWND, will be the 1st parameter to the function call which manipulates the object; what in C++ parlance is the 'this' pointer. With such a 'this' pointer one can query the window object for sub-objects it contains, such as the also previously mentioned HDC - Handle To A Device Context - a graphiocal sub-object. And Windows is keeping track of all this for you at no code size cost to your application whatsoever, and whatever information you need about a window instance is just a funcion call away. And in fact 'enumerators' are present where one can dump all sub-objects. But I've noticed that a lot of newer C++ coders are weak on function pointers. I realize they are not needed as much in C++ as in C, where they were the foundation of creating objects in that language. But I fear most or a lot of this just is lost on C++ coders when they look at the Windows Api. In my explorations within the Linux world I have never found anything nearly so elegant as the Windows Api. The closest I've seen is XLib, but you can't really create applications with only that. GTK is C procedural based, but in my eye its simply ugly, and lacks the elegance of the Windows Api.
So when one creates Class Frameworks in C++ or any other language to 'simplify' Windows Desktop/Laptop/Tablet programming, all one is doing is duplicating functionality contained within the underlying C based Api. An application class will inevitably be created. If the application class has a textbox/edit control on it then that sub-object will become a member object variable of the application class. But the fact is Windows is already keeping track of all this for you and will gladly hand back to you a pointer to that sub-object edit control/widget whenever you want it. And none of this will cost you one byte in code size, but if your goal is to make it look like C++ and have C++ classes and objects, then you can really start adding up the lines of code and Ks in your binary - not to mention the C++ stuff which its now your responsibility to keep track of and not leak.
So in my opinion the best way to create Windows desktop/laptop/tablet applications is to use the Windows Api on its own terms for the GUI and windowing, and use your fancy C++ Classes and libraries for whatever functionality your application otherwise provides.
I don't think complexity is subjective. If something requires two steps instead of one to do something, I'd say it's more complex. Definitely measurable. Now, whether it's harder to use the first or second approach is subjective, as it depends on the programmer, experiences, etc. Nevertheless, as has probably been proven, more complexity equals more bugs and more code to maintain. Why would I create and register a class, then create a window with all its parameters when I can just, say, do:
CMyWindow Window?
You may be used to WinAPI by now, but why should I put new people through it when, for them, there are easier frameworks to work with (because less complexity)? If they don't need the additional flexibility provided by the WinAPI, why should they use it? This is basics of basics in programming: abstractions. Abstract everything. Then use the high-level building blocks to construct your program. So if you would use the WinAPI, you'd have to abstract it yourself and then use that abstraction. But why bother when others have done the work already?
