|
I used VC++/MFC for about 10 years around '95-'05, and, I liked it a lot, also because of relative ease of GUI development (yes, we speak about message maps). But, when .NET/C# came out around 1999-2001, I became gradually convinced about the "added-value". So, in my case, I appreciate my VC++/MFC background, but I still appreciate it more working mainly with .NET/C#  ...
|
|
|
|
|
I began learning MFC around the time that .NET came out. I was a little late to the party and I never learned it completely.
Still, I feel your pain. I enjoy working in a native environment, and I'm slightly frustrated by big frameworks that do everything for me, as long as I do it their way.
But I must admit that in terms of ease and productivity, .NET is superior. However, ease and productivity don't always have to be the main priorities.
I will still play around with MFC, but as far as paying the bills goes, it's .NET all the way.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
MFC is like calculus when all you want and need is math.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I am a long-term user of both C++/MFC and C#/.NET/WPF, so I feel qualified to render an opinion here.
I think MFC will persist as long as the underlying Windows API (aka Win32 and GDI) programming model remains supported. There is a lot of software out there written using it. It remains a tool-of-choice for applications where a fairly simple UI, performance, and fine-grain control over memory allocation and threading are a priority. It is also preferable for some system programming tasks and device driver development.
That said, C#/.NET has a lot to offer in comparison. You don't need to build anywhere near as much "plumbing" when building a C# application, because it either simply isn't needed or the .NET environment includes an implementation that you can use. Complicated user interfaces are far easier to create with the various .NET UI technologies, again because you don't have to work hard at implementing basic features.
As always, it's a matter of choosing the appropriate tool for the job. IMO, C++/MFC still has a future.
Software Zen: delete this;
|
|
|
|
|
There are quite a number of people who still use MFC. Presently, it is in maintenance mode at Microsoft and it is doubtful there will being any significant updates made to it.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
Randy Faldon wrote: I like the libraries of MFC and I believe that straight C++, writing your own code can be more helpful in the long run than having someone who doesn't understand the complexity of what you want to accomplish.
Isn't that statement self contradicting? Pretty sure Microsoft has no idea what you (or I) want to accomplish.
Randy Faldon wrote: PASCAL and FORTRAN...SO, WHO BELIEVES THAT MFC WILL LIVE ON OR DIE??
You use Pascal and Fortran so I am rather certain that no one here is going to convince you of the death of MFC.
|
|
|
|
|
MFC was the first framework I learnt in order to land a windows programmer job in 2003. It's a pity I never had a chance to use it professionally. My first (junior) job was deigned to mindless mundane chores like localization (replacing English text in HTML with other language text.) The next job was coding WinForm with C++/CLI (.NET enabled C++). To think MFC is obsolete now. I only used it in my personal projects and wrote some CodeProject articles about it.
Now the technology world has moved on to the web, mobile and AI. Looks like my efforts to learn it is wasted.
|
|
|
|
|
I personally think MFC is solid. It will stay there for time to come, it's basically a rock.
... and just as malleable. I'm not exactly deep in the matter but what I've gathered, more modern solutions are easier to use and incur less overhead.
But if you're invested in MFC (and your customers don't demand visual bells & whistles which I hope they don't, an unnamed customer of ours once did and I'm glad it got stuck in the swamp of corporate legal), there's no reason to switch.
On .NET, Win.Forms got a status roughly comparable to MFC (works, but is so-not-modern and doesn't get cool stuff like first-party multiplatform support) and I've started a project with it.
|
|
|
|
|
The inventor of C++, Bjarnes Stroustrup states that there are languages that people complain about and the remaining languages that nobody uses. I have been using C++/MFC since the early 1990s and definitely prefer it to C# or Java as the applications that I develop tend to be CPU and memory intensive. C#, Java were explicitly created for programmers who could not master the usage of new/delete operators. Both C# and Java languages waste too much time searching for garbage.
|
|
|
|
|
You find the feud between you & managed languages so important, you're missing what's in common: both me & the OP are into tech that's universally considered old, yet runs like a solid horse.
Isn't that way more important, than fussy bickering?
|
|
|
|
|
Working in WinForms myself, albeit with DevExpress widgets. WPF was supposed to replace it, but haven't seen people really cotton to it.
|
|
|
|
|
I cannot imagine a single reason to write a user interface in C++/MFC instead of C#. C#/WinForms let you write code at an higher level, not caring too much to low level implementation detais, but also allows you to handle yourself the windows messages if you really need such a low level control of your code.
"Yes, but with C++ I can write high performance code, faster than c#" (not really true actually)
If you find a part of your code too slow when written in c#, you can write a c++ dll for that specific algorithm you need to run faster and use it from a .Net program (with interoperability and/or managed c++)
I really see no space for MFC to be the right tool of the job. C++ can be for some jobs, but not for writing UI, IMHO
modified 2-Aug-21 10:03am.
|
|
|
|
|
I worked in VC++ land for probably 15 years. Did a ton of C++/MFC code and was quite proficient at it. Never under estimate the prowess of an experienced C++/MFC coder, I could do anything with that toolset. Moved to a new job when .NET was coming up the curve, and my coding partner (we were a single team of 2) and I figured we best get on board with this new shift. So we embraced C#/.NET and did some solid work. Next job was me being a team lead to a group of 8 developers coding in PowerBuilder, Access and VB. C++/MFC was still my toolbox of choice, but it was clear there was no way I was going to get these folks coding in that arena without seriously blowing sht up. So, with some sadness, I walked away from C++/MFC for C#/.NET. And while I'm extremely productive in C#/.NET, I miss C++/MFC every single day. Been coding since 1984, and while C#/.NET pays the bills, C++/MFC was my 9th symphony.
|
|
|
|
|
I'm probably one of a sparse number of MFC holdouts. Decades ago, back in the Borland Turbo C++ days, I used OWL. After that, MSFT C++ and MFC.
I should note that the only aspects of MFC that I use are the UI centric ones. Windows, Dialgos, Property Sheets/Pages, Menus, etc... never used Ribbons, can't think of an instance where I would.
The majority of my work doesn't involve UIs, most of it is functional code called by others, APIs, and ISAPI Services. When I do require a UI, such as for configuration or reporting access callable from our main product, MFC is there. It is consistent, and it continues to function as designed from one VC++ release to the next. Because most of the modules I write must integrate tightly with our primary product as "plugins", moving to a ".net" would incur a lot of additional work. I also feel that when I do need something highly specialized, it is easy to inherit from MFC and create controls with modified appearance and behavior. As long as MFC is available, I'll continue to use it, and if they decide to no longer ship it with VC++ and cause errors using legacy MFC libraries, I would likely recompile it for use with the newer release.
|
|
|
|
|
Biggest bunch of crap, other than BizTalk, that was ever created. Visual Studio was created for developers to create application quickly, as in RAD development; not watch a hundred or more files get piled into an application and pray it all comes together.
There are too many people at Microsoft with nothing to do, creating new nightmares.
|
|
|
|
|
What? 
Please re-write that so someone understands.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
This discussion has become confused. mfc is NOT C++ nor is it Visual Studio. Please understand the difference. mfc was a necessary step to abstract the asinine Windows development approach. Really? Code your own case statement for events? At the time I discovered this, I was writing UI's on X-Windows, and X was way ahead of Microsoft when it came to toolkits, abstracting the event loop out of the developers head.
Along comes Visual Studio that automated the editing process of handling events, added MFC, etc.
It's important to keep the issues separate.
But at the end of the day, use what helps you get the job done. I just read in another post that Microsoft has released yet another UI approach. They just churn it to look relevant.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
|
Microsoft Foundation Classes - a framework for VC++ with OO code for doing Win32 stuff, at least that is what I understand it to be. Really old, hard to find documentation and examples (most of it is missing from publicly available pages at MS). Tried to do something with it during my CS course, I cursed every hour while searching for documentation and examples. Usually dead links. Microsoft is making sure new people don't have it easy to use it.
You can still use it in Visual Studio if you want to.
|
|
|
|
|
I think you seriously misunderstood... 
|
|
|
|
|
I blame Microsoft for obscuring it away so much. 
|
|
|
|
|
MFC was developed at a time when documentation was printed out and provided in the form of books. I still remember the thick stack from Visual C++ 3.0 (or maybe 3.1?): about a dozen books with a total of >5000 pages of text.
Programmers at the time were required to find out what parts of these books they needed and then actually read it. Better yet: find third party books on specific topics such as MFC UI programming and read those instead, and only use the documentation for reference.
Nowadays, programmers expect to use new APIs on the fly: spending more than an hour reading documentation is considered unacceptable, and an API requiring that considered obscure or outright bad.
Microsoft doesn't obscure MFC documentation, they just never integrated all that additional information contained in those third party sources - quite possibly in part due to copyrights, but also because they instead focused on .NET as a replacement.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
No, Microsoft during various migrations of its documentation sites simply decided not (or didn't care) to migrate a lot of stuff related to MFC and left lots of dead links to articles and example code on its own websites (at least that was the state of things about three years ago, maybe they fixed it by now). In case of a large company like Microsoft I call that obscuring.
And I spent way more time, than few hours searching through the web to find what was needed.
I don't expect to ever find an API I can use on the fly, unless it is some extension to an API I already know. It would be nice If API documentation was written in a way that enables this, but so far I have not seen something like that.
|
|
|
|
|
Languages and frameworks never truly die unless the platforms they exist on die. As long as Windows lives, so will MFC. Its certainly less popular and hard as heck to work with if you are used to .Net.
"Make everything as simple as possible, but not simpler." - Albert Einstein
|
|
|
|
|
... so I used my Bryan Adams CD.
It cuts like a knife ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
