Thread: Thoughts on MFC?

  1. #1
    Registered User cstryx's Avatar
    Join Date
    Jan 2013
    Location
    Canada
    Posts
    123

    Thoughts on 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?

  2. #2
    Registered User
    Join Date
    Dec 2013
    Posts
    241
    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.

  3. #3
    misoturbutc Hodor's Avatar
    Join Date
    Nov 2013
    Posts
    1,791
    Quote Originally Posted by Dave11 View Post
    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 Qt

  4. #4
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by Hodor View Post
    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 Qt
    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?

  5. #5
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    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);
    //}

  6. #6
    Registered User cstryx's Avatar
    Join Date
    Jan 2013
    Location
    Canada
    Posts
    123
    Quote Originally Posted by brewbuck View Post
    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.
    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.

  7. #7
    Registered User
    Join Date
    May 2010
    Posts
    4,633
    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.
    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.

    Jim

  8. #8
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    Quote Originally Posted by cstryx View Post
    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);
    //}

  9. #9
    Registered User cstryx's Avatar
    Join Date
    Jan 2013
    Location
    Canada
    Posts
    123
    Quote Originally Posted by jimblumberg View Post
    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.

    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.

  10. #10
    Registered User cstryx's Avatar
    Join Date
    Jan 2013
    Location
    Canada
    Posts
    123
    Quote Originally Posted by brewbuck View Post
    If you cared about code size you'd be using .NET
    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.

  11. #11
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by cstryx View Post
    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.
    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?

  12. #12
    Registered User cstryx's Avatar
    Join Date
    Jan 2013
    Location
    Canada
    Posts
    123
    Quote Originally Posted by Elkvis View Post
    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.
    Sure, but hard drives aren't the only means of storing portable programs. What if I want to maximize the usage of my USB key with programs to use as tools? I know you can get 1TB USB keys now, but who wants to spend $1000 on them? And because they are so small, what if I lose it or want to let someone borrow it? I'd be much happier to lend out a cheaper 4GB or 8GB USB than my expensive 1TB. Plus, 2/4/8GB are all much more common than 32/64GB or higher.
    Last edited by cstryx; 11-04-2015 at 09:20 AM.

  13. #13
    Registered User
    Join Date
    Dec 2010
    Location
    Trinidad, CO (log cabin in middle of nowhere)
    Posts
    148
    I've been doing WinApi about since it came out. Still doing it. Its about 2nd nature to me.

    I don't know how anyone can say one should do .NET if one doesn't want dependencies. .NET is a major dependency. Don't know how many megabytes, but its a lot - depending on version.

    The fellow who said MFC s**** is right on the mark. If there's one thing I hate its wrapping lower level functionality in such a way that it accomplishes nothing more than the original and adds to code bloat.

    If all you want is really simple utilities that you click a button and some code runs that does something useful, then Windows Dialog Engine bases apps are OK. Personally, I wouldn't use them, but that's just me.

    I do the WinApi thing because cross platform isn't a requirement for me. I just do Windows at work and for pleasure.

    What most C++ coders don't really understand is that using the WinApi is C based OOP. It doesn't have some of the syntactic sugar C++ class based stuff has, but it is very good OOP and it can produce smaller code than you can get any other way. Let me just give an example. One of my major apps has an exe and a required dll. I put my own string class in the dll and exported it, along with several grid custom controls. The dll has about 4000 lines of code and compuiles to about 54 K release build which I can compoact with UPX to 23K.

    The main exe has about 19000 lines of code in about 16 *.cpp and *.h files. It compiles to about 221 K and with UPX compacts to about 57 K. There is about another 17 K in four or five other support files (*.txt) the program needs. So this massive program with years worth of work and about 20000 lines of code comes to less than 100K.

    I realize nobody cares about sizes anymore and hard drives are infinite. Doesn't matter to me. I care. That's just the way it is.

    So if your use scenario is anything like mine, I wouldn't rule out WinApi. If I were to move to something else (I'm not) I wouldn't do MFC though. I tried that years ago and hated it.

  14. #14
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #15
    Registered User
    Join Date
    Dec 2010
    Location
    Trinidad, CO (log cabin in middle of nowhere)
    Posts
    148
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. thoughts
    By laasunde in forum C++ Programming
    Replies: 5
    Last Post: 06-26-2003, 08:38 AM
  2. UML and C++: Your Thoughts
    By Mister C in forum C++ Programming
    Replies: 5
    Last Post: 03-16-2003, 12:56 PM
  3. What are you thoughts?
    By hermit in forum A Brief History of Cprogramming.com
    Replies: 2
    Last Post: 10-06-2002, 06:10 PM
  4. more thoughts....
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 11
    Last Post: 05-07-2002, 02:34 AM
  5. thoughts
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 27
    Last Post: 04-29-2002, 10:00 PM