In practice, given that there is a large base of MFC developers, perhaps team lead will continue to choose MFC for new projects to harness available talent pool?
Similarly, if an initially MFC project has been ported to Mac/Linux, presumably each branch has its own dedicated developers. Is it usually unlikely the team will plan to develop a Qt port as your main and slowly fade out the native branches?
Quote: Original post by ChaosEngineQuote: Original post by rumbleQuote: Original post by ChaosEngine
There's really no reason to use MFC anymore. You're already making your code windows specific, so you may as well go the whole hog and use Winforms.
Being recently introduced and involved to GUI, and never really understood MFC to be comfortable, I am curious.
Are you saying MS will slowly stop supporting MFC or goad developers into .NET and other MS platforms?
Nothing so machiavellian. When MFC was released, it was a pretty reasonable alternative to the Win32 API. Sure, it was a bit clunky, but ultimately it was more productive than Win32, alleviating a lot of the boilerplate code you needed to write.
But these days, C#/Winforms is an order of magnitude easier/more productive to use. If you are writing a new windows-only app, there's simply no reason to use C++.Quote: Original post by rumbleOr are developers actively making the switch to Java or Qt, either for ease of use or cross-platform support?
Cross-platform? MFC was never cross-platform to begin with, C# has some x-platform support with mono and if you really want to go x-platform, you're probably better off with QT, wx, etc.
Need to leverage an existing C++ codebase? No problem, simply wrap a C++/CLI assembly round that sucker and you're good to go.
The only reason I can think to use MFC is if you have a large MFC codebase that contains a useful set of custom controls you wish to leverage.