彻底放弃没落的MFC,对新人的忠告!--吃瓜群众围观撕逼

时间:2023-03-08 15:40:05
彻底放弃没落的MFC,对新人的忠告!--吃瓜群众围观撕逼

http://bbs.csdn.net/topics/391817496

完全没想到10多年后还有人纠结要不要学MFC,我花点时间给新人们一个总结。

第1种观点 学习完MFC,你会更理解编程的思想,再学别的语言就更快了。

话说小白要去美国学技术,大黑劝他说:“你为什么不先到朝鲜,然后从朝鲜再飞到美国”,小白茫然不解。大黑接着说“你想你先到朝鲜再去美国,不是比从中国直接去美国近吗?”小白恍然大悟,“并且你到了朝鲜,那里有金太阳的照耀,你会更明白技术的思想。后面再学任何技术都很快。”于是小白去了朝鲜,然后他才知道原来朝鲜才是最好的地方,他给大黑打了长途电话,大黑问:“你感觉怎么样?”小白激动的说“我在学习用小刀刻芯片呢,听说美国都是动动按钮,学不到真正的东西。”

有的人要说“你看我就是先学了三年MFC,再学别的语言一样很快”,是,你要是先学三年JAVA或C#,再学别的语言会更快。你学三年MFC不是去跟零相比,是跟学三年其它语言比。在经济学上这叫机会成本,曼昆“你在面临选择的时候,要考虑的是机会成本”。

第2种观点 MFC接近于系统的底层,适合系统级的开发,学习他更能理解操作系统。

MFC能直接调用C,别的语言不能直接调用C吗?那.Net Interop是干什么的?醒醒吧!别说C,连MFC的DLL都有办法调用呢。
你真的觉得学习CDocument, CView, CWnd, CFrameWnd。。。这些绕来绕去的东西会更理解Windows?要更深的理解Windows要学习Win32编程,学习Windows核心编程,不是那个MFC,再说WinRT比Win32要好用的多。

第3种观点 MFC开发的程序运行效率高
MFC主要用来开发客户端程序,这里应该是跟C#对比,C#以前是托管程序,现在C#开发的Windows程序已经能编译成native了,运行效率提高了1.6倍左右吧,MFC是沉舟侧畔千帆过,船舱里的人还以为在乘风破浪。对了,visual studio的界面是用什么开发的呢?

还有一些观点,像什么刀呀剑呀,还有什么“你MFC用不好,也用不好C#”,就不一一列举了。很多时候辩证法就是粗看去很有哲理,实际毫无实际的指导意义。

为什么还有一些人推荐MFC?

话清末要废除科举制度,进京赶考的举子跪在外面绝食*,朝堂之上还有大臣坚持科举有多么好。是啊,你想这些老秀才学习四书五经学了半辈子,一下子又不考了,多少年的心血白费了。考物理,化学,代数,几乎给他们判了死刑。对于一个多年学习MFC,又不会别的语言的人,基本上也是深度套牢了。我记得冰河世纪里有一只老刺猬,洪水要来了,他躲在洞里不走“I was born in this hole and I'll die in this hole.”坚持是一种品质,顽固和守旧却是另外一回事了。这对于新手来说是一个很好的教训。

为什么还有很多刚毕业的大学生学习MFC?
因为他们的老师是上面所说的那些人。

MFC总有适合用的地方吧?
有,适合用在上世纪90年代开发Windows客户端程序。

MFC现在一点用都没有了吗?
不是,历史上遗留下来一些MFC的源代码需要维护。可能偶尔会用几个开源项目,就像弹药不够的时候偶尔也拼一下刺刀。

MFC应该跟什么语言比较?
Borland C++,VB6,Delphi,PB等。

什么人还需要关心一下MFC?
IT历史学家需要大写特写MFC曾经短暂的辉煌,考古学家需要考证这块化石的时候。

http://bbs.csdn.net/topics/391817496#post-400327680

MFC就是微软一个框架类   跟QT、WTL基本就是同类产品
唯一区别就是MFC没有维护,没有创新了,而QT挂着跨平台的称号(也就是外层统一API,如果linux则调用linux的API,微软的就调用微软的系统API)
小白也好,大神也好。认为当前项目有必要使用MFC就用
你想让小白直接用系统API写代码,也可以啊,一个main函数,然后创建窗口,创建按钮等等等
我不知道你喷MFC有什么意义?你喷MFC,跟你喷QT有区别?QT我可以说,他就是另一个MFC,唯一就是跨平台
如果微软再升级一次MFC,封装一下linux的API跟windows的API,秒你QT分分钟
我入门的时候,就是看的MFC,因为MFC简单易懂,我不需要关心系统API,我只需要调用MFC的API就能实现我的功能
通过MFC,再去玩WTL、纯API开发,就简单多了,这是我的经历,我不知道其他人是什么情况。
但是你喷MFC是毫无意义的事情。。。

我的题目是新手彻底放弃没落的MFC,并没有说MFC彻底没落,更不是说MFC一点用也没有。你说的很清楚,MFC毕竟是15年前的设计,它的定位就是局限在开发Windows 95内核上的客户端。既不能用于手机开发,又不能用于物联网。当然,还有应用服务器,Web服务器,数据库服务器就更不用说了。使用者越来越少不是很明显的趋势吗?所以我建议新手放弃MFC是没有问题的。

编程语言,框架,工具等之研发团队就像武器之军队,原子弹的出现并没有淘汰掉冲锋枪,甚至古老的匕首也存在着不可替代的作用,这是武器的生存空间问题。如果从整个作战系统的全局来考虑每一类武器的生存空间,重骑兵,投石车,被淘汰也就在情理之中了。MFC就像投石车,即使发明它的企业也早就不做任何改进了,而远程投射系已经经历了大炮,火箭炮,进而向弹道导弹的方向推进,它未来的生存空间在哪里?

某项技术好不好我这种菜鸟没发言权,但C#之类的东西运行慢是真的,能感觉得到,而且还得一大堆库的支持,烦得很。
QT也慢,不知道怎么回事。

MFC胜在简单、通用、稳定,它还是有自己的市场的,一些偏硬件的公司通常用它做上位机软件(当然也有选择用C#的),这些软件完全不需要花哨的界面,只关注功能的实现,MFC是非常好的选择,需要的维护人员也少。

无论MFC也好,WTL也好,WPF也好,QT也好,都是工具,各有自己的特点,谁熟练就用谁,不过,论学习成本,我还是觉得MFC是最容易掌握的

Visual C++前面的那个Visual指的是可视化界面编程,是本质特点,而MFC就是界面编程的基础类库。界面编程就是MFC编程的主战场,逃离了界面战场它什么都不是。MFC的简单易用只是相对于Windows API的,因为它是对Windows API的封装,它的快只是相当于在没有飞机之前的时代,蒙古的骑兵的那种快。

你在这展示的恰恰是MFC的局限性,当然这首先是GDI的局限性,花哨的界面都是靠贴图,切换图片。图片都是静态的,是死的,如果你用图片表示一个电池,还要设计多个图片表示电池的不同状态,比如说电量报警的情况。如果还要根据电量的数值来绘制电量的饱满程度,就只能用自定义控件了。界面设计师只能用PS来设计,设计出来程序员还不一定能开发出来。
另外,15年的发展,显卡已经从一个黄脸婆发展成一个亭亭玉立,芳龄二八的美少女了,而MFC从一个壮小伙子逐渐发展成82高龄的老翁。无论她有多少炫丽夺目的功能和性能,他已经再也驱动不了了,只能多买一此衣服让切换。如果说他们仍然深爱着对方,不得不说是思想层面的事了,哦,“思想”真是个好词,有什么事说不通,就可以说成是“思想“上的。

从未放弃过MFC

现在掌握两种语言:C#与MFC
个人认为两种各有特色,对同一个工程:
C#:开发周期短,UI及各类控件五花八门,简单易用
MFC:开发周期长,UI不好建立(虽然有bcg之类的),但效率比较高

目前没有放弃的原因,是现阶段主要进行视觉类程序开发,工业级方面的应用,效率非常重要,公司的一
个产品,进行视觉检测,C#执行120ms,C++下只要60-70ms

另外还是习惯MFC下的代码编写,C#里面写个跨线程,更新用户UI之类的,用委托,麻烦的要死

所谓MFC思想(一)

好多人都强调学MFC关键是它的思想,好,我就把它从思想的火锅里捞上来,用手术刀剖开让大家看看它混乱的思想。从面向对象来看,界面类的内聚性很差,ID_,IDC_保存在Resource.h里,界面元素,布局等都保存在rc文件里,一个界面类的代码不能从根本上独立,这样所有的界面类自然而然的产生了耦合,这直接导致编码工作难以单元化,而这是根本性缺陷,必然给所有工作增加不必要的复杂度。比如集成工作要手工处理Resource.h,RC文件等,当然还有不同类库之间宏定义,WM_的冲突等等。比如配置管理工作,配置项识别就纠结不清,必然导致分支与合并额外的重复手工劳动,而手工劳动最容易引进新的错误。单元测试就更不用说了,MFC基本上处于软件开发的手工作坊阶段。这就是MFC过人的思想?不过,从另一个角度,MFC作为反面的教材有值得深思的地方。

请问学会MFC都要学些什么呢?DOC-VIEW,OLE,UI线程,泵,钩,还是堆,栈内存分配与回收的机制?还是那些各种各样的CHAR,还是__cdecl, __stdcall,PASCAL等等,或者编译,链接的各种各样的参数?
继续讲故事,

MFC新婚之夜

红烛高照,MFC美女偎依在VC程序员的怀里,娇羞不语,只见她身上只剩下最后一件罗衫了,上面印着两个斗大的字“思想”,她用手轻轻按住新郎的手,“爱到这一层就不能再往下了”,新郎不解“为什么呢?”他的目光似乎已经穿透罗衫,MFC压低了声音:“除非你发誓,一辈子只爱我一个,不能爱其它任何女人。“新郎略一思索,他也没见过其它美女呢,“我发誓,一辈子只爱你一个。”印着”思想“的那块布慢慢滑落,新郎顿时惊呆了,MFC分明就是一个透明人,五脏六腑一古脑的展现在新郎面前,扑哧扑哧跳动的心脏,缓缓蠕动的肠子。MFC急了,”我就说你别往下看了,你就不听,你还爱我吗?“VC程序员心想,又没见过别的美女,可能别的美女也都是这样的。赶紧说:”爱,爱,爱。“MFC有点诧异:“为什么?”新郎来不及多想,脱口而出:”这样我能学到更多的东西。“
过了几年,丈母娘来了,沉思良久难以启齿,“这么说吧,当年我年轻的时候,邻居家有一个好闺女,我气不过跟别人家呕气,于是就生了MFC,没想到早产,天生有一些缺陷”。“什么?”VC程序员瞪大了眼睛“您不是一直声称,MFC是天下最好的美女吗?”丈母娘一见姑爷急了,马上说:“对对对,以前这么说没有错。不过我这几年又生了一个闺女,这一次才是最完美的。我现在想把这个闺女嫁给你,把MFC换回去。“ 
VC程序员脸一下涨得通红:“给我什么也不换,我只要MFC。”
“免费嫁给你也不要吗?不用买车买房,也不用聘礼。”
”我不希罕,我已经答应MFC,要爱她一辈子。”
丈母娘有点无奈了,”我不知道你跟MFC发展到哪一步了,她的很多内部细节在不该暴露的时候都暴露了。“
VC程序员显得很得意,”哈哈,我就喜欢她这样,这样我能学到更多的东西“。时间真是个魔鬼,几年的时间VC程序员已经完全习惯了MFC这种特殊的构造。
丈母娘叹了口气,MFC这个闰女害得她受了不少骂,没想到还有这么爱MFC的,难道爱一个人真的就会爱她的全部,包括缺点?不过这种爱法太匪夷所思了,会不会是因为从来没见过别的Girl,误以为自己一直深爱着MFC呢?"你是不是从来没见过别的Girl呀?"
“Girl?”VC程序员显得很不屑,"是CGirl好吗,有了MFC,我为什么还要去看别的CGirl?”
丈母娘显然有些语无伦次了,”要不这样吧,把CMFC和她妹妹都嫁给你吧。时间长了你自己会作出正确的选择。“
VC程序员:”算了吧,MFC才是我的最爱。对了,昨天我还跟您邻居家姑爷吵了一架,竟然敢鄙视MFC。”

自己也算是个资深的MFC开发者了,越来越感觉MFC的没落,现在这两年也是渐渐远离MFC相关的开发项目,做点其他的。
楼主说的很对,建议新人不要深入学习了,不是MFC要被淘汰了,而是现在开发的主流趋势是多终端的,主要集中在移动端和服务端,所以只做桌面程序的市场是越来越小了。

回复楼主,我从1997年使用MFC编程,到现在已经18年了,可是从来没觉得它落后了,关键是我这18年来只编写一个软件这个软件长度已经接近100万行C++代码了,里面自己建立数据库系统、自己建立编译器、自己建立人机界面开发平台等等,我现在用一个小时的时间开发的功能,估计你用C#、Java等语言一周都做不出来。

我现在上班基本没人管,工资应该还行吧,每天就花一点时间编编程序,怎么编写程序自己定,怎么做都可以,你说MFC落后吗?关键是你采用MFC编写什么程序?比如:你给我编写一个桥梁载荷计算的程序,你是用什么编写好呢?要么你用MFC编写,或者你用MFC开发的平台软件ANSYS等来做,你还指望采用C#,Java能开发出来吗?????

MFC适合于开发复杂的二次应用平台,定位是比较高端的,简单点说,你如果要想开发一个类似EXCEL,浏览器等平台软件的程序,你这时候只能用MFC了,而且你编写完成后,你10年内都不容易落后!!!!!

MFC诞生的时候是1992年,C++还没发明出命名空间,标准模版库也没有进入C++标准。
从现代C++的眼光来看,MFC是丑陋的设计。被抛弃是必然的。

说的有理。语言会影响思维方式。MFC还停留在史前C++时代。

刚刚还有人在群里面发招聘信息 cocos2d 1年经验10k-15k,现在移动端薪水炒得是火热啊。
MFC呢?绝大多数都是维护历史系统吧,薪水能给到多少呢?
市场10多年前都转到Web了,现在更是向移动端转变。这些平台,别说mfc Win32的技术都用不上。

越讨论越深入,但也越离题了。又回到了:语言只是工具,解决问题才是核心;语言都是相通的,精通一门语言后,学习其它的很快;.......
标题主要是针对新手,这个很重要。现在依然有很多搞mfc拿着很高工资的人,也有很多搞mfc分分钟就转java、c#的人,也有很多没搞mfc,但随时可以上手的人,但这些人都不是新手。
对于新手要知道,mfc 是过时的,微软自家都不更新了;现在搞mfc的人很少了,工作需求也很少了;现在是移动、互联网、大数据、物联网的时代,那么多技术可以学习,没必要选一个过时的东西。
作为一个学过mfc的人,确实佩服楼主写那么多、回复那么多。跟楼主一样,劝新人,换一种技术学习。

pc出货量持续下跌,手机终端已经成为人们连接互联网的最主要手段,传统pc上的应用越来越少,各种开发工具层出不穷。死抱着只能做微软的windows下的终端应用开发的mfc真的符合这个时代的发展要求么?

如果你已经在mfc浸淫了数年,有所成就,不反对你继续使用。如果是新手还是绕道的好,不说开源阵营的qt,java等等可以选择,就是微软大一统的windows10对mfc的支持也是有限的。

与时俱进才是王道。

自己看看都说了些啥。win10和MFC有毛关系?难不成在win10上无法使用MFC开发程序,或者开发出的程序在win10上运行不了?笑死人了。

MFC程序仍然能运行在Windows 10的PC上,不过8英寸以下的Windows,MFC还能运行吗?借用你的语气:“8英寸以下和MFC有毛关系?笑死人了。”是,跟MFC是没有关系,你告诉我为什么新出来的技术都跟MFC没关系呢?不这进一步佐证MFC的面越来越窄,微软已经把8英寸以下Windows 10免费,这是多大的市场?

请问博主如何学习COM,ATL,WTL。明说学这些东西就是为了进某公司。。。(但这些东西要完全自学)。 在下对Windows编程刚入道(不超过3个月),看过《Windows程序设计》,《C++templates》,《How to pragmme C++》,《C++ primer plus》,会一点MFC(拖拉控件的编程),请问如何学习COM,ATL,WTL这些东西,我隐隐觉得这些东西(ATL,WTL,MFC)许多组件名字相同,博主能给小白点建议么,感觉(COM,ATL,WTL,MFC)小公司不会采用,技术门槛高,而我又是自学,资料感觉少而老,但是C#这些东西大公司又不会采用,目的就是进莫公司,希望给点建议,非常感谢

COM,ATL,WTL 这几个都不建议学了,不行就换个公司,学了以后用处也不大

嵌入式,wince,MFC使用中。。
桌面平台,我用c++ builder,安卓平台,我用c++ builder,IOS平台,我用c++ builder.....

在嵌入式上,由于硬件机能的限制(CPU频率低,资源紧张),用C#有时候无法完成任务,虽然WINCE 5.0,6.0及以上,都支持C#开发的.NET程序,但是运行起来,那嵌入式板子真心操不起来啊,操不起来。。。。

一个200MHZ的CPU,要串口告诉通信,要ISA采集波形,要支撑1204*768分辨率的屏幕显示,画图,这时候除了MFC,我想不到另一个在开发效率,维护成本,运行速度上能平衡的方案了。当然,你要是不考虑开发周期,直接上C语言,汇编什么的,就当我没说。。

老的板子还会在wince上继续做下去,与MFC算是相濡以沫吧,关键是wince也不发展了,不管是嵌入式,还是桌面,还是其它,全都统一成windows 10了。我们也看到,跟MFC同一个时代的c++ builder转型初步成功了,不过我们也有一丝担忧,在开发语言、框架和工具纷纷走向开源和免费的路上,未来c++ builder的商业模式还能走多远?即使历史上,MFC跟VCL比也差多了,只不过MFC挂在微软的旗下而已。

我觉得推荐学MFC的人就是故意想误人子弟(因为他自己被这个落伍的技术套牢了)。对于it行业新人,iOS、安卓、js、这些技术不去学非要学落伍的要淘汰的技术。真是蛋疼啊。我曾经也是从MFC的坑里跳出来了,尼玛现在新系统谁还用MFC啊。现在新项目都重点放在移动端、web端。尼玛学MFC还不如去学微信公众号开发。

一句话说了:现在新手还学MFC。。简直是傻逼。。

mfc早过时了,新人还是远离一点好

mfc,没饭吃。新人完全没必要学习mfc,这种古董的东西了。如果是学习windows编程,应该从基本的win32开始。mfc现在完全不符合当下高要求的用户体验。win32 + html + css, direct-ui 此类技术的应用,更是让mfc更是被边缘了

看到帖子很高兴,看完帖子很悲哀。
都说中国进行工业化升级,没想到楼主依然是官僚体系的思考方式,而且这种思考方式在我的世界里还是很多,做任何事情都要抨击别人,总是以自己的尺子去测量世界,不符合自己尺子的人都是错的。摆正位置,统一思想,这种官场上的东西真是害死工业界的小白们。
我们现在开上汽车了,自行车就过时了,就要被淘汰了。我们吃上肯德基,麦当劳,就告别大米白面了吗?整个国家的软件水平都在一条线上吗?北上广不用的技术,去那些二三线城市也不用了吗?你所在的计算机领域不用的东西,别的领域就不用了吗?
你的世界太小了,你的视界太狭隘了,去看看工业一线的企业吧,他们很需要那些物美价廉的MFC软件的,MFC确实是已经过气了,但是真的没有过时。
小资程序员的通病,眼界小,心眼窄,确总是觉得自己就是全世界

离开应用场景和行业来讨论什么语言,什么框架,什么库有没有用,过没过时,是不准确的

写windows界面程序,要求发布的是本机代码,那用什么好呢?
我用win32API 写的,不过开发效率确实低

使用MFC并不是因为MFC好用,而是因为在要求本机代码发布的windows软件开发过程中,能使用的图形界面库寥寥无几。Delphi的本机代码版本早已不再继续开发,Qt因为过于臃肿。至于wxWidget则直接是MFC的封装。至于所谓的.Net Native,离开winRT就不能用了,更何况winRT软件只能在微软商店发布。

winRT对win7和XP无法支持。放弃win7和XP市场是不可能做到的。另外.NET NATIVE 并非纯正本机代码,而是缓存了预编译的部分,避免打开时重复编译。另外.NET NATIVE不能离开.NET FRAMWORK运行,而且运行效率与本机代码相比还是有差距。

可能大家各自的圈子不一样,所以观察到的现象也不尽相同。我怎么觉得,Delphi可比MFC惨多了?
MFC至少在工控领域还是能够很经常地见到的,Delphi至少在我周围的圈子里已经绝迹很久很久了。

史前的一场大决战,巨硬派了MFC,破筐派delphi,二将正杀得难解难分,突然四面楚歌,再一看旌旗招展,原来双方早已身陷重重的包围之中。破筐想逃,却逃不出去,只好带C++Builder一起杀入重围与delphi并肩作战,左突右冲,损失极其惨重。巨硬一看各路诸侯来势凶猛,自知抵挡不住,只好让MFC断后,自己带大队人马杀出一条血路,巨硬大呼:“吾头尚在否?吾头尚在否?”后来,背靠Windows天险,厉兵秣马,准备另辟蹊径,来年再战。可怜MFC孤军作战,没有援军,没有补给,也没有撤退的集结号,只好拼命了。

我想提醒各位,不要总是以 IT 人的立场来看待问题,在工程师中,除了 IT 工程师,还有很多其他的工程师,比如说航空工程师、自控工程师、电气工程师,他们也会是Visual C++的用户,不妨也听听他们的意见,听听他们怎么说,这样你的想法就不会那么偏激。反正,不管你们怎么唱衰MFC,但MFC一时半会儿也死不了,再过十年也死不了,甚至到某些人将来已经从程序员、软件工程师的职位上改行去做别的事情、完全脱离了IT业,到那时MFC说不定也还活得很好,在工控领域、在航空领域、在能源化工生产制造领域,依然发挥着中坚力量。

废话那么多,拿工资出来说事就好了。

学校学MFC的,到了公司基本用不上,大家都有自家UI库,MFC从来都是个烂摊子。

要理解设计模式,直接学设计模式就好;要理解windows api就学win32。

当然,有些山顶洞人程序员和公司,还在用MFC我就不知道了。

还有句话给新人:来说是非者,即是是非人
win98没玩熟,就追捧win2000的人多得很
win2000没用出啥头绪,就追捧winXP的人多得很
winXP才一知半解,就改道追捧win7的人多得很
这些人现在正追捧win10呢,他们的见树呢?他们的应用呢?
当然,今天,你不可能再拿WIN98给别人装机。
但你觉得追捧win10就正确吗?
其实,追求核心的人牢牢抓住本质,
能用win98避开缺陷完成目标,也不会因用WIN10的臃肿而阻碍目标
绝对不会因为一个所谓的过时和所谓的流行的概念就盲从。
只有表象才会过时,本质不会
提出过时和流行概念的人,或许有几分道理
但绝对都只是一些浮于表象的投机之徒
用投机的心态去找的饭碗真的能吃饱吗???

用MFC的(虽然我不用,用的是WTL),可以用擅长的C++语言, 可以方便的调用C/C++类库(系统或第3方), 可以嵌入各种脚本语言,可以方便极致的优化. 
当然如果一开始就学的C#, 真的没有必要再学MFC.
当然qt作为界面开发也行, 但是这个库实在过于庞大, 和STL也没什么事了,所以我推荐如果要用, 可以用WTL开发界面, 简单的对Win32封装.而且只是界面, 其他库完全可以用stl或第3方库什么的.

很奇怪,好像学MFC都不学别的了. 搞技术还是多学点好, 原理是相通的, 设计是可以借鉴的.
Windows搞界面就选这几个,如果是C++为主要语言:
wtl,duilib,qt(qt真心不建议,qt的学习成本也不低,不过好在难逆向)

不建议用wxWidgets, 搞了wxWidgets 3年,不是所说的那么容易跨平台,很多bug,不稳定, 莫名其妙的崩溃找源代码修改编译真是费时费力. 开发速度真没有使用本地sdk开发高, 很难定制复杂的控件和界面. 定制了复杂的控件后崩溃发现它的基础的类库有bug, 后悔浪费那3年时间.

如今流行拖拉机耕地,你丫到云贵高原耕一个我看看?
反驳哥的极端证明不了你们的极端,因为哥的极端本来就是拿来放大你们的极端的
你们说选择任何一样都可以完成MFC的
我只想问你们选择的任何一样流行的东西又有那一样是MFC做不到的????

不要再自以为是的鼓吹流行与淘汰了,图样图森破
高铁消灭不了飞机
飞机消灭不了汽车
汽车流行了,消灭不了摩托
摩托流行了,消灭不了自行车
自行车消灭不了马
马也消灭不了骆驼

你看不到自行车,那是因为你只生活在城市的中心
在你的生活圈子看不到的,不是数量减少了,而是你座井里了

马的功能有很多种,不管是代步还是作为食物还是作为运输还是作为生态之一,它都不是地球的必须
按你丫的思维,不必须的就没有必要了,那马早绝种了。

可以用马代步,也可以用汽车。没必要非得会骑马,才能学开车。对于绝大多数而言,直接学开汽车是个省时省力有效的方案。

各有所长

你要是做电商系统,作为一个架构师

你需要会分布式缓存,分布式文件系统,cdn,这些都是c/c++写的

还包括分布式消息中间件,配置服务器,数据库分表分库中间件,这些是java写得

消息推送服务器物,现在这个一般用go写

还有基于dock的容器布置技术,这是用python写得

当然了,数据到了pb规模,牛逼的团队还需要自己写分布式数据库(比如淘宝的oceanbase,那可是一帮搞java的人,用c++写出来的)

把这些都熟悉了,才可以搞什么web,服务层的分层设计,支持pc ,手机的api接口

然后,手机你又要基本熟悉andriod的java和ios的oc/swift

现在的互联网公司,架构师需要熟悉多种语言和技术

并不局限于java 或 c++

Windows编程革命简史 | | 酷 壳 - CoolShell https://coolshell.cn/articles/3008.html

主要部分来说是这样,CDC是HDC的封闭,CWnd是HWND的封装,CSocket等等。。。。但CDocument什么的却不是内核对象的封装,想要深入学习内核,还得学习API,而不是在MFC里绕。当然,要不要学Win32 API,还得看工作需要,如果是开发360之类的软件,那是必须要学的。如果是ERP之类的软件,你用Win32 API来开发界面,那就舍近求远了。

MFC上手慢,通常是错误的学习顺序。
C++ Win32SDK,不说精通,懂得差不多的话。MFC只需要一个星期。

时间关系我就简写了,你说的STA,MTA这些,clr的一个三级命名空间下都涉及到,并且还要研究managed与unmanaged之间的内存,线程,运行单元等的关系。这是不是也不浅?最大的区别在于,.Net(WinRT)想快速出成果的时候可以轻装上阵,而要深入又可以随时间循序渐进、层层深入,进退自如多好呀。所以MFC不是通往Windows核心的唯一道路,并且现在来看,甚至可以说是一条古道。当然对于已经掌握的老手而言,已经摸爬滚打练出来了,0成本 ,不需要进一步的时间投资,所以不需要彻底放弃。
再换个角度来讲,即使有的人压根没接触过这些,学的是Linux,gcc,java等等,照样是高手,所涉及到的技术更深。MFC作为起步的一种方式,只能说作为经验,难道还有相对的优越感吗?
另外,难道学MFC的人境界比学别的境界更高?这个我理解不了,我只能理解MFC比VB6在技术上更有深度。我理解的学习境界,“三人行,必有我师焉”是一种境界,“人不知而不愠”则又是另外一种境界了。

作为一个在IT界摸爬滚打了10来年的老人来说,我还是比较同意楼主的观点的。想当年也看侯捷的深入浅出MFC看得如痴如醉,不过就现在来看的确MFC属于过时的技术,市场上老板才不会纠结一定要用什么技术做出产品,说到底都是生产力,你能用更少时间更少预算做出更好产品才是老板关心的,从这个层面出发MFC不是一个好选择。再说MFC带给我们从思想上的改进也没那么明显,如果磨练编程思维宁可去学不会被淘汰的譬如算法,数据结构,做产品要效率还是要用现代的语言和框架。所以MFC在编程效率上慢(不是运行效率),在思想提高上也不明显,加上招工机会少,放弃学习反而是比较明智的选择。

不用MFC开发C++的Windows客户端,还有更好的选择吗

开发C++的Windows客户端,这是必须的选择吗?

当然不是必须的,还有C++/CLI,QT,Win32,...
但是MFC比CLI门槛低,比QT资料多,比Win32开发快,所以对于用C++的新手,MFC是最好的选择。

Windows 2000泄露的源代码,我记得有不少是MFC的。

Visual Studio 6,2003,2005,2008,我一直以为是MFC界面。
Visual Studio 2010,2012,2013,2015,我一直以为是WPF界面。

Office 97, 2000,2003,我一直以为是MFC界面。用Spy++看过,有窗口句柄,至少不全是DirectUI。
Office 2007,2010,明显风格不同于以前,属于DirectUI。
Office 2013,使用了.NET框架,但界面是WPF还是DirectUI的呢?
其实无所谓了,我想如果微软还在用DirectUI,DirectUI的界面描述语言也应该是Xaml了,Xaml也是DirectUI不断发展的成果。

以上都是我的假想,不去考古了,欢迎拍醒,非常感谢。。

VS2002 - VS2008 IDE 是一套代码发展过来的 .net 的
VS2010 - VS2015 IDE 是又重写的,应该是WPF。
像是记事本 画图 扫雷 纸牌之类的,都是直接 windows sdk。
office 可以肯定地不是基于MFC的东西。

MFC更重要的是一种编程思想,SDK是C的WIn API, MFC是C++的 Win API封装,没MFC, C++下的Windows编程就没法展开。承认现在C#, Java很火,但并不影响C++在工业基础性软件方面的调用。目前很多MFC的标准UI库已经做得很完善了。MS自己的Office, Visual Studio都MFC编写的,这没什么异议,很早就有定论。
比较好的MFC基础库有:
1、Codejock的Xtreme Toolkit Pro.
2、BCGSoft的BCGControlBar Pro.
3.、UCanCode的E-Form++ (重点推荐)