Is MFC being left behind ?
As it goes, the free MS VS 2005 Express C++ doesn't support MFC.
The idea of distributing a liteweight version of VS2005 was a great idea, so that students like me could start learning to code for Windows using one of the best development tools out there. Since there's no way one can use MFC to create Windows applications using the Express Edition - Windows Forms(C#) being the only option - and assuming that the average student cannot pay for the full VS2005, it seems to me that MS is droping the old MFC and leaving everyone with a single option : .NET.
A question that pops up here is this : Is there any point for beginning Windows prorammers to learn MFC ?
The funny thing is, MFC is supported in the full version, and MS says that they will continue to support it as it is a great framework.
If you're releasing a free version of VS2005 why not include MFC since it's still going to be used ? It seems illogical...
No point in learning MFC unless your employer requires you to since most of it can be done with .net and windows forms a lot easier and if it can't you'll have to go back to using good old windows api anyways.
MFC is on it's way out, but it's still used by a lot of companies, and will probably continue to be for a while yet. MFC extensions are also very popular. Check out BCGControlBar. Student pricing is very reasonable, and I've used it in a few apps. Makes for a fantastic interface.
I would not bother with learning MFC today. It's not by any means dead since there exist a huge legacy code base, and that's why MS still supports MFC and updates it. But almost all future improvements of MFC will be in the interoperability with .NET.
My advice would be to use .NET unless you have a good reason for needing MFC.
As to why it wasn't included in VC++ Express, well not even the Platform SDK was included so it's not a MFC specific thing.
My advice would be to use .NET unless you have a good reason for needing MFC.
As to why it wasn't included in VC++ Express, well not even the Platform SDK was included so it's not a MFC specific thing.
I feel that as gui's get progressively simpler to design in other languages and with other software paradigms we'll see a move away from thin OO wrappers like MFC.
I respect the need for all programmers to have a feel for how windows applications really work, but unless performance is a major issue I don't think that knowledge will provide as much advantage as it has in the past. This is likely to continue to be the case as languages like Java and C# become mainstream for developing desktop applications.
For the last four years I've had significant involvement (lab assistant, team leader and now assistant supervisor) in final year project teams working in C++. All students attempting our projects know C++ before starting, but perhaps 1 in 20 knows MFC. Typically this means that students don't appreciate the time, effort or risk involved in getting seemingly trivial MFC components to work work. I wish I had a dollar for every: "I have to do WHAT to insert something into a tree control". From personal experience, the use of MFC in a student projects increases the chance of failure by a factor of about 3 or 4.
To sum up, I would never ever ask one of my students to use MFC. In fact I directly recommend against it. Instead, consider doing things the unix way. Design small testable command-line applications in C++ and write front ends for them in more appropriate languages. If a command line interface is too restrictive, then use a client server approach.
Things to consider
--------------------
Typical problems introduced by programming in MFC:
* Program flow is hard to understand
* Coupling between doc/view/*dlg classes isn't identified until too late
* Leads to mis-understanding of the window message pumps and how events work
* Leads to code that is hard to debug and harder to modify
* Generates too much code most of which seems to be noise
* In some situations projects can be irrevocably damaged through changes to seeming innocuous code.
* MFC does not follow current best practices (it was designed well before most of them were around)
* poor support for exceptions
* hand rolled containers
* poor naming conventions
* poor use of inheritance
What alternatives do you have in C++?
* John Torjo's win32gui
* GTK + glade
* Windows forms (C# and/or managed c++)
* Raw Win32 (only appropriate for games or simple layouts)
* WTL (and/or) ATL
* WxWidgets
* Qt
I respect the need for all programmers to have a feel for how windows applications really work, but unless performance is a major issue I don't think that knowledge will provide as much advantage as it has in the past. This is likely to continue to be the case as languages like Java and C# become mainstream for developing desktop applications.
For the last four years I've had significant involvement (lab assistant, team leader and now assistant supervisor) in final year project teams working in C++. All students attempting our projects know C++ before starting, but perhaps 1 in 20 knows MFC. Typically this means that students don't appreciate the time, effort or risk involved in getting seemingly trivial MFC components to work work. I wish I had a dollar for every: "I have to do WHAT to insert something into a tree control". From personal experience, the use of MFC in a student projects increases the chance of failure by a factor of about 3 or 4.
To sum up, I would never ever ask one of my students to use MFC. In fact I directly recommend against it. Instead, consider doing things the unix way. Design small testable command-line applications in C++ and write front ends for them in more appropriate languages. If a command line interface is too restrictive, then use a client server approach.
Things to consider
--------------------
Typical problems introduced by programming in MFC:
* Program flow is hard to understand
* Coupling between doc/view/*dlg classes isn't identified until too late
* Leads to mis-understanding of the window message pumps and how events work
* Leads to code that is hard to debug and harder to modify
* Generates too much code most of which seems to be noise
* In some situations projects can be irrevocably damaged through changes to seeming innocuous code.
* MFC does not follow current best practices (it was designed well before most of them were around)
* poor support for exceptions
* hand rolled containers
* poor naming conventions
* poor use of inheritance
What alternatives do you have in C++?
* John Torjo's win32gui
* GTK + glade
* Windows forms (C# and/or managed c++)
* Raw Win32 (only appropriate for games or simple layouts)
* WTL (and/or) ATL
* WxWidgets
* Qt
Quote:Original post by Mocanu Razvan
Since there's no way one can use MFC to create Windows applications using the Express Edition - Windows Forms(C#) being the only option - and assuming that the average student cannot pay for the full VS2005...
A student is able to purchase the full VS 2005 for about 60$ from numerous sites. Don't buy any beer or go to the bar for a week, and work a couple extra hours and a student will be able to pay for the full version ;)
Quote:Original post by Mocanu RazvanA question that pops up here is this : Is there any point for beginning Windows prorammers to learn MFC ?
I really wouldn't bother with it. It can be a painful experience, and is not worth it when many vastly superior options are available (as pointed out by the above post). I highly, did I say highly? I meant highly recommend wxWidgets for any sort of UI/Interface development. There is also FLTK, but I would consider wxWidgets the superior solution: it's very mature, huge user base (easy to get support and very good documentation), it has every feature you can possibly want for most applications, and it is a very well designed library.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement