|
I would like to say or believe that MFC is here to stay, but the more I study the more I find that a lot of articles, peoples posts, Microsoft and other things that are focused on MFC seem to get little responses or so vague that we can't get a full explanation of a code block. Is Microsoft pulling away from MFC, has there been an issue with MFC that just doesn't jive with the C or C++ common language? If I'm missing something like "a better idea that has evolved from MFC into a NEW library that has the same functionality than by all means please spit out!"
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. With that being said I believe that with the base ingredients of MFC libraries that we can expand our knowledge of this and write expandable code into the pre-existing libraries.
I might be rambling on about this programmatic issue, but for me, MFC is a lot more than just another problem that I hear in a lot of forums in which programmers are not fond of for whatever reasons that they come up with, it's just another straightforward class in which I have a lot of respect and enthusiasm(Good Luck MFC).
There are languages that I can start from scratch in Notepad, there are languages that I need help with along the way, but there are languages that I can't comprehend to this day which is frustrating for me, meaning that sometimes we all need help in one way or another. Am I wrong by writing this or should I elaborate more on this subject? To me there are four main Microsoft languages (C, C++, C# & VB) and outside the realm of Microsoft, my choices are COBOL, JAVASCRIPT, PYTHON, straight HTML & CSS together, PASCAL and FORTRAN.
Anyway, this post may be in the wrong section, still the same, I would like to get some love and not negativity. No one likes to be beaten up with online sarcasm or just plain disrespect and disregard. SO, WHO BELIEVES THAT MFC WILL LIVE ON OR DIE?? Love ya, Mean it!!!
|
|
|
|
|
I'm an old Classic (i.e., pre-.NET) VC++ coder.
Before Java (and later, C#), there was not a good object-oriented language, so C++ pretty much was it for the WinTel platform (Apple used the hokey, Smalltalk-ish Objective-C). VBasic was considered to be almost a toy, not a whole lot unlike what JavaScript was before it grew into the freak that it is today, and so any big project in Windows was done with VC++. The only other Windows-ish stacks were Borland Pascal and the various X-Windows implementations; VC++ was a superior stack to these, and of course was directly related to Windows.
Java, with its belts & suspenders warts, was an easier language for lesser able programmers to be productive, and with the product code being as safe as possible - and oh, with managed memory. Microsoft basically cloned Java to get C# (although I must say that C# seems to be a better language), and in so doing revamped MFC's class system, getting rid of the very hokey data binding & message mapping (actually done via the clunky #define to some very ugly looking code). I personally think that there is some nirvanna C++-ish language that could have been developed that is like C++ but with garbage collection (that could be controlled) and (what I consider at least) to be the best of C++ & C#; alas, that language (and Windows stack) did not make it out (perhaps Rust is close to that, but it's not the Windows stack).
Now as far as VC++ as a language that can pay the bills, I thought was it was for the most part finished in the early 00s. My experience as a VC++ hired gun seemed to have no takers, as clients couldn't give a rat's a33 about someone's VC++ skill being transferable in any way to C#. This was the first time that I had realized that front-end programming had market value that was very ethereal, and that there wasn't really this body of lasting knowledge in doing front-end work. I think the database end is not so ethereal, and actually see data mining, or "business intelligence", to be a field whose market value is dependent at all that someone have experience in SomeStupidAPI 6.3, where someone having experience in only SomeStupidAPI 5.4 is as obsolete as the horse & buggy in the era of the Model T; the market value is coming up with cunning application of mining techniques that is far more important to client than whether he knows that SomeStupidAPI.
|
|
|
|
|
MFC was good when it came out - it made a lot of things a whole load easier.
But ... the world has changed since then, and the focus has changed with it. Newer frameworks (such as .NET) are more consistent, easier to use, and IMHO better all round.
Would I use MFC for any new project? No. I haven't even touched it for the best part of 20 years - though part of that is that C# is a "better language" for the modern world than C++ in many ways. Again, that's my opinion, my impressions - but I grew up with assembler, then C, then C++ and I've been doing this stuff for over 40 years now!
I'm not sayinG that ++ is a "bad language", it isn't - but from a speed of development and maintainability POV, C# and .NET knocks C++ and MFC into the bin! 
"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!
|
|
|
|
|
(don't mind me, it's 4h30am, and I'm going out for a long bike ride, not quite awake yet).
MFC is dead.
MFC is not properly maintained.
There hasn't been any improvement in many years (introduction of the Ribbon ? ). The resource system is antiquated, the collections are useless; localization is a b*** ,
MFC is good enough if you do simple UI within the framework limitations; as soon as you want something more "fancy" the learning curve is hard and feasibility is not that great.
CI/CD = Continuous Impediment/Continuous Despair
|
|
|
|
|
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. 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
