再论MFC与QT
打开CSDN,突然发现最近在黑MFC。其实讨论的重点就在于一点“新手要不要学习MFC”。所以希望双方的辩手在辩论时千万不要偏离了重点。现在我作为中立方来评论一下。
其实,目前在windows下的开发,选择并不多,无非就是MFC和QT,其他的第三方还有一些库,但使用的范围不大,所以就排行榜前2名进行讨论。在今年的微软开发大会上,我很有幸提问了一个问题“我发现今天大会上展示的例子多是用C#编写的,微软是否在有意淡化C++的地位。对于C++来说,多年来几乎没有发展,例如在GUI方面,C++实现十分麻烦。在微软内部,对于这两种语言的发展是如何定位的?”。来自微软的技术人员,听完我的问题后,不约而同的摇头,其实,微软并没有淡化C++的地位,相反,微软在C++上面一直不懈的在努力。但我们可以清晰的发现,微软在同时走两条路,一是夯实基础,就是C++基础方面。C/C++属于中级语言,相对于VB,C#之类的高级语言麻烦,相对于汇编语言之类又简单。所以C/C++是面向高性能用户的,CryEngine,Unreal,Frost等世界顶级的游戏引擎底层用的是什么,虽然我看不到他们的源代码,但我肯定是C++的,为什么?高性能的需要,只有C/C++接近硬件似得操作使得可以最大限度的对硬件资源和算法进行优化。当然,代价就麻烦,学习起来十分困难。当然,大家又有人喷了,我又不是开发游戏引擎的。是的,你不用,不代表这些方面没有市场,有人要用。你可以用简单的,微软不是给你准备好了C#了吗?一会再说。微软近几年在C++上面的努力是有目共睹的,我简单的列举几个方面,VC6作为经典的一代,但有很多弊端,如语法检查不严,最头疼莫过于for(int i; i < 10; i++ )的定义,VC6是不支持的,但从VC7(2003)开始就立刻纠正了这个问题,对C/C++的支持越来越好,随着Borland的没落,微软成了最大的,实力最强的C/C++的编译器。2005当时是对C++标准支持最高的。由于MFC对界面支持不好,从2008SP1开始,微软收购了BCG界面库集成到MFC中,但那酸爽,实在是……,显示效果一团糟。所以从2010开始,微软估计从底层调整了界面部分,而且,最让我欣慰的是,VC6的经典Classwizard又回来了。至于2012、2015等新版本,不好意思,我没有过,无法评价。而且VC是个很庞大的东西,我也只是用到了仅有的一点点功能,很多功能都用不上,所以我的评价也不够客观。但仅从我用的这点功能就可以看出微软一直在进步。而且还可以看出,微软在C++的努力确实不多,为什么呢,因为毕竟面向的是少数的用户,所以从战略上讲,微软确实不能投入过大的经历。引擎类的公司有几个用MFC的?人家用自己的库。正式因为微软对MFC的定位,所以微软大力在发展C#,C#在跨平台,快速开发上确实有优势。
再说QT,QT是一个跨平台的库,QT相对MFC来说最大的优势就在于GUI的开发,我们也一直在想,对于微软这样的公司来说,使用拖拉控件的方式很容易的,而MFC在GUI方面一直没有努力。因为微软认识到,即使在这方面做好了,意义也不会很大,不是吗?不如把有限的资源,放到C#上。QT号称的跨平台其实意义不大,最大的好处在于GUI的快速开发。而且QT也有各种丰富的集成库,可以实现各种功能。QT我用的不多,所以不做过多的评价。
至于新手学什么,要看你做什么,如果是在校学生,时间比较充足,学什么都可以,MFC也不是打基础用的,基础是C/C++算法,算法数据结构之类的才是基础,MFC只是一个工具而已,就MFC而言,我也只是用对话框而已,什么单文档,多文档从来没用过,学MFC也不是全部系统的都学。如果是已经工作,或是面向工作,QT也是不错的选择,主要要根据所从事的项目来进行选择。
所以最后而言,我的结论就是,争论的意义不大。因为,QT和MFC就是两个工具,好比WPS和WORD是两个编辑器一样,无所谓哪个好哪个坏,选哪个都是一样的。你可以问一下使用QT和MFC的人,没有谁把整个全学会的,比如QT,都只是使用了一点小功能而已。然后从一个小功能切入,逐渐了解整个架构。大家都说QT的优势在于界面功能强大,仅此而已,其实,MFC中界面是麻烦了一些,但也不是不可接受。做过项目的都知道,程序中最重要的是架构,其次是算法,最后是界面实现。架构和算法都是独立于编程语言之外的,虽然我没学过QT,但我维护过QT的项目,可以很轻松的维护,以为具体的思想是一样的。所以,最后,无论MFC还是QT都不要互黑了,各有优劣,真正到项目里面,无论QT还是MFC都用不上,用的是基本的算法思想。