69,369
社区成员
发帖
与我相关
我的任务
分享对那篇恶作剧文章的想法
你们一定知道是指哪一篇，就是所谓的对C++之父的访谈，本来可以一笑而过，但是仔细想想，却发现，它并非那么荒诞无稽。于是，将它作为了假想的敌人，写了下面这一篇。也许有人觉得有些小题大做，那就把它当作恶作剧的续集算了。
-------------------------------------------------------------------------
说实话，当我看到这篇文章时，我和其他所有C++程序员（虽然我大部分时间用的是VB）一样，感到震惊。难道大家这么多年的劳动成果只是一个玩笑？当我们一觉醒来，上帝对我们说，一切都是虚幻，原来如此，将来也如此。
没有任何人甘心让自己的努力白费，于是，就像大家预料的，辩护文章将会不断出现，帮助大家渡过信念危机。我承认，这一篇也是，为什么不呢？
首先，我还是要感谢Stroustrup，无论怎样，他的出发点符合大家的利益，不是吗？随着科技的高速发展，什么职业贬值最快，我想各位应该清楚吧。而且，更关键的是，恶梦还在后头，程序员将最终从万人之上的宝座上摔下来。虽然我这样说势必会激起众怒，但是大家别忘了，我也是你们的一员，难道我愿意？
至少现在我知道了，有人曾经试图挽救这个，我很感激，不论他的真正目的如何。
言归正传吧，让我们仔细看看对话。你会发现，很有道理，是的，他说的都是现在软件业的实情，都是问题所在。听起来非常悲观，甚至让你怀疑我写这篇文章的动机？如果真的达到了这种效果我就高兴了，因为我确实是想努力唤起大家的警惕。
Stroustrup承认了他创造C++的最初动机，“我想知道如果有一种特别复杂而且难以学会的语言，是否就没有人可以又把程序员们搞到市场的泥潭里去呢？”他没有说谎，这确实是一种比C要复杂得多的语言，太明显了，因为它至少兼容C。
那么，C++真正复杂和难以掌握的地方在哪儿呢？在于它的，依赖于运行时确定的，后台自动处理的东西太多了。因此，C++的语法就必须有太多的规则和约定，这大大增加了使用者的负担。然而最可怕的是，C++的语法并不是那么完备，有很多情况它无法明确地（起码是独断的）告诉你应该怎么处理。于是，我们需要“Thinking in C++”或者其他的什么，为它的一个具体的实现做出最终的仲裁，而C++规范本身则不负责任的把负担推给了别人。
让我们暂时轻松一下，看看其他的。我是说VB，你不得不承认它的重要意义，嗯，我想Copper一定在后面偷笑。它代表着，不管我们提出什么令人眼花缭乱的新技术，大家的目的都是一致的，就是提高程序开发的生产率。VB使得一个程序开发的周期大大的缩短了，很多C++的程序员一定不同意我的说法，他们认为VB甚至不是一个真正的程序开发语言。我不想讨论这个问题，你去问微软吧，或者看看最新的VB 7。如果你还是一个死硬派，那么，Java和C#（我真佩服微软的这一手）还有Delphi呢？
在这里，我们遇到了更多的暗箱处理，我们甚至不用管任何工作的细节。我们申请了内存不用释放，我们打开了文件不用关闭（虽然这都不一定是好习惯）。无论怎么说，我们从中受益很多。而且，非常幸运的是，它们工作的很好。我个人的观点是：今后的开发工具和开发方法将提供越来越多的自动处理能力，以使开发者能够集中注意力于真正的、与众不同的工作中，而不是陷入一些重复工作的泥沼。为了做到这一点，开发工具或者开发方法当然就需要一套复杂的规则，以实现这一点。
那么，同样的情况放到C++上，怎么就变了味呢？有人已经宣称对此事负责了：“虽然这个特性是为我的初衷而做的”。是的，C++是一个大杂烩，它什么都有。你要知道，这通常是不理智的，什么都想要通常的结局就是什么都得不到。
看看Stroustrup举的例子，typedef、多继承、还有模板。他说得对，不过我想，typedef恐怕还逊#define一筹。至于多继承与模板，我不想扯得太远，看看其他的参考了C++的语言是怎么取舍的就行了。我一直坚信，代码是写给人看的，而不是机器。
还有一个例子，是关于参数引用的，是的，一个星号可以提醒你它是如何工作的。我们人类是健忘的，正因为此我们可以不断的获得新的东西。看看C#中的ref和out修饰符，它提醒了大家我们的位置。以前我在设计软件时，也一直避免对受影响的变量用引用方式（也就是说还是借助传统指针），但是事实上它也不会构成很大威胁，因为我的文档中已经非常清楚地说明了参数将会被如何处理，我想这已经足够了。
也许我应该重申一下我的看法了，C++本身就是一个混乱的杂交品，没有经过认真的取舍。就像我们做软件一样，什么功能都往里面塞。看看你身边的那些巨型软件吧，你该知道怎么做了。
访谈中其他的部分就没有这么简单了，你知道我想说的是代码重用以及开发效率。因为你是对着那篇访谈来看这个的，至少我希望是。
先看前者，我想问一句，那是C++本身的问题吗？是的，用C++编写可重用代码是要难一些，因为你必须更加小心的定义对象的行为，在我刚开始使用MFC（我一直认为微软的这个工作做得并不好）时，我发现它并没有一个读入图像文件的方法，这可是个大问题，幸好我能够辗转的通过Windows API（这是标准的C函数）读入并且设法将其构成一个类。感谢微软，他们终于知道封装一个类需要特别考虑它的完备性了。
至于开发效率，这可是触到我的痛处了。我一直试图说服周围的同事们，注意文档的重要性；我也试图让公司能够认可更长的设计时间会减小开发的成本。但我没有成功。但是，你们认为这是一个开发语言的责任吗？
说到这里我又想起面向对象的问题，这个风靡了整个软件业的概念正在指导着软件开发方法的不断变革。我真的无法描述我对它的感激之情，它使得我们能够更为贴切的表达一个物体，并且能够将各种复杂的交互行为很自然的分离出来。我说的是，它具有那么强大的表达能力，它可以展现给我们一个丰富多彩的世界，而不是冷冰冰的数据结构与算法。
再回过头来看看C程序员们排斥C++的理由吧。效率低、编译之后的文件大？天哪，硬件方面有摩尔定理，我们还怕什么。相信我，绝大部分的程序不是为登月火箭服务的。
那么，还有什么呢，不处理错误？这确实是一个不好的习惯，按我的经验一个成熟的软件中至少将会有60%的代码负责错误的处理。这不是面向对象的错，但是也不是一点关系也没有，当大家享受着汉堡快餐的便利的时候，有时候确实忘了在自己做汉堡之前先把肉烤熟。
这里带来的一个普遍的问题，就是内存泄漏。是的，在C++中，对象的行为并不是编译时就能完全确定的。我们拿着一块内存措手无策：到底什么时候才能够把这个该死的东西丢掉？很有意思吧，C程序员们则必须亲自去做每件事，因为他没有一个可以依赖的自动机制。也许这种强迫性为避免了错误发生的概率，但是，一味重复的劳动你喜欢吗？它使你偏移了你的注意力，被各种繁琐的蔓藤缠绕着，而看不到外面的世界。
不论怎么说，Stroustrup确实做得非常好，掌握C++是如此的困难，以至于很多学校仍然拒绝教授C++。是的，使用C++需要有更高的有求，它要求设计者们必须有更好的结构分析与归纳的能力，这也是程序员演化的方向。
最后说一句，Stroustrup只是C++之父，并不是面向对象之父。
-------------------------------------------------------------------------
说实话，当我看到这篇文章时，我和其他所有C++程序员（虽然我大部分时间用的是VB）一样，感到震惊。难道大家这么多年的劳动成果只是一个玩笑？当我们一觉醒来，上帝对我们说，一切都是虚幻，原来如此，将来也如此。
没有任何人甘心让自己的努力白费，于是，就像大家预料的，辩护文章将会不断出现，帮助大家渡过信念危机。我承认，这一篇也是，为什么不呢？
首先，我还是要感谢Stroustrup，无论怎样，他的出发点符合大家的利益，不是吗？随着科技的高速发展，什么职业贬值最快，我想各位应该清楚吧。而且，更关键的是，恶梦还在后头，程序员将最终从万人之上的宝座上摔下来。虽然我这样说势必会激起众怒，但是大家别忘了，我也是你们的一员，难道我愿意？
至少现在我知道了，有人曾经试图挽救这个，我很感激，不论他的真正目的如何。
言归正传吧，让我们仔细看看对话。你会发现，很有道理，是的，他说的都是现在软件业的实情，都是问题所在。听起来非常悲观，甚至让你怀疑我写这篇文章的动机？如果真的达到了这种效果我就高兴了，因为我确实是想努力唤起大家的警惕。
Stroustrup承认了他创造C++的最初动机，“我想知道如果有一种特别复杂而且难以学会的语言，是否就没有人可以又把程序员们搞到市场的泥潭里去呢？”他没有说谎，这确实是一种比C要复杂得多的语言，太明显了，因为它至少兼容C。
那么，C++真正复杂和难以掌握的地方在哪儿呢？在于它的，依赖于运行时确定的，后台自动处理的东西太多了。因此，C++的语法就必须有太多的规则和约定，这大大增加了使用者的负担。然而最可怕的是，C++的语法并不是那么完备，有很多情况它无法明确地（起码是独断的）告诉你应该怎么处理。于是，我们需要“Thinking in C++”或者其他的什么，为它的一个具体的实现做出最终的仲裁，而C++规范本身则不负责任的把负担推给了别人。
让我们暂时轻松一下，看看其他的。我是说VB，你不得不承认它的重要意义，嗯，我想Copper一定在后面偷笑。它代表着，不管我们提出什么令人眼花缭乱的新技术，大家的目的都是一致的，就是提高程序开发的生产率。VB使得一个程序开发的周期大大的缩短了，很多C++的程序员一定不同意我的说法，他们认为VB甚至不是一个真正的程序开发语言。我不想讨论这个问题，你去问微软吧，或者看看最新的VB 7。如果你还是一个死硬派，那么，Java和C#（我真佩服微软的这一手）还有Delphi呢？
在这里，我们遇到了更多的暗箱处理，我们甚至不用管任何工作的细节。我们申请了内存不用释放，我们打开了文件不用关闭（虽然这都不一定是好习惯）。无论怎么说，我们从中受益很多。而且，非常幸运的是，它们工作的很好。我个人的观点是：今后的开发工具和开发方法将提供越来越多的自动处理能力，以使开发者能够集中注意力于真正的、与众不同的工作中，而不是陷入一些重复工作的泥沼。为了做到这一点，开发工具或者开发方法当然就需要一套复杂的规则，以实现这一点。
那么，同样的情况放到C++上，怎么就变了味呢？有人已经宣称对此事负责了：“虽然这个特性是为我的初衷而做的”。是的，C++是一个大杂烩，它什么都有。你要知道，这通常是不理智的，什么都想要通常的结局就是什么都得不到。
看看Stroustrup举的例子，typedef、多继承、还有模板。他说得对，不过我想，typedef恐怕还逊#define一筹。至于多继承与模板，我不想扯得太远，看看其他的参考了C++的语言是怎么取舍的就行了。我一直坚信，代码是写给人看的，而不是机器。
还有一个例子，是关于参数引用的，是的，一个星号可以提醒你它是如何工作的。我们人类是健忘的，正因为此我们可以不断的获得新的东西。看看C#中的ref和out修饰符，它提醒了大家我们的位置。以前我在设计软件时，也一直避免对受影响的变量用引用方式（也就是说还是借助传统指针），但是事实上它也不会构成很大威胁，因为我的文档中已经非常清楚地说明了参数将会被如何处理，我想这已经足够了。
也许我应该重申一下我的看法了，C++本身就是一个混乱的杂交品，没有经过认真的取舍。就像我们做软件一样，什么功能都往里面塞。看看你身边的那些巨型软件吧，你该知道怎么做了。
访谈中其他的部分就没有这么简单了，你知道我想说的是代码重用以及开发效率。因为你是对着那篇访谈来看这个的，至少我希望是。
先看前者，我想问一句，那是C++本身的问题吗？是的，用C++编写可重用代码是要难一些，因为你必须更加小心的定义对象的行为，在我刚开始使用MFC（我一直认为微软的这个工作做得并不好）时，我发现它并没有一个读入图像文件的方法，这可是个大问题，幸好我能够辗转的通过Windows API（这是标准的C函数）读入并且设法将其构成一个类。感谢微软，他们终于知道封装一个类需要特别考虑它的完备性了。
至于开发效率，这可是触到我的痛处了。我一直试图说服周围的同事们，注意文档的重要性；我也试图让公司能够认可更长的设计时间会减小开发的成本。但我没有成功。但是，你们认为这是一个开发语言的责任吗？
说到这里我又想起面向对象的问题，这个风靡了整个软件业的概念正在指导着软件开发方法的不断变革。我真的无法描述我对它的感激之情，它使得我们能够更为贴切的表达一个物体，并且能够将各种复杂的交互行为很自然的分离出来。我说的是，它具有那么强大的表达能力，它可以展现给我们一个丰富多彩的世界，而不是冷冰冰的数据结构与算法。
再回过头来看看C程序员们排斥C++的理由吧。效率低、编译之后的文件大？天哪，硬件方面有摩尔定理，我们还怕什么。相信我，绝大部分的程序不是为登月火箭服务的。
那么，还有什么呢，不处理错误？这确实是一个不好的习惯，按我的经验一个成熟的软件中至少将会有60%的代码负责错误的处理。这不是面向对象的错，但是也不是一点关系也没有，当大家享受着汉堡快餐的便利的时候，有时候确实忘了在自己做汉堡之前先把肉烤熟。
这里带来的一个普遍的问题，就是内存泄漏。是的，在C++中，对象的行为并不是编译时就能完全确定的。我们拿着一块内存措手无策：到底什么时候才能够把这个该死的东西丢掉？很有意思吧，C程序员们则必须亲自去做每件事，因为他没有一个可以依赖的自动机制。也许这种强迫性为避免了错误发生的概率，但是，一味重复的劳动你喜欢吗？它使你偏移了你的注意力，被各种繁琐的蔓藤缠绕着，而看不到外面的世界。
不论怎么说，Stroustrup确实做得非常好，掌握C++是如此的困难，以至于很多学校仍然拒绝教授C++。是的，使用C++需要有更高的有求，它要求设计者们必须有更好的结构分析与归纳的能力，这也是程序员演化的方向。
最后说一句，Stroustrup只是C++之父，并不是面向对象之父。
...全文
请发表友善的回复…
发表回复
gigix 2001-12-04
- 打赏
- 举报
你同样可以分配内存不管回收，用智能指针就可以。当你把C++和JAVA做比较的时候，首先必须弄清楚：哪些东西是JAVA本身提供的，哪些东西是JAVA的库提供的。C++也有很多很多的库，垃圾回收、多线程、网络……C++都有很方便的库，只不过没有SUN这样的公司大做宣传而已。
另外，打开文件不管关闭、分配内存不管回收、使用资源不管归还……这恐怕不是什么值得提倡的做法吧？
另外，打开文件不管关闭、分配内存不管回收、使用资源不管归还……这恐怕不是什么值得提倡的做法吧？
xiaoduan 2001-12-04
- 打赏
- 举报
傻B,浅薄
基础不牢还唧唧歪歪
基础不牢还唧唧歪歪
gxc_csdn 2001-12-04
- 打赏
- 举报
说白了都是只是编程的，不管是编码工也好还是系统分析员也好，都是跟着别人的屁股后面跑，没一点创造性。学点哲学吧，说不定有一天你也能看透事物的本质，弄个OOX。
dynamic_cast 2001-12-04
- 打赏
- 举报
按照弗洛伊德的精神分析学的观点来看：
是有人连OOP都不懂，然后自我安慰：我懂OOD，OOA。
如果各位有时间的话，多看看别的书也好，免得被这些东西弄得头昏眼花。
是有人连OOP都不懂，然后自我安慰：我懂OOD，OOA。
如果各位有时间的话，多看看别的书也好，免得被这些东西弄得头昏眼花。
stavl 2001-12-04
- 打赏
- 举报
To azs：你说得非常对，但我只是就事论事，所以没有涉及那么多。:-)
azs 2001-12-04
- 打赏
- 举报
只能说明一个问题，你还只是个编码工
别以为学了oop就是全部
ooa,ood不懂就不知道面向对象方法的本意
别以为学了oop就是全部
ooa,ood不懂就不知道面向对象方法的本意
halfdream 2001-12-03
- 打赏
- 举报
写得挺不错的
coolbee1121 2001-12-03
- 打赏
- 举报
啊?!
倒~gzgz~
倒~gzgz~
