VC不是梦想,C++需要自由的心

myan 2001-02-25 01:27:00
关于对于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++程序员
的一个威胁, 它把太多的精力和资源吸引到支路上面, 而对于主干道上真正的好东西
视而不见. 矫枉必须过正, 所以我不惜得罪一大批人, 写了上面的文章. 正如开篇所
说, 我一向认为无休止的争论是空谈误国, 该说的话已经说了, 大家可以批评讨论,
但我大概是不会再回到这个话题上来了.
...全文
1269 42 打赏 收藏 转发到动态 举报
写回复
用AI写文章
42 条回复
切换为时间正序
请发表友善的回复…
发表回复
evaiou 2001-03-12
  • 打赏
  • 举报
回复
我是个C语言初学者,因为系里开设的课程是C。现在考程序员也只能用C,可现在C似乎不流行了大家都在谈VC,java,Delphi..........
至少也是C++。我都看昏了。小弟不知道是否还有继续学C的必要,真的好苦脑,请各位好心的大行了虾指给小弟一条生路吧。
blindcat 2001-03-11
  • 打赏
  • 举报
回复
俺是菜鸟,但俺用c++builder
ppzhao 2001-03-11
  • 打赏
  • 举报
回复
请问各位高手C++用何编译工具好(VC,BCB,BORLAND C++,GCC)?不用MFC可编出窗口吗(WIN32)?
slzm 2001-03-11
  • 打赏
  • 举报
回复
俺是菜鸟,各位前辈说的我听起来都有道理,因为都听不懂.嘿嘿~~~见笑了!
我十分同意onion的"市场决定一切",微软是的市场战略比它的技术战略作的好,同时中国的程序员一般都还要养家糊口,自然什么"红"学什么了,MFC大行其道这也难怪.
blindcat 2001-03-11
  • 打赏
  • 举报
回复
关注
brucegong 2001-03-08
  • 打赏
  • 举报
回复
如果仅是嘲笑VC,而没有脱离C++,那就是五十步笑百步了。(我也没有脱离C++,所以也算是五十步笑百步)。
首先,为中国的程序员乃至软件业默哀吧,狗娘养的比尔,他的预言实现了。十年后他来中国收钱,没人敢不给。想一想什么第二道非公开密钥······
VC只是一个商业上成功的东西,有一定的创意。十四岁的小孩,不懂事的嘛,何必跟他们一般见识呢?就算是尽前辈的责任教导一下,也务必言语谦和。
C++好像不怎么完善,而且效率也并不高。充其量,算是软件工程上的一次重大的尝试。软件工程没有止境,所以它也不是终极产品。说到重要,好像还比不上汇编语言的出现。尽管那时候软件工程的概念不是很强,相信也有许多人------比现在的比例要大得多的人-----认为汇编语言就是终极产品了。要不然怎么解释它至今生命力顽强?
还有一点,如果我没有猜错,现有的几个主要的windows平台的C++版本都是在C的基础上实现的。也就是说,可以认为凡是C有的毛病,它没怎么减轻,然后又引入了一堆其它的毛病。又一个解释是要使用完全的C++语法------这可能吗?我们现在不是还动不动在C中嵌汇编?而且,往往还是C搞不定的地方用!在前几年,C也是挺火的,这几年是C++,将来会是什么呢?不管怎么样,泥巴眼光后推几年,孰是孰非就很清楚了。在这里发贴子论战,哈哈,我们在争吵,比尔知道了不知会多高兴,那么烂的东西还有人替它辩护。置于C++,如果你是发烧级的程序员,学好它,然后列出它的不足,让大家“慎用”,出不了几天,肯定会有一个更好用的东西出来。到时候,别忘了不要崇拜就好了
leeguoxun 2001-03-08
  • 打赏
  • 举报
回复
热血沸腾
gaoxianfeng 2001-03-04
  • 打赏
  • 举报
回复
我想大家都是在为中国的软件业担忧,用心,目的都是一样的。
是,现在很多人吃着这碗程序饭,但其实是只是对一些工具软件的应用。(不只是在说程序设计)
乱用一些集成的开发工具,图个方便省心,不求甚解。
我们所能做的只是用自己得行动感染周围的人,别做国外软件的奴隶,用好它开发属于我们自己的一片天空。
c/c++是属于世界的,但其它的就不敢说了。。。

胡言乱语
opkj 2001-02-28
  • 打赏
  • 举报
回复
to myan()
不知道为什么我在csdn上,火气一直比较大,因此我不太来这里。我一直在delphi/c++builder论坛上,最近关闭了。
宏的问题,我觉得没有什么可讨论的。这是技术和性能的一种平衡。
C的魅力在于在于这种平衡。完全的封装非常可怕。我一直认为不同项目级别提供不同的要求。
至于表驱动。这是最基本的数据结构,也是最简单的数据结构。在某些情况下,也是最快的数据结构。想想,message和handle。在操作系统级别使用hash都是浪费。vc从sdk来,他这么使用应该可以立即。
我不太喜欢vc。或者可以说喜欢vc,就像喜欢delphi一样。我是因为你的贴子中有“自由的心"才看的。但我想说的是光自由还不够!作为程序员,“平衡”才是最重要的。
我相信你是一位富有经验的程序员高手,对于我过分的言论,我表示道歉。
San_Daniel 2001-02-28
  • 打赏
  • 举报
回复
1.MFC的消息映射方式的确不甚高明,但是在设计大型类库过程中,有很多问题是难于处理的,人的精力终究有限,想方方面面都达到最完美是很难的。

2.以前也喜欢嘲笑MFC,但自己实际动手设计大型类库时(C++),却发现许多困难始料未及,回头仔细观察MFC时,才真正发现MFC的亮点——精密。于是从MFC中借鉴许多东西,甚至包括常数名称定义和文件组织划分。而这些细节往往决定了一个商业软件的市场——只有做过的人才能体会。其实在这些细枝末节的处理上,正体现了微软一种令人敬畏的大局观。知道么,并不是所有优雅的思想都能在现实中很好的Run起来,不要从艺术的角度去要求MFC。

3.我理解所谓稀奇古怪宏,因为我在我们公司的底层类库中也定义了一个类似的东西。这么做只有一个原因——与其实现430段类似的代码不如定义一个希奇古怪的宏!

4.我热爱OOP模型,但我也知道它的缺点:首先是难以跨平台——这曾让我刻骨铭心;其次是只能实现源程序级的代码重用,工业应用有问题。

总结:闪烁着智慧光芒的设想可能永远无法变成现实,冒着傻气的方案也许是唯一的选择。在嘲笑一个软件时,你很难了解到开发者的血泪。
spdia 2001-02-28
  • 打赏
  • 举报
回复
看了myan兄的文章感触颇深,想起了自己在编程时一次次被include的重复定义所击倒.
也许名字空间可以解决这个问题,然而可以说正是这一次次错误使我在分析错误产生的
同时对语言有了深刻的理解,使我能够读懂msdn,并从中独立找出解决问题的方法,我想
STL等大量方法的产生正是大量的编程的实践中总结出来的,然而那一项编程方法的提出
有着中国人清晰的烙印呢?空谈误国,只有知道的那不行才有可能解决.在学会走之前,跑
是不可能的,另外在枪炮发达的今天,不仍有人学武术吗?


marmoset 2001-02-28
  • 打赏
  • 举报
回复
我觉得微软的MFC和其它技术,并不能说是技术上最先进,最简捷的。但是它们在技术的完美性和现实的无奈之间找到了某种非常合理的平衡。
其实从很多书籍和资料上我们都能了解到:微软有太多顶尖的技术人才,这些人恐怕比我们所有的人都更清楚的掌握了所谓最先进的技术,但他们之所以对此有所取舍,必然是因为考虑到平衡的问题。因为如果你的产品只是针对非常特定的领域或者用户,自然可以非常快的把新技术反映进产品,而如果面对的是如此庞大的一个用户群体,恐怕就不能不考虑产品和技术的稳定性了。
MFC也好,STL也好,都是针对某些问题才能具有最佳的表现,但谁也不是包治百病的良方。
mistl 2001-02-27
  • 打赏
  • 举报
回复
My God!
路漫漫其修远矣......
liuer 2001-02-27
  • 打赏
  • 举报
回复
哈哈哈,更坚定了我学C++的信心,好希望微软死桥桥哦
myan 2001-02-27
  • 打赏
  • 举报
回复

to opkj:
写这篇文章本来就做好了挨骂的准备。即使你们说得再刻薄,我也不会生气。
至于你们认为我不懂C/C++,我倒不否认,虽然苦学了5年,不敢言“懂”字。
说我不了解VC,我也认可。毕竟没有认真用过,只是为了了解粗浅地研究过。
不过说真的,我真的没觉得MFC有那么高深玄妙,值得大家如此崇拜。微软的
技术水平强在整合,弱在特色,整体而论无以伦比,分解到各个技术领域则
几乎都不是最突出的。你是搞Delphi的,觉得Delphi的事件委托模型比之
MFC的表驱动事件模型如何?COM比之CORBA如何?Windows比之UNIX如何?
SQL Server比之Oracle如何?Exchage比之Lotus Notes如何?Word比之
LaTex如何?微软之所以强大是因为所有这些对比中略逊一筹的产品居然来
自一个公司,而所有优胜者却分别来自不同的厂家。跟你一样,我也很佩服
微软,很钦佩它对于市场的把握和行动的有效,特别是其独特的企业文化
和运作形式。但这种钦佩并没有转化为迷信和盲从,也没有使我丧失最基本
的技术判断力。我对于SUN/Java, Oracle,Intel公司基本上也持相同态度。
我相信有伟大的思想者,但不相信有完美的公司,更不认为任何公司能够永远
占据整个市场的80%。我写那篇文章的原意就是希望大家能知道,权威到达极至
的时候,也就是革命开始萌芽的时候。我们决不能像19世纪的物理学家一样匍
匐在牛顿的脚下。历史已经无数次地证明,伟大的变革往往开始于众多小人物
的不自量力。我请大家冷静地想想这个问题。

下面就你的看法中所涉及的几个技术问题谈谈我的看法。
1. 宏基于预处理,不属于语言范畴,而且能力太强,难以限制。可以做一些非常的事
情,大量泛滥,及其不利于软件的可读性和可维护性。ANSI C++对于使用宏
是非常谨慎的。我阅读97年之后的C++文献,发现有些地方大师们对于宏的
避讳已经到了有点神经质的地步。这我可以理解,滥用宏是C使用者的老毛病,
矫枉必须过正。ANSI C++里已经提供了很多好的机制来取代宏,除了十分必
要的场合,一般而言不要使用宏。MFC出于90年代初,正是宏的被无限利用的
癫狂年代。其实不久情形就发生了变化,到了95年,Java语言里完全没有了
宏的踪影。当然,我不否认在C中,宏还是有它的必要性,不然的话GCC也就
没理由在这方面作那么大的扩展。至于你猜测我见到C代码就会晕倒,不才当
年用C是写起宏来也很匪,也与Linux源代码打过几个月的交道,现在偶尔读
Richard Stenvens的TCP/IP第二卷,感觉还挺得住,谢谢关心。

另:我确实觉得MFC里的宏算是所有流行产品里最复杂的了,如果你看到更复杂
的,请介绍给我。既然你对于宏感兴趣,我出个题(C++):
请写一个宏,每次调用它的时候定义一个匿名变量,变量类型由宏参数决定,
但是请注意,在同一作用域里用户可能多次调用这个宏,你要尽最大努力保
证编译器不会抱怨Redefine variable.

2. MFC事件机制不够优美早已是公论,从OOP的观点来看,甚至比它早的Borland
OWL库在这一点上都比MFC强得多。至于你说到继承的代价,我估计你是想说
虚函数和多态的代价。首先,这个代价被夸大了。其次,代价确实存在,
所以从MFC到VCL再到Java2 AWT/Swing都没有使用最自然的继承模型来解决
事件机制。我也说得很清楚,不使用继承是可以理解的。但是MFC使用了表驱动
的方式来实现事件响应,实在是不漂亮。对于这个问题,Delphi就解决得很好,
delegation(授权或称委托)是四大代码重用方法之一,非常清晰优美,而且没有
虚函数的负担。虽然C++不支持closure操作,或者说不支持透明提交,但STL里
提供了一个mem_fun函数对象,可以非常轻松地仿真透明提交。MFC诞生的时候,
STL还没问世,不过微软如果把用在构造那些稀奇古怪的宏上面的精力拿出一半
来,这个问题根本就不成其为问题。一句话,MFC对于事件机制的封装,就是表
面上故弄玄虚而实际上没有封装。如果没有ClassWizard,我担保那些宏能把
80%的人弄晕。

3. 我指责微软的编译器不符合标准,是因为它是微软,是最有能力最先研究出最好
的C++编译器的厂家,然而处于私心,微软对这项事业关注明显不够,现在,几乎
所有的C++编译器在标准化方面都比VC强,难道MS不该指责吗?你说你用过4,5
个编译器,没有标准的,确实不错,目前还没有哪个编译器敢说自己是标准的。
但是你使用Borland C++5.5.1时会感觉到,这个编译器已经非常接近标准,令人
满意了。可是VC连下面的代码都要报错:
for (int i=0; i < 10; i++)
;
for (int i=10; i > 0; i--)
;
要加上不常用的/GX编译参数才能处理try..throw..catch块,..VC1.5里用到
template时编译器会对我说:“Sorry, the template keyword is still not
supported.”现在微软威风了,什么提示都不给。我使用VC时提心吊胆,不知道
什么时候用到的标准特性会不被支持,也不知道什么时候用到了VC支持的非标准
特性。连微软自己办的Visual C++ Developer's Journal主编都对此极为不满。
要是Bill Gates知道遥远的中国还有这么多人替他找挡箭牌,真是应该高兴的做
梦都要笑出声来了!

篇幅已经够长,我不想多说了。总之,我是站在今天的C++技术水平上谈论一个
10年前成型的产品,对这个产品有非议是正常的,实际上我自己对于MFC的缺点
是可以容忍的。我不能赞同并且非常担忧的是,在我们中国有这么多人把这个
技术上早已经没什么新意,甚至可以说是过时的产品,当成理想中的C++最高峰,
这对于我们中国C++程序员群体而言,是一大悲剧。当年候俊杰先生写MFC深入浅
出时,是一个伟大的先行者。候先生之后,数以万计的VC迷们掩杀而至。那么候
先生今天在研究什么呢?还是MFC吗?请大家深思。
kyokyo 2001-02-27
  • 打赏
  • 举报
回复
呵呵,有意思!!!
C++当然好,面向对象当然Wonderful,但是,任何东西都是两方面的。
期间是使用方便与代价之间的矛盾。
MFC是精彩的设计模式,是精彩的框架。RTTI是它实现的,那是C++还没有
那东西那!MFC设计者是天才,比C++提出RTTI概念更早。概念是最宝贵的。
谁能先提出,再推行,就是天才。
盖茨是天才,他以前是计算机高手,Unix高手,Mainframe高手,但不是天才。
当他说:“Windows 能赚钱,人们需要这个”,那就是天才拉
dreambuilder 2001-02-27
  • 打赏
  • 举报
回复
关注!
Virtual 2001-02-27
  • 打赏
  • 举报
回复
和和 我觉得象蜻蜓点水一样 才是得道的
Virtual 2001-02-27
  • 打赏
  • 举报
回复
和和 我觉得象蜻蜓点水一样 才是得道的
Virtual 2001-02-27
  • 打赏
  • 举报
回复
和和 我觉得象蜻蜓点水一样 才是得道的
加载更多回复(22)

15,440

社区成员

发帖
与我相关
我的任务
社区描述
C/C++ 非技术区
社区管理员
  • 非技术区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧