Topic: Thoughts about MFC
All resulted more low, it personally my reasons on library MFC and concerning a place of the given product in the modern world Besides, here: http://rsdn.org/forum/cpp.qt/6769008.1 the Author: MasterZiv Date: 27.04 18:21 I promised to companion MasterZiv to return to a subject of arguing MFC (only already in the given section, instead of in section on Qt). I started to be engaged on MFC in 1999. I will more precisely tell that it was the first class library mastered by me. After it was: a Borland C ++ Builder (VCL);.NET (C#) and, at last, Qt. Therefore - like as is with what to compare. However - to compare C# and MFC it is somehow illogical (different host languages), therefore we leave only that on a C ++ I will in passing note that I apply to some projects MFC and for today. ADVANTAGES: 1) Legkovesnost. As MFC is rather small object-oriented (however - about it hardly more low) a superstructure over WIN API it weighs at all much. To the modern measures - practically anything. 2) Intuitive clearness of library MFC for the developers owning WIN API. Class library MFC represents a dial-up of classes and methods for those entities which make a basis of window interface Windows that simplifies understanding of the entities defined in library MFC. 3) Great volume of operating time - as on the Internet (codeguru, codeproject etc.) And in old repositories of developers, therefore - possibility quickly to receive the answer (including here again - on ) on the most various aspects of application. 4) for the simplicity account, thanks to presence of source codes and already specified operating time - big (possibility to make that the left heel of the Customer wants). 5) it is necessary to mark that MFC develops (truth extensively) - MFC Feature Pack to develop applications with modern enough GUI. That fact that in MSVC2015 returned MBCS - Multi Byte Character Set (which already threw out from MSVC2013) - also undoubtedly testifies to some popularity MFC today. LACKS (as always - an underside of advantages): a) for today, it appears to make simple enough things completely not simply. Certainly, if worked with MFC many long years an output you will find. But it already another story altogether So, for example, ComboBox as a part of a toolbar: in Qt some lines; On MFC - a heap of the code All right, we leave GUI. We look towards support of popular DBMS. However, here the pattern and that is worse. If VCL and Qt have decent support of a DBMS, for MFC - it is necessary to search and adjust different to fulfill completely not difficult SQL request. b) the C codes ++ projects on Qt are much more readable and are laconic, rather than on MFC. Programming on MFC, the developer is always connected to superfluous (technical) entities which would be possible to carry out from the application-oriented code. Even simple dialogue application (without Doc/View), abounds unnecessary in 99 % of situations with entities. So, calls DDX_Control (...) Abounding in DoDataExchange - also on are represented to me by superfluous technical entities. c) transfer of a ready class from old in the new project is for MFC also dancing with a tambourine! If I want to transfer a window (in sense - successor CWnd) files (*.h) and a source code (*.cpp) it appears explicitly insufficiently. It is necessary ' to pick out ' both resources, and identifiers of resources and pens to transfer them on a new place. The conflict on identifiers of resources is a separate problem, there is no its desire to concern, will simply mark - that it is and spoils life of the developer (as always at the most inappropriate moment). In Qt, and in VCL, transfer is a simple copying of files then them we register the project - and we would forget about it! d) archaic architecture Doc/View (Document/kind) also enters superfluous, absolutely irrelevant essence for the XXI-st century. If in 1990, for the text editor it was actual, now is simply superfluous essence on which nevertheless, all library MFC is fastened. This complication which simply should be bypassed in the modern projects - , empty document class - is simple for support Doc/View e) Concept of OOP in MFC any vague. I admit that for 1990 it quite even it was normal. For example - the pattern observer for handling of messages is implemented by macroes BEGIN_MESSAGE_MAP/END_MESSAGE_MAP This decision in style old kind ANSI a C, but in any way in style of the modern C ++ If I in a dialog box (studio means) add new , this new member a class...... With any it is declared as public - instead of private (or at the worst protected). That fact that the abstract classes in MFC are not interfaces, and contain implementation, also represents retreat from ideas of normal object-oriented design. I perfectly understand that there are requirements of compatibility with the old code, but after all could enter, along with support old, and any new variants - corresponding to a today's level of development of technologies... Or M $ already was going to bury MFC the Output: application MFC for today makes sense in simple projects where ease is important. Quite often it is simple a dialog box with statically library MFC. Choice Qt is obvious To more difficult projects-. For old projects where to it MFC hundred years, also are not present possibilities/finance to pass to something new, application MFC also is actual. I thank all who had enough patience to read up to this line! And even more I thank those who expresses the thoughts in the given occasion!