Class Libraries - MFC In Disfavor?
-
I've noticed a general increase in articles on CodeGuru, CodeProject and PlanetSourceCode where the primary feature of a given article is that the source code the article represents does not use MFC. The primary concern is "code bloat" which IMHO isn't as much an MFC problem as it is a programming knowledge problem, but the concern is there nonetheless. How many of you have been presented with projects where one of the documented requirements was "No MFC"? This is especially prevalant in COM/ATL projects. This leads me to the conclusion that there seems to be a groundswell of need for "something better" that makes better use of the C++ RTL. We are all aware that MFC is not nearly all that it can be, and even holds us back at times due to its weird little bugs, macro-choked code, and inheritance restrictions. IMHO, MFC should be more object oriented and provide a more substantial [thread-safe] wrapper around the Windows and C++ APIs. 0) Has anyone (or any group) ever given any thought to developing a new Windows class library that can replace MFC? 1) Is there enough free-range programming talent out here to tackle what seems to be an enormous task? 2) Could such a potentially large class library be made ready for prime time in a relatively short developement cycle? 3) Whatever happened to Owl, Turbovision, or Zapp? What class library is Borland C++ builder using now? 4) How would such a library be supported? Web-based? Standard windows help file? 5) Could any/all of the shortcomings of MFC and Windows be circumvented by writing such a class library? 6) Would we be any better off with a more RTL-oriented class library? 7) Could such a class library gain interest and support from other programmers and third-party companies? 8) Would Microsoft view such a project as a threat of any consequence to its dominance in the industry? 9) With the advent of C# and .NET, is there even any interest in such a project?
-
I've noticed a general increase in articles on CodeGuru, CodeProject and PlanetSourceCode where the primary feature of a given article is that the source code the article represents does not use MFC. The primary concern is "code bloat" which IMHO isn't as much an MFC problem as it is a programming knowledge problem, but the concern is there nonetheless. How many of you have been presented with projects where one of the documented requirements was "No MFC"? This is especially prevalant in COM/ATL projects. This leads me to the conclusion that there seems to be a groundswell of need for "something better" that makes better use of the C++ RTL. We are all aware that MFC is not nearly all that it can be, and even holds us back at times due to its weird little bugs, macro-choked code, and inheritance restrictions. IMHO, MFC should be more object oriented and provide a more substantial [thread-safe] wrapper around the Windows and C++ APIs. 0) Has anyone (or any group) ever given any thought to developing a new Windows class library that can replace MFC? 1) Is there enough free-range programming talent out here to tackle what seems to be an enormous task? 2) Could such a potentially large class library be made ready for prime time in a relatively short developement cycle? 3) Whatever happened to Owl, Turbovision, or Zapp? What class library is Borland C++ builder using now? 4) How would such a library be supported? Web-based? Standard windows help file? 5) Could any/all of the shortcomings of MFC and Windows be circumvented by writing such a class library? 6) Would we be any better off with a more RTL-oriented class library? 7) Could such a class library gain interest and support from other programmers and third-party companies? 8) Would Microsoft view such a project as a threat of any consequence to its dominance in the industry? 9) With the advent of C# and .NET, is there even any interest in such a project?
Actually, Yes. I have started work on just such a project as you describe. I call it the PIL, or Portable Interface Library (which is probably a very poor name, since it will likely expand to more than just user interfaces). My primary design goals are 1) To use a standard C++ class wherever possible over a custom class. (strings, lists, maps, whatever). This makes it much easier and more consistent for a developer to write code without having to use a proprietary class, or do constant conversions between standard and proprietary ones. 2) To promote a much more object oriented overall framework, while still maintaining a low-level flexibility wherever possible. This may involve the use of platform specific classes that get wrapped in portable wrappers. 3) Port the library to every conceivable platform (though this is a lower priority, and probably will not occur until the platform is much stronger, it still needs to be designed with platform independance in mind). 4) Take advantage of as many language features as possible (where they make sense), such as Templates, RTTI, STL, etc... This will have the side effect, that if the library gets very popular, MS will feel lots of pressure to more fully conform to the C++ standard. It can also provide a learning tool for junior developers to study for realistic real-world useage of language features. I've started a mailing list, and am currently hosting a page with source download on my personal web site. I intend to move this over to something like SourceForge eventually, but I want to make sure the license is nailed down properly before that happens. You can access the code and mailing list from http://www.visi.com/~erikf Be warned though, this code does not follow any of the principles outlined in this message. It's a bunch of bare bones Windows specific code that I originally modeled somewhat on MFC (about 4 years ago). It's my intention to use this only as a starting point and to morph this code into something much better. I invite anyone who wants to join the project to do so.
-
Actually, Yes. I have started work on just such a project as you describe. I call it the PIL, or Portable Interface Library (which is probably a very poor name, since it will likely expand to more than just user interfaces). My primary design goals are 1) To use a standard C++ class wherever possible over a custom class. (strings, lists, maps, whatever). This makes it much easier and more consistent for a developer to write code without having to use a proprietary class, or do constant conversions between standard and proprietary ones. 2) To promote a much more object oriented overall framework, while still maintaining a low-level flexibility wherever possible. This may involve the use of platform specific classes that get wrapped in portable wrappers. 3) Port the library to every conceivable platform (though this is a lower priority, and probably will not occur until the platform is much stronger, it still needs to be designed with platform independance in mind). 4) Take advantage of as many language features as possible (where they make sense), such as Templates, RTTI, STL, etc... This will have the side effect, that if the library gets very popular, MS will feel lots of pressure to more fully conform to the C++ standard. It can also provide a learning tool for junior developers to study for realistic real-world useage of language features. I've started a mailing list, and am currently hosting a page with source download on my personal web site. I intend to move this over to something like SourceForge eventually, but I want to make sure the license is nailed down properly before that happens. You can access the code and mailing list from http://www.visi.com/~erikf Be warned though, this code does not follow any of the principles outlined in this message. It's a bunch of bare bones Windows specific code that I originally modeled somewhat on MFC (about 4 years ago). It's my intention to use this only as a starting point and to morph this code into something much better. I invite anyone who wants to join the project to do so.
I'm not sure portability between platforms is viable (but it is a noble concern). It's been tried before and everyone ignored it because the platforms are so radically different - anyone here remember the Zapp library?. Of course, I was working on cross-platform apps back in the late 80's/early 90's when DOS apps were still being developed, Linux was just a gleam in Linus' eye, Windows was still living in a 16-bit-only world and OS/2 was being widely ignored by everyone. Now, there's two predominant camps - Linux and Windows (I don't count BeOS yet because BeOS doesn't have much of a following and it's still unclear as to whether it can find a large enough niche to become a concern). Does anyone still use OS/2 on a day-to-day basis? When a project like this is joined, philosophical differences of opinion can easily kill it or hamper its forward motion. How do you plan to control it? In my oh-so-humble opinion, using MFC class names is a good idea because the majority of people using this framework would be coming from the MFC world. Nomenclature familiarity is a "good thing"™. I thnk I'll join your mailing list. :-)
-
I'm not sure portability between platforms is viable (but it is a noble concern). It's been tried before and everyone ignored it because the platforms are so radically different - anyone here remember the Zapp library?. Of course, I was working on cross-platform apps back in the late 80's/early 90's when DOS apps were still being developed, Linux was just a gleam in Linus' eye, Windows was still living in a 16-bit-only world and OS/2 was being widely ignored by everyone. Now, there's two predominant camps - Linux and Windows (I don't count BeOS yet because BeOS doesn't have much of a following and it's still unclear as to whether it can find a large enough niche to become a concern). Does anyone still use OS/2 on a day-to-day basis? When a project like this is joined, philosophical differences of opinion can easily kill it or hamper its forward motion. How do you plan to control it? In my oh-so-humble opinion, using MFC class names is a good idea because the majority of people using this framework would be coming from the MFC world. Nomenclature familiarity is a "good thing"™. I thnk I'll join your mailing list. :-)
Portability is a low concern. I would like to make it a goal of the library, but not it's primary one. I think it's very viable to have a library be portable, and I have some very definate ideas about how to not only make a library portable, but also flexible and powerful without being limiting. (Lofty goals, I know). I think the problem with Zinc (the people that made zApp) was that they tried to do everything. Basically they replaced the OS with their own layers, which I do not agree with. A great deal of abstraction is necessary, but the library should not prevent you from getting down to the metal if you want to. As for philisophical differences, well, there is really only one way to deal with this. You need a project manager. Someone that is the final authority. This is how Open Source projects typically succeed. For instance, Linus is the last word about what goes into the kernel and what doesn't. You can modify your own kernel any way you like, even release your own kernel under a different name if you like. A PM should not be a dictator though. He should listen and evaluate and discuss. But ultimately, if the idea doesn't make sense or there is some overriding reason not to implement the idea, then the PM's word is law, or at least on the project that he is managing. Hopefully, you get some like minded people together that can work out their differences and everyone can compromise. Or, people can work together on the parts they agree about and strike off on their own over parts they don't. Please join the list, and we can discuss specific issues at length. Anyone else is more than welcome to join the list as well, even if you just want to give your input without ever writing a line of code. Again, you can get to the list from the PIL homepage which is currently at http://www.visi.com/~erikf
-
Portability is a low concern. I would like to make it a goal of the library, but not it's primary one. I think it's very viable to have a library be portable, and I have some very definate ideas about how to not only make a library portable, but also flexible and powerful without being limiting. (Lofty goals, I know). I think the problem with Zinc (the people that made zApp) was that they tried to do everything. Basically they replaced the OS with their own layers, which I do not agree with. A great deal of abstraction is necessary, but the library should not prevent you from getting down to the metal if you want to. As for philisophical differences, well, there is really only one way to deal with this. You need a project manager. Someone that is the final authority. This is how Open Source projects typically succeed. For instance, Linus is the last word about what goes into the kernel and what doesn't. You can modify your own kernel any way you like, even release your own kernel under a different name if you like. A PM should not be a dictator though. He should listen and evaluate and discuss. But ultimately, if the idea doesn't make sense or there is some overriding reason not to implement the idea, then the PM's word is law, or at least on the project that he is managing. Hopefully, you get some like minded people together that can work out their differences and everyone can compromise. Or, people can work together on the parts they agree about and strike off on their own over parts they don't. Please join the list, and we can discuss specific issues at length. Anyone else is more than welcome to join the list as well, even if you just want to give your input without ever writing a line of code. Again, you can get to the list from the PIL homepage which is currently at http://www.visi.com/~erikf
Have you looked at Qt? http://www.trolltech.com. They have a GUI framework that compiles on *nix and Win32. Unfortunately only the *nix version is free. :(
-
Have you looked at Qt? http://www.trolltech.com. They have a GUI framework that compiles on *nix and Win32. Unfortunately only the *nix version is free. :(
QT is not an Object Oriented framework. On top of that, it uses parser to pre-parse the non-C++ code into C code. In general, QT is a very good library, but does not achieve what I (and it appears John) are looking for.
-
QT is not an Object Oriented framework. On top of that, it uses parser to pre-parse the non-C++ code into C code. In general, QT is a very good library, but does not achieve what I (and it appears John) are looking for.
Ah, OK. I haven't looked very closely at Qt (since I'm not an X programmer :) ), but I just knew the name and thought I'd throw it out there.
-
Actually, Yes. I have started work on just such a project as you describe. I call it the PIL, or Portable Interface Library (which is probably a very poor name, since it will likely expand to more than just user interfaces). My primary design goals are 1) To use a standard C++ class wherever possible over a custom class. (strings, lists, maps, whatever). This makes it much easier and more consistent for a developer to write code without having to use a proprietary class, or do constant conversions between standard and proprietary ones. 2) To promote a much more object oriented overall framework, while still maintaining a low-level flexibility wherever possible. This may involve the use of platform specific classes that get wrapped in portable wrappers. 3) Port the library to every conceivable platform (though this is a lower priority, and probably will not occur until the platform is much stronger, it still needs to be designed with platform independance in mind). 4) Take advantage of as many language features as possible (where they make sense), such as Templates, RTTI, STL, etc... This will have the side effect, that if the library gets very popular, MS will feel lots of pressure to more fully conform to the C++ standard. It can also provide a learning tool for junior developers to study for realistic real-world useage of language features. I've started a mailing list, and am currently hosting a page with source download on my personal web site. I intend to move this over to something like SourceForge eventually, but I want to make sure the license is nailed down properly before that happens. You can access the code and mailing list from http://www.visi.com/~erikf Be warned though, this code does not follow any of the principles outlined in this message. It's a bunch of bare bones Windows specific code that I originally modeled somewhat on MFC (about 4 years ago). It's my intention to use this only as a starting point and to morph this code into something much better. I invite anyone who wants to join the project to do so.
Sounds perfectv A most important & noble task - I'm only suprised that this thread has not been innundated with similar messages of support. Prehaps they all took off to your site, as I know plan to do... Keep up the good work!
-
I've noticed a general increase in articles on CodeGuru, CodeProject and PlanetSourceCode where the primary feature of a given article is that the source code the article represents does not use MFC. The primary concern is "code bloat" which IMHO isn't as much an MFC problem as it is a programming knowledge problem, but the concern is there nonetheless. How many of you have been presented with projects where one of the documented requirements was "No MFC"? This is especially prevalant in COM/ATL projects. This leads me to the conclusion that there seems to be a groundswell of need for "something better" that makes better use of the C++ RTL. We are all aware that MFC is not nearly all that it can be, and even holds us back at times due to its weird little bugs, macro-choked code, and inheritance restrictions. IMHO, MFC should be more object oriented and provide a more substantial [thread-safe] wrapper around the Windows and C++ APIs. 0) Has anyone (or any group) ever given any thought to developing a new Windows class library that can replace MFC? 1) Is there enough free-range programming talent out here to tackle what seems to be an enormous task? 2) Could such a potentially large class library be made ready for prime time in a relatively short developement cycle? 3) Whatever happened to Owl, Turbovision, or Zapp? What class library is Borland C++ builder using now? 4) How would such a library be supported? Web-based? Standard windows help file? 5) Could any/all of the shortcomings of MFC and Windows be circumvented by writing such a class library? 6) Would we be any better off with a more RTL-oriented class library? 7) Could such a class library gain interest and support from other programmers and third-party companies? 8) Would Microsoft view such a project as a threat of any consequence to its dominance in the industry? 9) With the advent of C# and .NET, is there even any interest in such a project?
> How many of you have been presented with projects where > one of the documented requirements was "No MFC"? This is > especially prevalant in COM/ATL projects Well, since a COM project should not have a heavy (if any) GUI, then it is fine to not use MFC. Use ATL for COM apps, and MFC for GUI apps. It is when people start trying to use ATL as a replacement for MFC when developing GUI apps (or *MIXING* the two together, which is REALLY not-too-bright) that things start to go wrong. This kind of faulty thinking happens a lot, because some people have the idea that MFC is too bloated, and would perfer that time be spent reinventing the wheel that MFC already has for you to use. Anyway... Rant over... > 0) Has anyone (or any group) ever given any thought to > developing a new Windows class library that can replace MFC? Yes. Ever heard of WTL or Atilla? I was under the impression that they were designed to be alternatives to MFC for GUI apps. Peace! -=- James.
-
> How many of you have been presented with projects where > one of the documented requirements was "No MFC"? This is > especially prevalant in COM/ATL projects Well, since a COM project should not have a heavy (if any) GUI, then it is fine to not use MFC. Use ATL for COM apps, and MFC for GUI apps. It is when people start trying to use ATL as a replacement for MFC when developing GUI apps (or *MIXING* the two together, which is REALLY not-too-bright) that things start to go wrong. This kind of faulty thinking happens a lot, because some people have the idea that MFC is too bloated, and would perfer that time be spent reinventing the wheel that MFC already has for you to use. Anyway... Rant over... > 0) Has anyone (or any group) ever given any thought to > developing a new Windows class library that can replace MFC? Yes. Ever heard of WTL or Atilla? I was under the impression that they were designed to be alternatives to MFC for GUI apps. Peace! -=- James.
Got websites for those (WTL and Atilla)? I've found VCF too ( http://vcf.sourceforge.net/ )
-
Got websites for those (WTL and Atilla)? I've found VCF too ( http://vcf.sourceforge.net/ )
WTL and Atilla are covered topics here at CodeProject, and also at CodeGuru... -=- James.
