MFC. 30 аргументов против

Ok, since you asked it, here it goes:

• MFC violates C++'s message passing mechanism: virtual methods no longer work, instead you have to search for a method implementation using message maps.
• if you use the Visual Studio of MFC wizard and something breaks, you are out of luck: it is very hard to fix things.
• window classes need double creation: first you create the C++ object, then the Win32 window. Extra work for no purpose, since you can not use the C++ object until the C++ window is created.
• MFC has no layout management. If you want to change text while the application is running, you have to adjust controls yourself.
• some controls must be deleted by deleting the C++ object, some other controls must be deleted by invoking DestroyWindow, some other controls must be deleted by both Invoking DestroyWindow and deleting the C++ object. Hence the application will most probably leak memory.
• DDX sucks. MFC does not use the Model-View-Controller pattern, so it is very difficult to do any meaningful editing of data structures through the GUI.
• MDI children forms can not have controls on them. You have to put controls in dialogs, and dialogs can not be MDI children, unless you hack the system.
• Win32 is not hidden at all. You have to look up Win32 constantly, even if you use a C++ library. You have to lookup every flag to pass to CreateWindow, for example.
• Toolbar objects are not controls. In order to place a combobox in a toolbar, you have to hack the toolbar, or superimpose the combobox over some unused buttons.
• changing tooltip text in toolbar buttons using code is almost impossible: almost everything crashes. You have to malloc string memory which is used by the tooltip structures, but the docs don't say when and how to free it, or if it is copied internally to some buffer.
• There is no MouseEnter and MouseLeave events. You have to fake them using a special function.
• the enabled/disabled state of tool buttons is checked only when the message loop detects no mouse and keyboard messages. Therefore it is quite possible to modify the state of a command to disabled, but the command will be shown enabled if the user does something that requires continuous mouse input.
• functions placed in message maps are not checked for conformance to the required function signature. I once had forgotten to declare a parameter, the compiler quietly accepted it, the debug version was ok, but the release version crushed. There are numerous ways to mess up message maps.
• Controls in tabs do not belong in the tabs, but in the form the tab is! that means you can not build tab pages with the UI designer, because controls have to be placed on top of each other. You can only do it with code.
• There is no way to do proper validation of input data in text fields. The text field class does not contain the sufficient methods to properly implement masks.
• there is not even a way to properly validate data on form acceptance: pressing the OK button does not generate any programmable event, it just invokes the OnOK function of the class of the dialog. If you place another control that must validate data(for example, Apply), the validation code in the OnOK method will not be invoked.
• there is no way to modify the system menu of a window unless you use Win32.
• Border type selection also defines the ability of a window to be resized(!!!).
• MFC not only does not use the MVC model, it doesn't even use callbacks: all controls are send to parent forms: you can not do any useful subclassing of controls in this way.
• menu items are not objects. If you expected to draw your own menu items by overriding a OnPaint method, you are out of luck: you have to use the horrible mechanism of owner-drawn menus.
• MFC inherits the horrible Win32 API where some functions regarding rectangles use one more pixel from the right and bottom side of the rectangle. For example, drawing a rectangle inside the coordinates {x=0, y=0, width=100, height=100} will actually draw up to x=100, y=100, thus drawing a rectangle of 101 pixels size.
• drag-n-drop is really difficult to implement, especially within a tree view. You have to use image lists, and then do the drag-n-drop manually (tree nodes are not recognized, you have to have code in OnMouseMove).
• thread objects are not automatically deleted when the thread ends, even if autodelete is true. Many leaks from this.
• the class Lock<t> does not lock the critical section, mutex or semaphore passed to it unless you pass TRUE to the constructor. Which is very silly, and costed me a whole week's trip to the contractor's country because the app was crashing, because I thought that Lock<cmutex> lock1(mutex1) locked the mutex automatically.
• GUI commands are delivered through the OnCommand messages, making most of the application a big switch statement on the command id. Some may not think this is a big deal, but when you have lots of commands, it is very boring to having to write a case statement for each new id. Plus it makes the application really slow.
• dialog controls are not classes, unless you map each win32 component to a class. You have to create the control in the UI, then map a member instance to the control. Triple work for achieving the same thing that other toolkits do in a line of code.
• non-control of the message pump loop makes it really difficult to write any good state-driven code that drives the GUI. You have to write new win32 message ids, post messages in the message queue, and any data the message has, must be put in another parallel queue, because the message queue only takes a WPARAM/LPARAM. Alternatively, you can place the pointer value of your message data in LPARAM, and hoping you remember the correct type afterwards.
• controls can not have parents other than dialogs or control toolbars. You can not nest controls.
• radio button frames are treated like tabs: radio buttons are not children of the frame, hence if you move the frame, you have to move the buttons as well.
• ids of radio buttons must be sequential, otherwise radio buttons will not work, because the API uses the range of IDs to deselect a radio button. Which means that, if you want to insert a new radio button later, you are screwed: you have to edit the control ids by hand.

Overall, MFC is very stupid. My first commercial project was with MFC. A horrible experience. Then I bought Qt and never looked back. MFC is a horrible hack meant to give C++ a bad name and turn programmers away from C++ and onto Visual Basic, which is proprietary. It is no coincidence that only Visual Studio 6 and prior versions use MFC. The Microsoft's flagship products (Office etc) do not use MFC at all (you can test that using Spy++: no AFX classes in other apps except Visual Studio).

Achilleas Margaritis 29 березня 2007 р.