win32 or MFC
-
I agree with the other replys which say that MFC makes it *much* easier to create GUI-intensive applications. However, sometimes you need your .exe to be as small and fast as possible and have as few external file dependencies as possible. IMHO, in those cases, "old school" WIN-API programming simply cannot be beat.
I'm surprised no one has mentioned WTL ...or even Windows Forms :-D cheers, Chris Maunder
-
I'm surprised no one has mentioned WTL ...or even Windows Forms :-D cheers, Chris Maunder
Windows Forms, hmmm, I would never mention those before VS7 (.NET) is released... - Anders
-
I have had this tugging feeling to ditch MFC recently. I never was a Win32 programmer, and had a hard time understanding plain Win32 in the beginning (I came through the ranks with BASIC->VB->Java->MFC). Now that I've been using MFC for a few years, I have started to realize that much of what I use in MFC is a (very) thin wrapper around Win32. I don't use Doc/View very often at all, and I would never use MFCs COM classes. Most of what I program are utilities. Also, I'm a shareware developer and I'm getting sick of the bloat that MFC brings with it (the same reason I left VB). I do think that, before I go completely to Win32, I will look at WTL closely to see how it works. It's my understanding that WTL provides an implementation similar to the GUI side of MFC, but without the Doc/View and without the bloat. (Yay, I hope!) -Mike Stevenson Owner, Liquid Mirror Software (http://www.liquidmirror.com) Owner, Shareware Junction (http://www.sharewarejunction.com) Owner, Internet Shopping Spree (http://www.internetshoppingspree.com/) Owner, I Hate Metallica (http://www.ihatemetallica.com/) CoderX@liquidmirror.com **************************************************** Get AnyWhere 5 Now! Copy, move and zip files, easy as one right click! http://www.liquidmirror.com/ ****************************************************
-
I have had this tugging feeling to ditch MFC recently. I never was a Win32 programmer, and had a hard time understanding plain Win32 in the beginning (I came through the ranks with BASIC->VB->Java->MFC). Now that I've been using MFC for a few years, I have started to realize that much of what I use in MFC is a (very) thin wrapper around Win32. I don't use Doc/View very often at all, and I would never use MFCs COM classes. Most of what I program are utilities. Also, I'm a shareware developer and I'm getting sick of the bloat that MFC brings with it (the same reason I left VB). I do think that, before I go completely to Win32, I will look at WTL closely to see how it works. It's my understanding that WTL provides an implementation similar to the GUI side of MFC, but without the Doc/View and without the bloat. (Yay, I hope!) -Mike Stevenson Owner, Liquid Mirror Software (http://www.liquidmirror.com) Owner, Shareware Junction (http://www.sharewarejunction.com) Owner, Internet Shopping Spree (http://www.internetshoppingspree.com/) Owner, I Hate Metallica (http://www.ihatemetallica.com/) CoderX@liquidmirror.com **************************************************** Get AnyWhere 5 Now! Copy, move and zip files, easy as one right click! http://www.liquidmirror.com/ ****************************************************
Ahh, finally someone in this thread with whom I agree completely. I have had similar programming experience, and a similar reaction to MFC. I actually started with OWL, but I don't remember that very well. Anyway, the MFC wrapper is definitely thin enough in places that often times it's merely a matter of ::LineTo(dc,x,y) vs. dc->LineTo(x,y). I still use mostly MFC now (sometimes ATL), but probably see the benefit of only a few features, such as message maps, CSocket, and debugging benefits (I actually couldnt really tell you what debugging features are MFC's and which are MSVC's). One of my gripes with MFC is that decided to have its own container classes, such as CList, CString, CPtrArray, etc., when the STL had already created list, vector, basic_string, etc., which I have found to be more useful and generally more type safe. If anyone knows why ms implemented its own container classes for mfc please let me know. But when all is said and done, MFC seems to be sufficently stable, reasonably intuitive, and quite possibly reduces production time in many projects. Also, I would think that a novice programmer might be more intimidated by win32 api than by mfc.
-
Ahh, finally someone in this thread with whom I agree completely. I have had similar programming experience, and a similar reaction to MFC. I actually started with OWL, but I don't remember that very well. Anyway, the MFC wrapper is definitely thin enough in places that often times it's merely a matter of ::LineTo(dc,x,y) vs. dc->LineTo(x,y). I still use mostly MFC now (sometimes ATL), but probably see the benefit of only a few features, such as message maps, CSocket, and debugging benefits (I actually couldnt really tell you what debugging features are MFC's and which are MSVC's). One of my gripes with MFC is that decided to have its own container classes, such as CList, CString, CPtrArray, etc., when the STL had already created list, vector, basic_string, etc., which I have found to be more useful and generally more type safe. If anyone knows why ms implemented its own container classes for mfc please let me know. But when all is said and done, MFC seems to be sufficently stable, reasonably intuitive, and quite possibly reduces production time in many projects. Also, I would think that a novice programmer might be more intimidated by win32 api than by mfc.
MFC was around before STL, so the container classes were a good thing. Now they muddy the water - do you stick with MFC since the rest of your team understand it and you code remains consistent, or press ahead and use the more powerful STL stuff? In some cases it's better to use the MFC implementations. One example is large maps. With CMap you can initialise the hash table and use a custom hashing algorithm, whereas std::map doesn't support this. In a map with 10000 items std::map can be an order of magnitude slower - yow!You could buy a more up to date stl implementation that has std::hash_map, or you could moan to Microsoft for not keeping their STL up to date :mad:
-
MFC was around before STL, so the container classes were a good thing. Now they muddy the water - do you stick with MFC since the rest of your team understand it and you code remains consistent, or press ahead and use the more powerful STL stuff? In some cases it's better to use the MFC implementations. One example is large maps. With CMap you can initialise the hash table and use a custom hashing algorithm, whereas std::map doesn't support this. In a map with 10000 items std::map can be an order of magnitude slower - yow!You could buy a more up to date stl implementation that has std::hash_map, or you could moan to Microsoft for not keeping their STL up to date :mad:
In VC7 we have hash_map...:-D Sorry its not there already. Walter Sullivan Program Manager, ATL/MFC
-
Ouch! I'm sure you like the pieces I designed...;^) Walter Sullivan Program Manager, ATL/MFC
-
In VC7 we have hash_map...:-D Sorry its not there already. Walter Sullivan Program Manager, ATL/MFC
Excellent! Is STL still licensed from Dinkumware?
-
Excellent! Is STL still licensed from Dinkumware?
Yes, it is. Walter Sullivan Lead Program Manager, ATL/MFC