VC不是梦想，C++需要自由的心
C++是开拓者的语言，是思想者的语言，是“高手”层次之上的语言。或许在实用性、简单性方面，现在和将来都会有许多语言不断地超越它。但是，我认为在相当长的一段时间里，在构造和表达软件工程思想和创造性软件的开发领域，不会有什么语言能超过它。
关于对于VC/MFC/ATL的评论问题,其实我很早就想写一篇文章来阐述自己的观点,不过又觉得这种容易引发论战的文章实际上是在空耗大家的时间, 不如做点实际工作. 但是现在中国程序员群体的思想走向已经到了一种非常危险的一边倒的地步,上几期电脑报上登出了几名14岁的小孩子, 刚刚学会写几个程序, 就把VC列为自己的梦想. 我去年找工作的时候，连续被几个公司问会不会VC，得到我的答复之后，他们怎么也不能相信一个学了四年C，两年多C++，还利用“空闲”时间学习了Java、Perl的人，一个敢于在“专长”一栏里写上“掌握C++”的人，居然只是对VC“略有了解”，我从他们的表情中看出一种不屑：“你还敢说自己懂C++？你还有时间去学别的东西？连VC都不会，水平能高到哪去？”我并没有费力去向他们解释VC外面的世界更精彩，因为之前我在提到STL这个词汇的时候，已经留心他们目光，那是一种冷漠、茫然和无动于衷。一切都已经十分清楚，解释是徒劳的，他们根本不知道VC外面还有C++。
当然不劳大家担心，我最终还是找到了一份满意的工作。但是这种经历对我的触动是很大的，因为我已经深深地感觉到，当我们中国的程序员好不容易能够有机会以一双开放的眼睛面向整个世界的时候，我们的思想又被迅速地封闭了起来。一个叫微软的巨人用一只巨大的圆规在我们的思想里画了一个大圈圈，并且对我们说：“天就是这么高，地就是么大，你们享受吧！”伊甸园的生活是快味的，但是，当我们所有人都被牢牢地限制在一个范围之内，听命于一个上帝的清规戒律时，我看不到我们自己的未来还有什么希望，我甚至看不到我们自己存在的意义。
不自由，勿宁死！
我们的能力当然是有限的，在相当长的一段时间里我们所能到达的疆界还是会远远地小于先驱者开拓的界域。但是我确信，就在现在，我们的能力至少可以突破微软给我们划定的天地。微软是好的，她很体贴，很出色。但是不论是微软也好，巨软也好，在我们程序员的心中，没有凯撒。我们可以把你当朋友，但是你别想做我们的主子！我们一定要走出去，虽然我们知道极限是存在的，很长时间里我们是不可能超过前人的，但是我们一定要出去。我们可以因为累死而在探索的道路上而止步，但决不能在人为设定的篱笆前畏缩不前。
C++是我最钟爱的语言，我愿意投入一辈子的时间在她的身上。VC也是一个好东西，在Windows下我最喜欢的C++编译器。MFC/ATL也都是好东西，如果将来需要，我也会认真地学习它们。但是，我心中的天地比这要宽广的多，标准C++所定义的语言性能集和标准库，是更加绚丽的风景线；STL所带来的通用编程时代的曙光，更令我心驰神往；设计模式的精美与一致，面向模式编程范式的初现端倪，面向对象软件工程的成熟与巨大希望，TAO/ACE的庞大与精致，我们中国人自己的C**语言的动人心魄，...，让我目不暇接的珍宝太多太多。虽然我所能接触到的东西只是一小部分，虽然在这个过程中我更加深刻地发现自己的水平是多么的不值一提，但是我已经可以大声宣称：外面的世界很精彩！
我知道我们都还是生活在现实世界中的，精神上的快乐不足以填饱辘辘饥肠。但是我们现在是在说C++啊！想想你为什么不用更简单、更好挣钱的VB、Java、Delphi，偏偏要把已经够难学的VC当成自己心中的理想呢？不就是因为VC能够代给你自由、自信和自豪吗？如果你意识到VC同样是道更大的篱笆墙，你为什么不愿意冲出去，获取更大的自由、自信和自豪呢？
B.Stroustrup说：“我想大家学习C++，应该是为了解决哪些开创性的问题，而不是一次次地重复解决哪些已经有了成熟的框架和现成的解决方案的问题。”C++是开拓者的语言，是思想者的语言，是“高手”层次之上的语言。或许在实用性、简单性方面，现在和将来都会有许多语言不断地超越它。但是，我认为在相当长的一段时间里，在构造和表达软件工程思想和创造性软件的开发领域，不会有什么语言能超过它。或者说，精通了C++语言及其思想的程序员，在思想深度和对新技术的领悟能力上上是远远超越其他语言使用者的，我们或许应该称这种人为程序员中的思想者。正因为如此，我认为被限制在VC的圈圈里，不是一个C++程序员能够容忍的。
我觉得，作为一名真正的C++程序员和自由的思想者，更应该有有一颗仁慈的心。不要整天纠缠与C++和JAVA谁好谁次的争论，不要一听说某软件使用VB做的就鄙夷起来，更不要拒绝学习其他的语言。C++难学、难用，距离应用层面比较远，这些问题我们应该坦率地承认，可能的话做出一些努力来改变这些情况。应该积极鼓励把其他语言与C++混合使用，让C++成为它们背后坚实的支撑。我不是公司的老板，但是我觉得，如果我的企业能拥有这种水平的程序员，我会为自己的企业而骄傲，也会给他最高的薪水。
附：
我个人认为MFC实现上的缺陷：
MFC是在89年代末，90年代初定型的，当时C++还十分不完善。在当时来讲，MFC是相当先进的。但是从那以后，C++发生了（可以说是）革命性的巨大变化，与新的C++相比，MFC的体系结构和实现机制显得比较落后，很多优秀的C++特性都没有被合理地应用，反而自己另起炉灶搞了一摊。而且VC这种语言也越来越不象C++了，完全为微软自己的应用而量身定制，甚至不惜违反标准。（不过在编译技术尤其是优化技术上的确还是无人能及）
MFC由几个缺点让我比较不满：
1. 大量使用稀奇古怪宏, 搞的代码不象个样子. 真佩服有些人那么耐心地去分析它们.
2. 消息映射的实现机制十分笨拙. 不用继承我可以理解, 但是为什么不用委托, 而要用表驱动? 还是那句话, 搞的代码不像个样子.
3. 对于底层SDK的封装太薄, 面向对象的感觉不足.(当然也有他的好处, 不过这毕竟是C++!)
4. 自己另起炉灶搞了RTTI, SEH, CString, CObjXXX(Container)这些东西, 实现的又不太好, 早几年还可以理解, 现在则完全落伍.
5. 很多场合本来是标准库可以一展身手的地方, MFC完全没用上.
6. 为了迎合MFC, 编译器的很多地方都违反标准.
7. Doc/View体系的局限性, 想突破很难.
话说回来, MFC还是一套出色的工具. 但是现在它事实上已经成为了对中国C++程序员的一个威胁, 它把太多的精力和资源吸引到支路上面, 而对于主干道上真正的好东西视而不见. 矫枉必须过正, 所以我不惜得罪一大批人, 写了上面的文章. 正如开篇所说, 我一向认为无休止的争论是空谈误国, 该说的话已经说了, 大家可以批评讨论,但我大概是不会再回到这个话题上来了.
如果您对本帖内容有任何质疑，或者您在阅读/下载 本帖内容时遇到困难 请在站务管理版里发帖提出。点这里进入反馈
|
