Why does a swede call himself Norge?
Fantastic doctrines (like Christianity or Islam or Marxism or Microsoft-bashing) require unanimity of belief. One dissenter casts doubt on the creed of millions. Thus the fear and hate; thus the torture chamber, the iron stake, the gallows, the labor camp, the psychiatric ward - Edward Abbey
MFC - good or bad?
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
I really am norwegian, but i''ve lived in Sweden for 11 years now..=)
Everyone calls me just "Norge", and that''s why i use that nick.
Everyone calls me just "Norge", and that''s why i use that nick.
I use MFC for all my external config programs and whatnot, Its simple to slap togather an MFC project that dose something in a few mins. I look at it as the Visual Basic component for C++.
www.EberKain.comThere it is, Television, Look Listen Kneel Pray.
MFC is just a quick way of doing something complex at the cost of some serious overhead. In my opinion, its better to put together your own library of GUI objects and work off that. It''s cleaner but less standard (whatver "standard" means these days). A simple "Hello World!" program should run about 40k in win32... same thing in MFC is about 1.2 meg. That''s a lotta bytes to simply put 12 characters on the screen.
I''ll put it this way...
If I want to write a utility that the world may download (sumthin'' like WinAmp) then I use straight Win32.
If I need an editor for a game I''m working on and I need it quick, I use MFC.
- Jay
I''ll put it this way...
If I want to write a utility that the world may download (sumthin'' like WinAmp) then I use straight Win32.
If I need an editor for a game I''m working on and I need it quick, I use MFC.
- Jay
Quit screwin' around! - Brock Samson
yeah, I see MFC as the RAD tool for C++, its ok until you try to use more complex controls like CTreeView, CListView, and all those other controls that in lean and mean win 32 are already complicated, for game dev purposes, in my opinion, there is no need for MFC at all.
December 29, 2001 02:00 AM
The amount of misinformation in this thread is scary. Here are the facts:
MFC is a set of classes (and a few functions) provided by Microsoft to make Windows programming easier. Some areas it covers are basic class wrappers for Windows functionality (like CButton or CPaintDC), Doc/View architecture, stuff to make COM/OLE way simpler, a string class (CString), and some container classes (such as CList).
The only things really in common between STL and MFC are that both have strings classes and container classes. STL doesn''t offer any functionality regarding windows, controls, COM, etc. MFC and STL can be used in the same application. It''s not a matter of one or the other. Also, code can be written so that the core functionality of the program is pure C++/STL with the Windows-specific MFC code in separate classes/modules.
You can pick whether to dynamically link to the MFC DLLs or statically link the MFC code into your app. If you choose to statically link, you don''t have to worry about missing/wrong DLLs but the EXE will be larger. If you use InstallShield for building setups, there is an MFC runtime install object that makes installing the latest MFC DLLs on the user''s machine simple.
A "Hello World" app in MFC does not take anywhere near 1.2mb. The AppWizard generated "Hello from MFC!" takes 40kb linked to the DLLs, 100kb linked statically. My most elaborate MFC app, which uses MFC and STL extensively, takes up 500kb statically linked.
MFC is most useful for any app that works like a typical Windows GUI app with toolbars, menus, buttons, etc. It''s used in a lot of commercial apps, including many produced by Microsoft. In game development, it''s not that useful for the actual game (since the use of windows, controls, etc. is limited) but can be useful for tools like the game editor.
MFC is a set of classes (and a few functions) provided by Microsoft to make Windows programming easier. Some areas it covers are basic class wrappers for Windows functionality (like CButton or CPaintDC), Doc/View architecture, stuff to make COM/OLE way simpler, a string class (CString), and some container classes (such as CList).
The only things really in common between STL and MFC are that both have strings classes and container classes. STL doesn''t offer any functionality regarding windows, controls, COM, etc. MFC and STL can be used in the same application. It''s not a matter of one or the other. Also, code can be written so that the core functionality of the program is pure C++/STL with the Windows-specific MFC code in separate classes/modules.
You can pick whether to dynamically link to the MFC DLLs or statically link the MFC code into your app. If you choose to statically link, you don''t have to worry about missing/wrong DLLs but the EXE will be larger. If you use InstallShield for building setups, there is an MFC runtime install object that makes installing the latest MFC DLLs on the user''s machine simple.
A "Hello World" app in MFC does not take anywhere near 1.2mb. The AppWizard generated "Hello from MFC!" takes 40kb linked to the DLLs, 100kb linked statically. My most elaborate MFC app, which uses MFC and STL extensively, takes up 500kb statically linked.
MFC is most useful for any app that works like a typical Windows GUI app with toolbars, menus, buttons, etc. It''s used in a lot of commercial apps, including many produced by Microsoft. In game development, it''s not that useful for the actual game (since the use of windows, controls, etc. is limited) but can be useful for tools like the game editor.
December 29, 2001 04:52 AM
quote:
Martee:
Since when was the STL designed to be an enterprise-level Win32 application framework? And since when was MFC designed to be a collection of extendible, generic algorithms and data structures?
Right, and this is why I said ''Straight C++ and STL''. You use straight C++ OOP to create your own (efficient and clean) Win related classes by using the Win32 API, and use STL for all the generic container classes. Where is the problem ?
My point wasn''t that there''s anything wrong with straight C++ and STL. It was that comparing STL and MFC doesn''t make sense, because they are two completely different things.
ReactOS - an Open-source operating system compatible with Windows NT apps and drivers
quote:
Original post by Anonymous Poster
You use straight C++ OOP to create your own (efficient and clean) Win related classes by using the Win32 API, and use STL for all the generic container classes.
This is known as "reinventing the wheel". Which is all good and dandy if wheel design is your primary interest. However, for the people that wants a vehicle that actually goes somewhere, reusing the existing wheel design might be a better idea.
Fantastic doctrines (like Christianity or Islam or Marxism or Microsoft-bashing) require unanimity of belief. One dissenter casts doubt on the creed of millions. Thus the fear and hate; thus the torture chamber, the iron stake, the gallows, the labor camp, the psychiatric ward - Edward Abbey
--AnkhSVN - A Visual Studio .NET Addin for the Subversion version control system.[Project site] [IRC channel] [Blog]
" A simple "Hello World!" program should run about 40k in win32... same thing in MFC is about 1.2 meg. "
Take it out of debug mode man.
the last config program i wrote had one button and two sets of radio buttons, its about 20k.
Take it out of debug mode man.
the last config program i wrote had one button and two sets of radio buttons, its about 20k.
www.EberKain.comThere it is, Television, Look Listen Kneel Pray.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement