给 C++ fans 泼一点冷水
(remark: 本文并不适合初学者. 并且本文草就，可能有错漏，大家原谅)
前些天不小心在一个网站上看到了恶魔和梦魇关于 C++ 的务虚主义的对话,
嗯,很有意思，也学习到不少东西。
梦魇的一些话却不同意
--- CUT BEGIN ---
脑子里整天盘旋的，还是指针、动态内存这些低级的东西。试问Python程序员什么时候需要考虑内存释放问题？一个整天考虑这里内存
会不会丢失的程序员，他的效率怎么可能赶得上Java/VB/Python？说道这里，你可能会反驳：“但是C++本身确实需要考虑内存回收问
题啊！”。事实上，NO！使用STL和Boost库，我真的可以一个delete都不用，一个字节都不泄漏。而且写出来得代码很清晰。遗憾的是
，整个C++教育界都认为这是高级C++技巧，从来没有人一开始就告诉初学者“你可以这么做”。包括我在内，很多C++使用者整天殚精
竭虑地在想：“这个函数应该返回一个字符串地拷贝呢，还是传回一个引用更快？”更有甚者，C++程序员中一些学院派整天还在争吵s
hared_ptr多占用的那几个时钟周期！老天，都什么时候了？！ 那个功夫，Java程序员又完成一个项目了！
--- CUT BEGIN ---
附带说明一下，防止资源泄漏的技术不需要付出很高的学习代价，轻易可以学会。
你只要记住在想使用指针的时候，把
TSometype* p(new TSometype());
改写成
shared_ptr p(new TSometype());
--- CUT END ---
有了 STL, boost, C++ programmer 的生活就简单了吗 ?
呵呵，未必。
C++ 用来解决简单问题，未必是最称心的工具，我们来看看复杂一点的问题，C++ 好不好解决.
--- 问题
STL, boost 确实可以保证不会忘记析构对象。
但是，当 STL, boost 认为必须析构对象的时候，是否能够安全的析构呢 ?
具体一点, 当 smart ptr 发现已经没有指针使用一个对象了，此时析构这个对象是否是安全的呢 ？
当然，此时释放对象，你定义的的各种指针，确实不会变成悬空的了，但是，还有，this 指针呢 ?
为什么要考虑 this 指针 ？
举例: 在一个复杂的应用中，如果一个 ui event, 调用了某个object的成员函数，该函数判断当前状态后，调用了object 的 owner
的某个函数，好了，owner 经过判断，认为刚才的 object 已经没有用处了，会做下面动作之一
1. (传统C++) 显式析构
2. (新方法) 将指向这个 object 的smart_ptr 指向 另外一个object, 同时
通知合作模块，对象的变化；如果此时引起所有的 smart_ptr 都切换到新的 object, 老的 object 将被析构。
好了，这样就存在一个危险点，call stack 回到老 object 的成员函数的时候， 如果它还想继续访问自己的成员变量/调用虚函数，
OK, 错误了。
--- 你可能会说
1. 我的程序不会有这种情况。
OK, 你的程序没有这个复杂性，你幸运。但是当今用C++, 多半是用来解决复杂问题的，简单的问题，可能 VB/Delphi 就可以搞定了
。
我在什么时候碰到这个问题？例如，当年我写一个可以按照 per connectin 自动配置各层网络层 (是否加入 SSL, 是否支持自动断线
重联等等)的 OO stack 的时候，就碰到这个问题。
现在我用 Delphi 写程序，对于 RAD 的 UI Event 割断 use case 联系不满， 决定将程序的结构从 UI Event driven 改成 use
case driven 的时候，同样碰到这个问题: form 告诉 use case manage code，OK button已经按下了，use case manager 判断，呵，
这个 form 没有用了, close it; connect to a new modal object and switch to a new form, 呵呵，同样的问题。(虽然是
Delphi, 换成 C++, C++ builder 是一样的).
2. ok, 我写的成员函数，每次调用到可能导致析构自己函数之后，不再访问自己的数据成员，不再调用别的成员函数。
哈, 不错，很安全了。
但是，每次需要写代码的时候，都要牢记这点，首先，很累；第二，有些时候，恐怕没有这么乐观；第三，对维护人员的要求，也太
高了吧 ?
3. 我从程序设计的角度来避免这个问题
en, 我相信高手是有办法，但是，这会导致你的设计对 applation domain 的 concept 不够匹配，导入了语言而至的 computing 成
分；而且，这会增加类体系的复杂性。
我用 C有13年了，C++也有9年了，设计复杂程序也有好些个了，我不认为这个方案很好。
4. wait, 我还有一个好办法, 析构了之后访问数据成员，无非就是 access violation，这个好办，我将 Windows SEH (Structure
exception handler) remap 成 C++ exception, 非法访问之后，抛出一个异常，object 已经析构了，后续对它的访问，本来就没有太
多用处
en, 这个方案好像对程序改动小一些；很多时候应该也可以工作(除非对象访问完自己后，又想将一个什么通知送给另外一个对象，呵
呵，这就不行了).
问题在于, unix 的signal 不能这样做, singal 处理函数必须快速返回，不能让你throw.
5. ok, 我做一个析构管理器，延迟析构
嗯，有这个干劲，不错。问题:
1. 似乎不太容易做
2. C++ 老问题，新来的程序员又要学习一个 library, 而且必须记住，什么时候
必须要用它。
6. 请高手指点 ......
我也希望有好的方案，因为我自己喜欢 C++, 能力够强，不会限制我的系统设计。
这个问题，对于 Java 来说，是 piece of cake 了。我对 Java 语言机制熟悉有限，不过 Java 要是不能处理这个问题就是笑话了。
Java 本来对对象有引用计数或者类似机制，只要进入成员函数，使用 this, 就增加计数，退出就减去，OK。即使数据结构里面的指针
已经全部没有指向 object，但是也要等到最后一个成员函数退出，计数才复零，垃圾清理才被允许。
现在C++ 的领地已经被侵占不少，大家普遍认为，复杂的东西，还是要用 C++ 才好，结果我却发现，复杂的东西，C++ 继续把复杂性
double 了一下。从我自己的能力和经历来看，一个复杂的程序，对象的析构还是其中最难的一环。不是怕泄漏资源，而是是否能够析
构，在一些有可能交叉递归，甚至多线程同时进入某个对象的成员函数，而调用可能都是会交叉递归的时候，真是很难处理。
对于 C++, 我的看法，C++ 设计的时候，天生就没有想到要减轻 designer & programmer 的负担，他是设计给不怕困难的高手用的，
没有什么限制，C++ 没有偷偷摸摸地做什么，但是也没有提供多少帮助。
国内计算机业产值最大的，还是行业软件，同时也经常不够时间慢慢打磨一个设计和实现，这种情况下，还是 Java & C# 容易一些，
这就是我给大家 C++ fans 泼的冷水了。
我自己呢? 开始用 delphi 了，无法，team 容易组建。STL 很好，数据结构不要操心了，GP 很好，增加设计时候的武器，但是，如
果team里面只有 我光杆司令一个，有什么用 ?
BTW: 如果我下次仍然要实现一个auto reconfig 的 高效stack, 我到要好好想想，是不是该用 结构化设计 + C 来做主框架了。
问题点数：100、回复次数：84Top
1 楼babysloth（小懒虫虫）回复于 2002-04-13 19:39:27 得分 0
呵呵，能不能把话说清楚一些，看了半天还是没看懂：（
C++可以自选垃圾收集器，如果您实在不会用C++管理内存的话，就去装一个。
您的例子极不清晰。如果想下这样的结论，您是否应该扪心自问：我会用std::auto_ptr吗？我会用boost里的五个smart pointer吗？我了解RAII吗？如果都是肯定的回答，那么恭喜您，您的结论还有可能不失偏颇。Top
2 楼mjm_d（菠萝蜜多）回复于 2002-04-13 20:22:53 得分 0
我想一个一味追求简单的而汇编一窍不通的程序员都是垃圾Top
3 楼runrunrun（农妇、山泉、有点田）回复于 2002-04-13 20:28:49 得分 0
不知道有几个大型软件是用 Java/VB/Python 做的Top
4 楼hucong（stupid urchin）回复于 2002-04-13 20:48:18 得分 0
知其然,要知其所以然,我可不想变成"技术"白痴,别人让你干什么就干什么.!!软件开发不仅仅是生存的一项技能,更是一门艺术!!Top
5 楼claydog（土狗）回复于 2002-04-13 20:58:59 得分 10
//！ 我越来越同意一个观点：
“从来没有哪一种语言能包揽所有的领域中的所有工作，现实世界是用多种语言配合使用的,C++也只不过是那么多语言中其中的一种而已，而其他任何语言也是同样如此。”
//！ 以下为个人观点，不正确之处望指正：
我想在很大程度上C++的优势是在于对整个硬件系统的透明把握和高效访问及其控制，对于所要解决的问题系统在细节上方方面面都能够顾及到的能力。但是一个复杂项目是对开发工具及其开发人员综合素质的考验。所以一个复杂的项目的开发前期都要对所能够使用的开发工具和开发人员做一个综合性的论证。
/*！
正如fastest286 (fastest286)所说：“STL 很好，数据结构不要操心了，GP 很好，增加设计时候的武器，但是，如果team里面只有 我光杆司令一个，有什么用 ? ”
在招新人的做项目的时候也常常听到有人说：C++太不好用了，什么结构都要自己去构造，太容易出错了，实现一个链表常常搞混。
*/
C++创始人有一句话的大意是：目前没有那种语言能在通用性、效率和精致三方面的统一上可与C++相题并论。（可能引用的有点出入）
对于复杂的系统设计，一些难题要么开发工具自己能够较为方便的解决，要么就是留给开发人员去使用一些灵活、精致的设计去解决。C++的特点在于其基础类型（或者说语言的核心部分）较为精简，而把大量的自由（说的稍微不好听一些是一些比较难的创造性工作）留给了库或开发者本身。
并且C++有一个特点：同样的一个实现可以有不同的路径。C++创始人在《The Design and Evolution of C++》中说：人们的思维的方式是如此的丰富多彩，企图推行一种单一理念总是弊多于利。这样，C++被有意设计成能够支持各种各样的风格，而不是强调“一条真理之路”。而且C++还要考虑到与C语言的兼容性，所以在这一点上的确较为为难。
但是常常就是因为这个特点使得众多C++的初学者常常迷茫于这一庞大的密林之中。C++用的久才有深刻体会。
常听人说：发现做一个设计的时候使用Java比使用C++快，我相信这个说法。Java把许多平台特性去掉了（虽然它本身就是一个平台），并且是一个纯的面向对象语言，在做OOD的时候不象使用C++那样会被C++其他的特性所迷惑。我相信一个大师在做设计可以不受这些语言特性的迷惑，但是毕竟大多数人不是大师，他们都选择能够迅速反应他们设计的工具。
在我内心深处对C++有着狂热的爱好，但是相信自己不会做一样工具的卫道士，也希望有更强大的工具出现。非常感谢fastest286 (fastest286)的“冷水”，让我们在学习C++的同时又能够不被它永远沉迷。
非常希望那些C++的老手和从事多年项目开发工程师能够多发表自己的看法。
Top
6 楼fastest286（fastest286）回复于 2002-04-13 22:27:55 得分 0
我泼这个冷水的目的, 在于
1. 部分人学习 C++ 只是因为这是最强大的语言, 能够学习好表明了自己
有实力.
2. 从myan的文章中，我觉得他(可能还有一些其它的 C++ 高手) 认为,
C++ 的重大缺点在于, 目前的C++ 教育跟不上形势, 大家没有学好
C++ 的使用，觉得很难。如果教育跟上了, C++ 标准库逐步齐全(相对)
以后, 还是不难的。
我想表明, 对于 (2) 来说 C++ 还是难的。难在: 简单的问题大家不用
C++, 复杂的问题呢，即使使用现代的C++，很多方面的使用，仍然比
Java/C# 难，这在中国最普遍的行业软件开发中是很吃亏的。
国内还有哪些行业用 C++ 多? 以前电信方面的软件很多用 C 写(不是++),
但是现在除了硬件接口的还是用C, 管理部分的用Java 的很多了. 银行的软件
也是这样。用友他们也在尝试 Java, C#.
金山开发 WPS, C++应该是比较理想的，但是，国内开发这种通用软件毕竟
难走。游戏开发要用 C++, 但是国内的游戏开发团队有几个挣到可观的钱了?
这样，对于 (1) 来说, 要更好好地思考. C++ 是不易学，不易精的语言，
而且在国内实际应用不算广泛，如果当作兴趣爱好自无不可，如果从职场考虑，
就要好好衡量了。包括新的程序员，以及有希望带队的经验程序员。
我去年就曾经决策失误了。某一个项目，回过头了，真的不应该用 C++开发，
更加不应该用 Visual C++开发，即使是最后要追求精品，也是应该先用delphi
之类打开局面之后有需要再来决定有没有必要为了轻薄短小换开发工具。如果
左轻侯看到这个贴子，那么，呵呵好玩了，其实当初你去广州，我们两人和你
聊C++的时候，其实我们当初应该转向的了。
由于上面我的贴子，确实是随手为之，所以我的思想可能没有表达清楚。
-----------------------
to claydog(土狗):
我从兴趣爱好的角度，还是喜欢 C++ 的，毕竟C++做了很多其他语言没有做
的努力，给我程序员最大的可能性。
但是，从工程，从公司，主要是从目前国内现状来看，不能沉迷于 C++。作
为C++高手，也要小心。
> C++创始人有一句话的大意是：目前没有那种语言能在通用性、效率和精致
> 三方面的统一上可与C++相题并论。
我承认。想我现在用 delphi, 通用性，效率先不说了。光是Delphi本身的语言
就让我讨厌。集合的定义用小括号，使用的时候用中括号；数组的常量初始化，
结构的常量初始化，中间的分隔符都不一致；else 前面的语句不要分号等等，
什么垃圾吗，连语法的一致性都没有。不是 "最小惊讶原则", 而是 "每每出乎
意料原则".
但是，目前国内软件，有多少是需要很讲究通用性和效率的？呵呵，我看过
杭州某个著名国外上市电信企业写的sms代码，那个糟糕哦；后来果然听说，
sun作smsc都撑不了多少 sms packet/second, 但是，别人先有了系统，而且
依靠企业，能够卖出去。
我年轻的时候不是这样想的，大概现在已经开始不年轻了，觉得还是生存
和发展重要，至于语言的选择，还是以尽量能够为自己，为公司创造最大价值
为准。
> 常听人说：发现做一个设计的时候使用Java比使用C++快，我相信这个说法。
> Java把许多平台特性去掉了（虽然它本身就是一个平台），并且是一个纯的
> 面向对象语言，在做OOD的时候不象使用C++那样会被C++其他的特性所迷惑。
> 我相信一个大师在做设计可以不受这些语言特性的迷惑，但是毕竟大多数人
> 不是大师，他们都选择能够迅速反应他们设计的工具。
不必是大师，只要是不盲目追求 "语法技术"的 C++高手，应该都不会被很多
东西迷惑。
一个重要的问题在于框架型的库，最能够减轻开发的工作量，框架都给你了，
不是最大的design pattern 吗？
而 standard C++ 是不准备在这个方面发展的，加上，由于C++ 没有标准的
serialize/persistant 机制，rtti 机制不够强，内存管理机制很多时候不够
用，使得很多大型 C++ 库都自己实现一套, 这样一来，两套库的 class之间
想相互用可就不那么容易了。
其他的，同一个framework 下面, 新合作的designer好配合；和new programmer
交流也容易之类的就不说了。
-----------------------
to hucong(stupid urchin):
> 知其然,要知其所以然,我可不想变成"技术"白痴,别人让你干什么就干什么.!!
> 软件开发不仅仅是生存的一项技能,更是一门艺术!!
如果艺术当作爱好是没有问题的，如果用来谋生，须知很多艺术家是饿死的。
我也很想中国多一些能够让人自由发挥一点的研究所啊，可惜没有。
-----------------------
to mjm_d(菠萝蜜多):
> 我想一个一味追求简单的而汇编一窍不通的程序员都是垃圾
还好，这个评论下，我还不是很垃圾，我从 APPLE II 的 call -151, machine
code 开始，学了好几种汇编。还写过 小型 CPU 内部的 micro code.
除非你想做hack/crack/加密/杀病毒, 或者优化3d引擎，否则，除了深入调试程
序之外，这些汇编知识真的没有什么用，屠龙之计。
菠萝蜜多 大概还是一个年轻的技术追求者。呵呵，作技术追求没问题，关键是
处理好爱好和职业生涯的关系。
-----------------------
to babysloth(小懒虫虫):
写得不好，请原谅，但是您可能还没有能够看懂我的文章。
我说的问题，是 C++ 垃圾收集机制改变不了的，除非 C++编译器可以让人自定义
成员函数入口和出口代码。
您问我的问题，很好，相信您也懂了。好了，那么给几个实用的题目给您思考一下，
应该对您有用(如果您和我一样，自己想出来再上网查看，应该有长进)
1. C++ 里面的 RTTI 不够强，要自己实现一个类似 RPC 一样的远程私有调用低层的
话, 可以怎样用 C++ 的特性来减轻 对许多函数 参数打包、解包 的工作 ?
呵呵，这是实际工作中有用的东西。网络通信，以及 cross thread defferd
procedure call 了， 都是用得上的(这下几乎可以扔掉 win32 DPC/APC 了)。
曾经看到一个手下，写了上千行打包，解包的代码，都不肯去想想办法，于是努力
想了半天，给了一个方法，几百行，无论是普通函数，成员函数，都可以打包了。过
了两个月, CUJ 等出了差不多的方法，您可以去那里找答案。
2. 要对 一个 thread 做一个 gracefully deffered terminate，C++哪个特性可以有
帮助 ?
如果没有记错的话，qt win32 实现中的方案和我的差不多，你可以去那里找答案。
呵呵，这些都不是考平台或者库的，考怎么用好 C++ 的。
-----------------------
-----------------------
很久没有写过什么贴子了，今天怎么心血来潮，写了一大堆，呵呵。byebye.
Top
7 楼fastest286（fastest286）回复于 2002-04-13 22:45:17 得分 0
BTW:
再说一点不是泼冷水的话吧。
如果要学好C++, 而不只是学某个framework 下面什么工作怎么做,
去 cuj, ddj, 之类的是正途，不是codeguru.Top
8 楼freezingfire（让美梦来得更猛烈些吧）回复于 2002-04-13 22:45:52 得分 10
贴主，你在那里工作？我去投奔你^_^
我非常同意你的观点，C++太难了，我不是资深程序员，2年半c++，半年java，现在又回头做C++4个月，坦白的说，当我从C++转到Java时，一旦适应之后，觉得Java真是容易多了，易学易用，特别从设计的角度。本来现在转回C++后还没觉得什么，一看你的文章才确实发现现在考虑的问题是用Java设计时候的几倍。的确有太多的时间是花在了考虑C++底层的实现问题上。另外我感触最深的就是C++标准化太差，很多东西没有统一的解决方案，的确是一个大的运行库一套自己的东西，每次去找用什么东西来实现某个功能，是我最头疼的问题，因为答案往往有好几个，可能自己有自己的特色，自己有自己的使用范围，让人没法选择。
虽然大型软件还是C++的天下，但是我觉得对于目前中国的普通商用软件公司来说，C++的确不是好的选择。Top
9 楼duqiang2050（杜杜）回复于 2002-04-13 22:52:24 得分 0
freedom or deathTop
10 楼babysloth（小懒虫虫）回复于 2002-04-13 23:09:01 得分 0
看来我真是没看大懂，不好意思。
C++设计的目的是通用语言，在某些特定场合的确比不上C#/Java方便，这是不争的事实。
C++ RTTI不够强的问题，也是C++下一版标准要解决的重要问题之一。
至于thread，boost库里的thread已经可以解决相当的问题，相信会逐步完善的。Top
11 楼banalman（IT解放者）回复于 2002-04-13 23:10:30 得分 0
语言的发展永无止境，我们都应努力掌握Top
12 楼yanqlv（maomao）回复于 2002-04-13 23:39:27 得分 0
给我的感觉是现在一些新的概念,实现更多的出现在JAVA上,而不是
C/C++上,不过两者都学,是能够通过对比看出一些发展的趋势,掌握一些设计思想的.毕竟JAVA的一些思想是从C++里学的,知其然,要知其所以然,才理解的更深刻,哈,不过让我自己选,我还是选JAVA开发.Top
13 楼godemon_lord（荡漾茶烟）回复于 2002-04-13 23:52:26 得分 0
啊，看不懂、看不懂、看不懂啊……
看来自己水平太低了，没办法，今后再向你讨教：）Top
14 楼nicholas_87（nicholas）回复于 2002-04-14 16:45:52 得分 0
关注！！！Top
15 楼maobin_y（ymb）回复于 2002-04-14 17:04:48 得分 0
我无话可说，这不仅仅是技术的问题，还涉及到国际的问题，如果每个人都向美国的学生一样可以自由地阅读c++大师的论著，同时有必要时直接去找C++工作组的成员专家探个明白，可能结果会不一样哦！看看我们的C++教材，就知道为什么我们的C++高手那么少了。真正语言高手不是语言高手，而是数学与哲学方面的高手，同时还是硬件方面的专家，语言对他来说只是一种解决工具而已，最重要的是当他觉得不好用时，就自己写一个来代替它。Top
16 楼hucong（stupid urchin）回复于 2002-04-14 18:09:39 得分 10
语言本身不代表什么,学会了是不难,学精通就难了,不仅仅是靠着语言教材就能精通的,需要从各个不断补充,一些基本的计算机软硬件的知识不可能不学吧.语言拿来干什么??是解决问题.问题都解决了,写得再好得代码,再优美得代码也不是白搭,可维护性,那也不知一天两天得事情,国内起步晚,很多项目本身得需求分析,设计这一关就没过好,还能期望写出多好得代码来??维护就更别提了,我们现在的项目是比较大,花了一年的时间了,可惜最核心的代码(20%),还是一改再改,这样能行？?项目负责人也知道不行,那为什么还要修改,需求分析没做好,许多功能点多余,还有许多功能点缺乏,一些开发人员中途走掉,又为了赶进度,结果哪有时间区主义代码的质量,代码的效率,代码的优美?能按时完成项目,就算万事大吉了,这不是个人的问题,只是普遍的问题,没有合格的项目合格负责人,没有coder高手(我们这个项目的coder,一般都是刚毕业一年到两年的,公司为什么聘请更好的人员??怕花钱那!!)
c++固然不适合开发应用程序,但系统程序能少得了它??个人得能力有限,但团队里得每个人都象你这样热衷于写出高质量得代码,我想做出优秀的软件应该不会太难吧.库只是再适当的适当时候用,自己写一个也可以三,我们不能没有库就不能生存三.比如我们现在用的通信库,就是自己封装的udp,通信成功率就相当高(虽然unix下有T/TCP协议,面向连接的协议,开销只和UDP差不多,为什么我们不采用??因为只有unix系统(不是全部)才支持,而我们是基于unix和nt两个平台的,当然都要兼顾,所以只好自己开发这个库),这个你会用什么来开发??c吗??(和c++有什么区别??)
一个语言有其适应范围,有其设计的出发点,以及有其面向的具体用户,彼此到底谁更容易开发,没有个说法,哪个更适合你哪个就最好!!为什么不这样认为呢??????Top
17 楼hucong（stupid urchin）回复于 2002-04-14 18:14:41 得分 0
项目的失败,怎么怪开发工具呢??什么项目采用什么开发工具,不是随便乱来的,否则吃亏的是自己.你总不会写个数据库引擎,你去用vb吧???你也不会为了做一个商业网站去用c去写cgi吧?Top
18 楼ziqiriying（紫气日盈）回复于 2002-04-14 18:28:12 得分 0
胡扯！
C++ 全世界几百万人用！
Top
19 楼ilovec39（ilovec39）回复于 2002-04-14 18:46:41 得分 0
聪明的程序员用JAVA,真正的程序员用C++Top
20 楼redoctober（redoctober）回复于 2002-04-14 18:46:45 得分 0
用我的C++，让别人说去吧！！！！！！！！！！！Top
21 楼maoxianwang（傻蛋）回复于 2002-04-14 18:53:39 得分 0
你们的专家分长的好快呀
小懒虫虫等人！！
Top
22 楼youyouaq（阿叁）回复于 2002-04-14 21:14:46 得分 0
万分感谢！请高手们继续，让俺这菜菜菜鸟接着聆听教诲。Top
23 楼mis98ZB（Effective Typer）回复于 2002-04-15 15:30:02 得分 0
学习、理解。Top
24 楼duanfeng（段玉）回复于 2002-04-15 15:42:40 得分 0
我的看法,用C++练功最佳Top
25 楼gigix（透明）回复于 2002-04-15 15:43:26 得分 0
不知道有多少人听了李维先生的讲座录音？babysloth听了没？
当我们把C++和JAVA放在一起比较优劣的时候，这本身就意味着它们处于同一水平线上，互有高下——你还看到有人把JAVA和汇编放在一起比较的吗？呵呵，少数几个SB除外。至于C++和JAVA，它们本来就难分高下，不然这种讨论早就结束了。
两种本来就难分高下的语言，谁能用得好，谁就强。李维先生说得好，语言只是低层次的，软件设计的思想最重要。没有思想，只有学习一种一种又一种的新语言，疲于奔命；有了思想，才能驾驭这些工具，为我所用。
所以，学东西的时候，多动动脑子；讨论问题的时候，多动动脑子。别老是执迷于一种两种语言——说到底，JAVA和C++有多少不同？我不觉得。Top
26 楼cwanter（亚玛逊河上的渔夫）回复于 2002-04-15 15:51:47 得分 0
语言不重要，关键是算法。Top
27 楼duanfeng（段玉）回复于 2002-04-15 16:01:53 得分 0
都重要Top
28 楼neptunez（）回复于 2002-04-15 16:37:45 得分 10
呵呵，花了我半个小时时间把以上贴字读完了。俺没什么经验，也实在不能像楼主那样旁征博引。说实话，俺现在对c++ RTTI机制如何不好也没有深刻的体验。
以上相当同志好像误会了楼主的意图，请注意主题：泼冷水。并不是就是要贬低c++。只不过是要对某些认为c++无所不能，学了c++就有了饭碗的同志泼冷水罢了。楼主也没有要比较什么语言。
不知大家读过谁偷了我的奶酪这本书，即使你是c++高手也不能固步自封，抱着c++不放手。
对我自己而言，无论以后用什么开发，c++是我的第一个oo语言，也永远是我的最爱。永远支持关心c++的发展！Top
29 楼caocao82（cxxboy）回复于 2002-04-15 16:48:42 得分 0
看看而已Top
30 楼roger_k（大兔子）回复于 2002-04-15 17:54:30 得分 0
gzTop
31 楼nebula（南湖畔的深蓝）回复于 2002-04-16 10:51:08 得分 0
怎么老是有这种无聊的问题和无聊的争辩
幼稚加弱智Top
32 楼igand（~~~~~~~~~~）回复于 2002-04-16 10:54:49 得分 0
oTop
33 楼dev_uoboy（【世界】）回复于 2002-04-16 11:14:43 得分 0
同意nebula(南湖畔的深蓝)，争这中问题的真的很无聊Top
34 楼Linux2001（闭关开发中）回复于 2002-04-16 11:27:00 得分 0
如果哪一天Windows,Linux,Unix用VB,Java,Python来写了，那么C/C++的确是到他退休的时候了，可是现在的这些优秀操作系统是否使用VB,Java,Python来写的呢，不是，所以C/C++仍然应该存在下去Top
35 楼ptofga（pt）回复于 2002-04-16 12:32:38 得分 0
看得我都在云里雾里似的。
俺是一个菜鸟，
现在c++还值不值得在研究下去？
麻烦高手们诊断诊段Top
36 楼bluesun（）回复于 2002-04-16 13:14:56 得分 0
其实用什么语言并不重要，关键是有这个语言的人，哪个语言好还是差不应是我们主要关心的问题。Top
37 楼fastest286（fastest286）回复于 2002-04-16 23:25:59 得分 0
to neptunez:
RTTI 不够强的一个后果:
想写一个通用的persistant 机制, 或者想自动一点地完成 OO -> rdbms
map, 或者想写一个简单的类似 RMI 调用的机制, 没有办法利用 reflection
机制自动化地做一些事情，必须自己写所有的 package/unpackeg 工作，很麻烦。Java 的 rmi 为什么就不需要你自己将 object 打包，解包呢 ?
---
你对我意思理解是正确的。我是在和一个朋友聊天后有所感触写了这个
贴子，但是可能写得不好，大家没有理解我的意思。
当时我的感触:
在国内，追求技术，学校、研究所不是好地方，多数公司也不是好地方;
我们还是要解决了吃饭问题，业余再来爱好技术更稳妥。
为什么针对 C++ fans 呢 ? 对于 C++ 的追求者来说，很多人是追求技
术完美不怕困难的，但是这个方向走得太理想化了，很有可能和目前的现
实不好结合。
---
to others:
当然 C++ 可以完成任何工作, 不用别人的库也可以。但是，花的时间
长了就要命了。
BTW: MS biztalk server(MS server 里面很重要的一个东西), 这样一个
东西，不算普通应用软件了吧 ? 我记得 60% 还是 70% 用 VB 写, 10% 以上
是 HTML, C++ 只有 10% 左右。
全部用 C++ 性能更加好，但是，时间和成本呢 ?
国内的公司也会这样考虑的。
OK, 该说的说完了，这个贴子我不回复了，想和我讨论可以给我发条子。
Top
38 楼wolfliu（）回复于 2002-04-17 04:36:48 得分 0
我去年来到美国，圣诞节期间去加州转转，
从那里了解的情况是，C++还是使用最多的语言
而去年美国公司大裁员，首当其冲的就是Java程序员
大多数要求效率的软件是不会用Java开发的，而Java的
低效率(当然是运行)是人所共知的。
Java确实很风光了一阵子，可是现在风光不在了。
虽然微软也推出了C#，也许是其战略的一部分。
有些事情很难说。
对于那些想出来混的朋友，我建议你们学C++
Top
39 楼wolfliu（）回复于 2002-04-17 04:40:35 得分 0
感觉Java想成为一种包治百病的药
可能吗？
当你有病的时候，应该对症下药Top
40 楼youyouaq（阿叁）回复于 2002-04-17 08:40:44 得分 0
其实楼主的本意是好的：泼冷水并不是打击！是让大家看清更多的事情Top
41 楼myan（）回复于 2002-04-17 10:39:15 得分 10
看了一下日期，居然贴出来好几天了，这段时间没怎么来CSDN，错过了跟楼主交流的机会。
楼主显然经验丰富，其实他的主要观点就是：
1. 现在人们拿C++来是解决复杂问题的。
2. C++解决复杂问题会更复杂。
3. 所以要给C++迷们泼点水。
我非常赞成楼主的第1、2条论据，而且现在的我也不打算去给C++迷们“煽风点火”，鼓励大家去赴汤蹈火。楼主的本意是很好的，如果大家头脑发热了（象我先前那样），就应该冷静一下。所以，泼点水也是应该的。
不过（当然会有这个“不过”），我不觉得这构成大家逃离C++的理由。
楼主给出的例子，我们太看懂。但我感觉得到，的确很复杂。无论这种复杂性是不可避免的，还是可以通过重新设计来避免，大家需要注意的是，这种复杂性实实在在的出现了。复杂性出现之后，怎么办？我觉得这恰恰是C++的用武之地。当你遇到了复杂问题时，总会有办法来解决，大不了降到C甚至汇编的层次，还解决不了的话，那你可以直接放弃了。对，在这个例子里，Java是有它的优势，可是风水轮流转，你用Java，说不定哪天另一种复杂性从水里冒出来，直捣Java的软肋，到那时，你怎么办？JNI？
我在与snowfalcon的通信里所提到的东西，现在自己也有很多不再认可。但是灵活的运用现代C++类库，可以降低绝大多数任务的困难程度，这是勿庸置疑的。从楼主提出的几个问题来看，他显然精通网络通信与多线程等设计领域，可是他可能同时还精通比如说高精度的数学运算，现代算法与数据结构，图形图象处理等等领域吗？可能，但总的来说，恐怕不能。
库的作用不是帮助你解决极端复杂的问题，而是让你不必付出太大的精力就解决某个领域中的普通问题。
因此，用你在工作中遇到的复杂状况来否定库的价值，以及库在降低普通任务困难程度的中的作用，我认为是不恰当的。
楼主一再提到，他在某些复杂任务中的出色设计与后来某著名框架和库的思路一致。这是好事，可是正好反驳了楼主因此对于库作用的怀疑。你遇到了复杂问题，没有别人的库能帮助你，但是你解决了，封装成库，你帮助了别人，这难道不是更大的好事吗？
普通用户使用C和C++的方式，的确需要指导。我看到太多初学者，用几个星期“精通”了C语言，然后奋勇地通读了一本C++书，再了解一点模板、STL、面向对象，就开始英勇地大量使用各种复杂的特性。这样不栽跟头才怪呢！为什么我认为教育问题很重要，原因就在这里。语言始终只是工具，是拿来解决问题的。如果你能用自己得心应手的基本方法解决问题，为什么要引入那么多复杂的东西呢？在编程里面，唯一值得你信赖的思想就是抽象的思想。C++和其他的语言只不过提供了更多的抽象手段，使你在遇到复杂问题是可以有足够的设计方案空间，用抽象解决问题，并不是让你随意地滥用高级特性，更不是让你相信有银弹的存在。
应该一开始就告诉大家，C++不是唯一的道路，编程这条路上真正拼的也不是语言。历史上最伟大的软件，几乎无一例外地是混合语言编程的结果。你或者学好C, Python, Perl, VB/C#/Delphi什么的，各取所长，混合运用，或者你把C/C++玩熟，争取在一个team里与他人配合，发挥自己的特长，都是可以的。更重要的是，决定高下的在语言之外，你对系统了解多少，对专业领域了解多少，经验是否丰富，你为人如何，学习能力如何.....，这些才是你的本钱！
Top
42 楼cloudwu（云风）回复于 2002-04-17 16:26:55 得分 10
我们现在项目, 结构设计上最大的纰漏就是对象的删除上.
就是主帖中提到的删除的那个时序问题 :)
最近我修改了设计, 打算用在下个项目里, 基本解决好了安全的对象删除.
首先所有的对象都是从一个对象池里分配出来. (类似 STL 的 allocator)
在删除的时候, 向这个对象池提交删除请求.
ps. 我们现在的项目是一个网络游戏. 游戏程序一般都有固定的脉搏, 比如
一秒工作 40 次. 别的软件也会有类似的东西.
那么, 程序的一个周期结束后, 删除该删除的对象被认为是绝对安全的.
(这个时候, 如上例举出的 ui event 都应该处理完了)
那么, 在一个运行周期里, 所有的删除请求都只是放在一个队列中.
等待这个周期完毕才真正删掉.
所以这里只需要避免待删除对象队列的 iterator 失效的问题.
向对象池提交的真正 delete 操作某个对象的时候, 当前操作的对象,
做一个 lock 操作, 被 lock 的对象, 自身在删除队列里的节点是不会被释放掉的, 但对象会析构掉. 然后后面的 unlock 操作会去释放队列中它的节点.
这样保证可以正确的取到下一个要删除的对象.
Top
43 楼fastest286（fastest286）回复于 2002-04-17 17:40:10 得分 0
呵, 云风也跑了过来. 是果子和你说的, 还是你自己上来的?
说到这个具体的问题
做自己的释放管理器的话, windows 的消息循环是一个地方吧, 判断好
消息不是sendmessage发送过来, 并且正在等待接收, 应该就可以处理,
然否 ?
看来game 中还犯了好些个设计考虑不周哦，例如当初的线程模型也没有
认真设计过。
期待你们的下一个版本，不过恐怕我也没有时间玩，看看受欢迎程度好了.Top
44 楼fastest286（fastest286）回复于 2002-04-17 17:43:49 得分 0
写错了, 居然我还不能去修改:
做自己的释放管理器的话, windows 的消息循环是一个地方吧, 判断好
消息不是sendmessage发送过来, 如果不是，表明消息从windows消息队列
中来, 应该可以安全删除对象，然否 ?Top
45 楼neptunez（）回复于 2002-04-17 18:12:13 得分 0
myan大侠说得太好了，期待着哪一天俺也说得出来~，呵呵Top
46 楼lion1900（雨后的天空）回复于 2002-04-17 18:14:38 得分 0
吵个屁呀，谁有本事去给LINUX等自由软件做点贡献，大家都缩在MS$下，有什么资格说这说那？？Top
47 楼cloudwu（云风）回复于 2002-04-17 19:15:07 得分 0
果子叫我来的 :)
其实开始也不是设计不周.由于效率考虑,很多地方都定义了对象控制的时序规则.
在遵守规则的情况下也不会出什么错. 如果严格的做保护, 就需要牺牲空间
和时间的代价了.
但是这次新版本, zhandong 在北京跟我们这边合作, 交流不畅. 广州
这边几个人, 写起来都没有出问题. zhandong 没吃透我做的那套系统,
在处理网络消息时背离了我定的一些规则. 导致极端情况下出错.
(比如在一瞬间接到两个消息, 把一个同一对象删除又立刻创建)
最后想改已经难度很大了, 最后采用了变通的方案.
新做的系统我已经决定牺牲掉一部分性能, 保证对象的安全. 而且最近几个月
研读了 stl 的 source, 很有启发. 重新写的 template 要漂亮的多.
我们新做的东西要比 windows 处理消息来的复杂, 因为对象需要模拟一个并发
处理的过程, 而不能按 windows 那样用一个队列去依次处理消息.
所以要复杂一些.
当初辅线程的部分, 我后来重写过了. 由于我们游戏一共就 3 个线程. 而不是
一个不定线程数量的玩意, 所以针对性的写了代码, 工作还是很稳定的.
新的 project 里, 主要是重新做了 GUI 的一部分, 新的东西合理的多.
基本所有的元素都跟 Windows 处理每个窗口那样, 有完备的消息机制.
界面上的元素也都统一了接口,可以方便的扩展, 现在用 C++ 单独的写
诸如 Edit, ListBox, Button 等等控件. 游戏的界面可以实现的非常复杂了.
(这两天刚实现了聊天信息的图文混排)
仅仅是代码量的问题(目前已经为界面底层写了近2万行代码), UI 系统的复杂度已经控制住了. 所有的界面控制和网络包分析都交给了一个嵌入脚本语言控制.
(已经不用 IE 和 javascript 了)
总的来说, 新做的这个东西比你在的时候看到的那个版本稳定的多, 至今所有
程序 crash 的问题都在 24 小时内找到问题所在并解决掉. 系统设计上的纰漏
暂时就是那个对象删除时序问题, 虽然设计开始我就意识到, 只是没想到
多人异地合作时, 为了避免这个问题而带来的麻烦之多.
想想先那个版本搞的人焦头烂额, 这次的整个编码过程要轻松的多了 :)
我本人对 C++ 解决复杂问题还是很有信心的
至于游戏开发, 参与的程序员有没有游戏开发经验感觉也无关紧要.
C++ 基本功最重要 :) 这次我们一起做的这个项目除了我之外, 再就是 kyo
ruiheng, zhandong. 都没有做过游戏程序. 但是感觉比去年做的时候舒服很多.
顶多, 我多填几个 object_xxx::draw 的函数就够了
Top
48 楼j8c（海软）回复于 2002-04-17 20:56:22 得分 0
UPTop
49 楼VSoft（vicky）回复于 2002-04-17 21:49:03 得分 0
这是一个公说公有理，婆说婆有理的问题，我只能说，凭我的感情，我爱C++Top
50 楼beck（）回复于 2002-04-17 23:09:25 得分 0
gzTop
51 楼frogking1（薛丁谔的猫）回复于 2002-04-18 00:20:57 得分 0
精彩！！高手请继续！Top
52 楼cber（cber）回复于 2002-04-18 00:44:16 得分 0
打个记号，以后再看Top
53 楼Solstice（大佛）回复于 2002-04-18 20:39:05 得分 0
gz...Top
54 楼cber（cber）回复于 2002-04-18 21:59:05 得分 0
嗨，忙了几天新的项目，总算可以抽出一些时间来好好看看这个帖子了^_^
对于上面大家的讨论，应该说的是，我的看法和myan差不多;-)
诚然，C++在目前来说还是使用人数最多的编程语言，但近几年（自标准化后）来我们在C++上的教育已经是大为落后了（尤其是相对Java来说），这也导致很多人在使用C++解决问题时不能充分地利用到C++中现有的资源，再加上不同的编译器厂商对于C++中的一些特性的实现手法各不相同，更增加了人们对于它的使用难度了。这不可不说是使用C++时的痛苦所在了。
但从C++的发展来看，它一开始是为了兼容C而出现，也就是说对于大部分的C代码，我们都可以比较容易地把它们在C++系统中重新编译使用并能够获得和在C平台下面一样的功能（以及几乎一样的效率）。这在目前的软件开发中还是很有意义的，因为不可能在每一个新项目开始后大家都要重新从轮子做起吧，重用是很必要的，也容易降低开发的费用和风险。从这方面来说，C++相对Java等新兴语言来说，还是很有竞争力的
暂时想了这么多，这次就这样吧^_^Top
55 楼do_do（do_do）回复于 2002-04-19 07:28:56 得分 20
楼主：早上看到你的第二个贴子，虽只是大概明白你们谈什么，但就想回。不巧开会的时间到了，开完会就忘了，现在看到你的这个帖子，实在忍不住想说几句。
首先，我在6年前接手了一个很象你的那样的一个CMIP的STACK库。那event是网包(AAbort indication)，整个stack(被称为session)是个ACE里的Event_handler，它的owner是SessionManager。这是设计错误。Session不应该是Event_handler而SessionManager才应该是。这样就不存在你说的问题。对应你的情况，callback应该是那owner的成员函数。
问题的关键是这些错误不是C++造成的而是用户造成的。JAVA因为有garbage collector，所以你的设计不出问题。如果你写个C++的garbage collector，你也一样不会有问题。这就证明不是语言面的问题。
当OO刚刚出现时，计算机的应用不广，面对的问题不太复杂，面向过程的方法完全可以胜任。随着应用的不断扩大，它所面对的问题又越来越复杂。OO是解决复杂问题的好方法，所以到80年代末90年代初就开始盛行。C++做为支持OO的语言，它是可以很好地解决复杂问题。OO解决复杂问题的关键是把复杂问题分解成不复杂的小问题。如果你的分解错误，或者是在用分解的小问题解答组合起来解决大问题时错，你最后可能使问题更复杂。从根本上讲，这不是C++或OO的错。最多只能说它不能阻止你范错。象JAVA等语言，它们在某些方面是有有阻止你犯错的能力，但没能根本上做到阻止用户犯错(可能吗？)。其实现在很多软件产品就是想在这方面给软件人员提供帮助。当你发现问题的解决方案比你想象的复杂时，最好还是检查一下你的设计。
话说回来，我很支持给C++迷们泼些冷水(前些日子和gigix通信就提到一下)。所谓的迷(fan)，就是崇拜。C++只是许多计算机语言中的一种，它只能起到语言能起到的作用--把你的想法告诉电脑。单精通语言而没有想法(idea)是虚的。如果你有很好的想法而对语言不太精通你仍然可能实现它。就象你不大会英文，你一样能大致地把想法告诉别人。如果你精通英文但没什么想法，充其量只能转述别人的思想。所以语言没有idea重要。复杂的系统不可能只是一个人的idea，你只有充份使用别人已经成型的想法，对它加以灵活使用才不至于停留在coder的水平上。
要下班接孩子去了(晚了要罚款^_^)，晚上或明天再聊！Top
56 楼fastest286（fastest286）回复于 2002-04-19 11:33:07 得分 0
呵呵，前面我虽然说不再讨论这个贴子了，但是这里有一个这么认真的
朋友参与进来，呵呵，还是应该一起交流。
>首先，我在6年前接手了一个很象你的那样的一个CMIP的STACK库。那event
>是网包(AAbort indication)，整个stack(被称为session)是个ACE里的
>Event_handler，它的owner是SessionManager。这是设计错误。Session
>不应该是Event_handler而SessionManager才应该是。这样就不存在你说
>的问题。对应你的情况，callback应该是那owner的成员函数。
>问题的关键是这些错误不是C++造成的而是用户造成的。
我的问题和你的问题不太相同，当初野心太大，想实现一个功能很齐全，
适应范围很广，平台很广的stack, 因为设计中类层次多，粒度也较细，但
是为了效率起见，又有一些机制设法保证效率。最后由于整个系统复杂度
过高,即使实现了也不能给 upper user 一个简单的使用界面后，不得不重
新调整设计，削减设计目标。
至于我提到的情况，有些时候是难以避免的，由于network stack 的太
复杂，不好举例，我用 Delphi 的 RAD 来举例吧, 反正没有native 垃圾收
集的OO 语言在这点上面都是一样的。希望你对这些工具多少有一点了解。
用 Delphi 实现一个 use case, 需要连续几个 form 顺序工作才能完成
工作的时候，当前面的 OK/Cancel 被 click 的时候，后面的 form 就应该
show 出来，而前面的 form 就应该 close & free.
问题是谁去 close & free 呢 ? 如果是 OK/Cancel Button 的事件处理
函数中进行，那么事件处理函数返回之后，VCL 库一定不再访问 self 了吗？
如果由后面的form 进行 close, 那么就引入了本来没有必要的耦合度了。
(这个耦合度还不算太难处理，但是这里只是举例而已)。
当然，如果整个设计体系不一样，有可能从开头的设计就可以避免这些问题。
但是，为了避免这些问题而不得不采取比较复杂的设计结构，并且复杂不是
因为 application domain 的概念，而是由于 language / class library
的限制而带来的，就不得不说这是语言对设计实现的支持不够，让程序员陷入
计算机领域的复杂度了。
再说回 delphi, delphi 其实对于刚才的问题是有解决的方法的。
第一个, 也就是大多数人的工作方法，所有的form 是在程序 start的时候create,
要 close 的时候只是 close, 不 free. 安全而傻瓜，就不评论了。
第二个, Release 方法. 调用 Release 之后，delphi 将在所有的 windows message
和 event handler 都处理完成之后 free form. 只要这里不再搞出一个多线程，
让另外一个线程调用 form 的非 event handler 成员函数，就没有问题.
说到底，是 delphi 实现了一个滞后的垃圾收集。
说了这些，我想表明的是，我提到的问题不是一个孤立的问题。在实践中有时候，
就是会碰到一些问题，用C++/Delphi 这种传统语言来实现，会由于语言本身支撑不够，
导致实现阶段不得不引入额外的复杂性，有时候甚至还是相当复杂性，才能处理好
一些基本问题。
对于有时间长期打磨一个系统的人，当然不存在问题。但是我这几篇文章，主要
还是针对主流开发中的人而言的。
> JAVA因为有garbage collector，所以你的设计不出问题。如果你写个C++的
> garbage collector，你也一样不会有问题。这就证明不是语言面的问题。
C++ 的 gc, 怎么区分一个 object 目前有一个成员函数还在调用过程中呢？
我没有跟踪最近 gc 的进展，总是觉得编译器不支持的话，难以做到。您如果
有心得，请不吝指教。
> 当OO刚刚出现时，计算机的应用不广，面对的问题不太复杂，面向过程的方法完全
> 可以胜任。随着应用的不断扩大，它所面对的问题又越来越复杂。OO是解决复杂问
> 题的好方法，所以到80年代末90年代初就开始盛行。C++做为支持OO的语言，它是
> 可以很好地解决复杂问题。OO解决复杂问题的关键是把复杂问题分解成不复杂的小
> 问题。
> 如果你的分解错误，或者是在用分解的小问题解答组合起来解决大问题时错，
> 你最后可能使问题更复杂。从根本上讲，这不是C++或OO的错。最多只能说它不能
> 阻止你范错。象JAVA等语言，它们在某些方面是有有阻止你犯错的能力，但没能根
> 本上做到阻止用户犯错(可能吗？)。
看来您也是有多年开发的程序员了。
我最近几年有一些感触，我说出来不妨讨论一下。
比起 面向过程，OO 更加接近 application model, 因而更容易分解，描述清楚
appliation model.
但是比起面向过程，OO 比编程基础设施(process, thread, stack, memory,
resource, 呵呵 RDBMS 也算吧 等)稍微又远了一点。
远了一点的其中一个结果是，OO 实现的程序，从 function call layer 的层次
上粒度更细，调用更多，嵌套调用一般也是更多。 这样子，在一些控制流复杂的程序
中(例如, UI/businesss/network 层都不太简单)，使用传统 OO 语言有些时候会因此
导致一些实现上的额外复杂度，例如我提到的，某些时候不得不构造一个自己的垃圾
收集系统。
说到底，我认为原因是，计算机底层是冯.诺结构，而传统OO语言在帮助我们将面向
应用领域的设计转换到冯.诺结构的时候，没有帮助我们处理掉其中一些细节问题。
对于没有时间慢慢打磨的项目来说，要从设计、实现的角度处理掉这些细节问题，
是不经济的。
> 其实现在很多软件产品就是想在这方面给软件人员提供帮助。当你发现问题的解决
> 方案比你想象的复杂时，最好还是检查一下你的设计。
呵呵。
> 话说回来，我很支持给C++迷们泼些冷水(前些日子和gigix通信就提到一下)。所谓的
> 迷(fan)，就是崇拜。C++只是许多计算机语言中的一种，它只能起到语言能起到的作用
> --把你的想法告诉电脑。单精通语言而没有想法(idea)是虚的。如果你有很好的想法而
> 对语言不太精通你仍然可能实现它。就象你不大会英文，你一样能大致地把想法告诉别
> 人。如果你精通英文但没什么想法，充其量只能转述别人的思想。所以语言没有idea重
> 要。复杂的系统不可能只是一个人的idea，你只有充份使用别人已经成型的想法，对它
> 加以灵活使用才不至于停留在coder的水平上。
> 要下班接孩子去了(晚了要罚款^_^)，晚上或明天再聊！
BTW:
其实我倒是希望 C++ 增强一些功能(或者可选)，然后对于语言高级特征，可以有
编译开关控制。普通程序员可以使用带有高级特征的 .H 文件，但是他自己的.H .CPP
文件中不能使用高级特征。这样在团队开发中，更容易进行控制。
主流程序开发因此而倾向于更低效的 Java/C# 我觉得可以理解。Java/C# 里面去除
很多高级特性，其实和主流程序员不能很好掌握有关系。
( 昨天和朋友聊起来，他们带的两个团队的开发，普通程序员连 new/delete 都不能
使用的, 必须通过特定的申请释放函数。为什么？普通程序员 能力/ 细致程度不够。)
慢慢聊吧。
Top
57 楼anrxhzh（百宝箱）回复于 2002-04-19 12:46:09 得分 20
楼主：
对于这个设计问题,C++有优雅的解决方案。
在这篇论文中有详细的介绍：
Wrapping C++ Member Function Calls( http://www.research.att.com/~bs/wrapper.pdf )
将boost的shared_ptr跟上面的方法结合起来，即使是在多线程的复杂环境下，也可以完美地解决对象销毁的问题，
Top
58 楼FireAngel（土豆）回复于 2002-04-19 13:03:50 得分 0
厉害厉害，都厉害，小弟好生景仰。
重复一下：“我对你的景仰有如滔滔江水连绵不绝，又如大河泛滥一发不可收拾”Top
59 楼fastest286（fastest286）回复于 2002-04-19 14:19:57 得分 0
to: anrxhzh(百宝箱)
快速粗略地看看了 BS的 wrapper, wrapper 解决了member function
引用计数问题, 从而 shared_ptr 可以继续工作, anrxhzh(百宝箱)
的解法, OK。
最近一两年已经在怎么充分利用 C++ 解决设计问题上面不是很用心了，
所以有一些问题，后来也没有认真思考。
原因是觉得发展下去，各个领域有更方便的工具，包打天下的工具(包括
语言)在处理每个领域问题的时候方便程度都不如这些工具，因此领域会
萎缩，因此开始不怎么用心了，惭愧。
C++ 确实能力强大，但是对detail designer 的要求很高, 就象刚才
的问题。
但是我仍然关注着C++, 因为毕竟还是有不少问题，C++ 是合适的，
特别是准备做一个精品, 呵呵。
谢谢 anrxhzh(百宝箱) 的指教，我下来再慢慢看看。Top
60 楼masterjames（三月街）回复于 2002-04-19 15:15:35 得分 0
......Top
61 楼fastest286（fastest286）回复于 2002-04-19 16:22:11 得分 0
anrxhzh(百宝箱) 提出来的解法, 对于完全是自己构造的类库已经可以
工作。只是尚有几个问题, 不是很致命, 但是也还有不方便(哎, 在现有
的 C++ 语言和库下面, 老是这样):
1. 对象有直接暴露的数据成员或者子对象, 作为参数传送给了别的非
成员函数。
2. 如果在现有的框架上工作, 例如MFC 下面, 原有的框架代码不支持
这些东西的情况下，不好配合工作。
如果不碰到这些个问题，解法还是很优雅的。
Top
62 楼Betta（小新）回复于 2002-04-19 17:35:33 得分 0
>to fastest286(fastest286)
>
>1. 对象有直接暴露的数据成员或者子对象, 作为参数传送给了别的非
> 成员函数。
暴露的数据成员本身就不是优雅的程序设计风格
>2. 如果在现有的框架上工作, 例如MFC 下面, 原有的框架代码不支持
> 这些东西的情况下，不好配合工作。
>
>如果不碰到这些个问题，解法还是很优雅的。
是的呀，目前的许多库，包括STL对于自身的replaceable都几乎没什么
支持，最近才知道 std::allocator 并不标准，自己写的allocator
只能针对某个STL implementation，而不是任意的STL，真觉得莫名其妙，
只好对容器类进行wrap，算优雅吗？
Top
63 楼Betta（小新）回复于 2002-04-19 17:49:21 得分 0
其实new/delete的问题很容易解决的，对我来说，大概一个月
最多出现一个memory leak的调试，而且也不麻烦，因为调试
MFC非常容易定位new是那个位置(VC6)，没有MFC也一样，MFC
的内存监测其实很容易模仿的，把new和delete重载就可以了，
还有就是TRACE出所有的构造/析构，再就是ASSERT防止错误的
参数。反正要得到正确的程序并不累。用boudschecker证明我
这样做的结果是内参和资源是没有leak的
只是写C++程序还是慢，反正就是快不起来，郁闷啊... 感觉
是C++给了我追求完美的诱惑，而我却用这个诱惑把自己绑在原地
//这个句型不错吧，呵呵
Top
64 楼fastest286（fastest286）回复于 2002-04-19 19:02:41 得分 0
to Betta:
"是C++给了我追求完美的诱惑，而我却用这个诱惑把自己绑在原地"
说得很好, 我也被绑了很长时间, 呵呵。
Top
65 楼elli（）回复于 2002-04-19 19:14:44 得分 0
我认为学习C++可以调整人的心态，培养一种踏踏实实做事的作风，有了这种品质后，即使学习其它语言，也有好处。不知大家以为如何？Top
66 楼efanl（传说中的一凡……）回复于 2002-04-19 19:34:21 得分 0
哇，这人懂不懂啊？Top
67 楼wangguoqian（新机器的灵魂）回复于 2002-04-19 20:00:19 得分 0
看看能不能回复`
▇▇▇▇▇▇▇
phoenix polar
←∮≡
▇▇▇▇▇▇▇
Top
68 楼do_do（do_do）回复于 2002-04-20 00:48:55 得分 0
> 用 Delphi 实现一个 use case, 需要连续几个 form 顺序工作才能完成
工作的时候，当前面的 OK/Cancel 被 click 的时候，后面的 form 就应该
show 出来，而前面的 form 就应该 close & free.
> 问题是谁去 close & free 呢 ? 如果是 OK/Cancel Button 的事件处理
函数中进行，那么事件处理函数返回之后，VCL 库一定不再访问 self 了吗？
如果由后面的form 进行 close, 那么就引入了本来没有必要的耦合度了。
(这个耦合度还不算太难处理，但是这里只是举例而已)。
我不了解Delphi，不过如果你可以做个form manager的话，让它来管理(就象window manager of X/MS window system)那些form应该可以避免这个问题。其实你一定有这些form管理的代码在你的系统里。
> 说了这些，我想表明的是，我提到的问题不是一个孤立的问题。在实践中有时候，就是会碰到一些问题，用C++/Delphi 这种传统语言来实现，会由于语言本身支撑不够，导致实现阶段不得不引入额外的复杂性，有时候甚至还是相当复杂性，才能处理好一些基本问题。
Again，this is not an implementation issue but design issue。是有可能因为某种方法的缺陷，使你在做设计时不得不增加复杂性。它往往予示这种方法将取代，新方法将会出现。
> 对于有时间长期打磨一个系统的人，当然不存在问题。但是我这几篇文章，主要
还是针对主流开发中的人而言的。
当电脑的应用使某一方法的潜在问题暴露的时候，即使是有时间长期打磨一个系统的人也无可耐何。就象用面向过程的方法来解决现今的许多应用时的问题，即使你是很有经验且有许多时间打磨，你也无法使问题消失。
> C++ 的 gc, 怎么区分一个 object 目前有一个成员函数还在调用过程中呢？
>我没有跟踪最近 gc 的进展，总是觉得编译器不支持的话，难以做到。您如果
>有心得，请不吝指教。
它不需要知道是否“有一个成员函数还在调用过程中”，因为那owner不会做delete，它只要知道对象的生命周期就行了。
> 看来您也是有多年开发的程序员了。
唉！老了^_^
> 比起 面向过程，OO 更加接近 application model, 因而更容易分解，描述清>楚appliation model.
赞同！
它只是更接近但还很不足，object decomposition对正个系统的好坏起举足轻重的作用，而此过程又是非常容易导致因人而异的结果。这是OO的很大缺陷。
> 但是比起面向过程，OO 比编程基础设施(process, thread, stack, >memory, resource, 呵呵 RDBMS 也算吧 等)稍微又远了一点。
你是说他们本来不是OO的东西，要加层wrapper来使它变成OO从而得出OO离它远了点？如果是，我不苟同。通过对象使用和通过函数来使用它们，我觉得很难说是近了还是远了。当然如果你的意思是别的又另当别论。
> 远了一点的其中一个结果是，OO 实现的程序，从 function call layer 的
>层次上粒度更细，调用更多，嵌套调用一般也是更多。 这样子，在一些控制流复
>杂的程序中(例如, UI/businesss/network 层都不太简单)，使用传统 OO 语言
>有些时候会因此导致一些实现上的额外复杂度，例如我提到的，某些时候不得不构
>造一个自己的垃圾收集系统。
“OO实现的程序从function call layer的层次上粒度更细”你是说因为要定义成类，所以它的成员函数就要尽量定义得完整些(well defined method)从而会导致许多小的成员函数，对吗？这是有可能。面向过程，你的粒度是过程，一个过程可以做许多的事。而面向对象的一个成员函数你不能不管合不合适都塞一大堆东西进去。所以，一个面向过程的过程可能对应好些个面向对象的成员函数甚至几个对象间的协调工作。对控制流复杂的程序，你OOA/D做得好，看上去你增加了它的复杂度(多加了些类做控制/管理)。但它实际上使理解更容易，能提高usability和flexibility。所以，从这种意义上看，它其实是降低了复杂度。
> 说到底，我认为原因是，计算机底层是冯.诺结构，而传统OO语言在帮助我们
>将面向应用领域的设计转换到冯.诺结构的时候，没有帮助我们处理掉其中一些细
>节问题。
类的成员函数其实就是一个过程，是完全可以(也应该)使用面向过程的一些技巧的。
> 其实我倒是希望 C++ 增强一些功能(或者可选)，然后对于语言高级特征，可
>以有编译开关控制。普通程序员可以使用带有高级特征的 .H 文件，但是他自己
>的.H .CPP文件中不能使用高级特征。这样在团队开发中，更容易进行控制。
我是觉得许多我们觉得的不便或问题不是改进C++能解决的。我等待另一种方法和语言的出现来彻底解决。
> 主流程序开发因此而倾向于更低效的 Java/C# 我觉得可以理解。Java/C# 里
>面去除很多高级特性，其实和主流程序员不能很好掌握有关系。
在美国，基本情况是C++程序员一般在开发某种技术的core，Java等程序员主要是做它的application。C++程序员的工作较稳定，因为需求量较少所以工资随国家经济状况的起伏也不大。
> ( 昨天和朋友聊起来，他们带的两个团队的开发，普通程序员连 new/delete
>都不能使用的, 必须通过特定的申请释放函数。为什么？普通程序员 能力/ 细致
>程度不够。)
前几年的IT boom，使美国也有不少这样的程序员。前些天带孩子上中文学校就碰到一位在国内学声乐的，现在在加州州政府做程序员。他的歌唱得可真好！
普通程序员本就不应该花精力于此。
Top
69 楼hahazhuzhu（东东）回复于 2002-04-20 04:36:08 得分 0
你用的那些高级语言并不是“简单”，里面有一大堆你没用到的垃圾代码，如果真是想简单的话去搞什么机器语言啊。现在的高级语言基本都是从C/C++衍变出来的。Top
70 楼fastest286（fastest286）回复于 2002-04-20 15:22:01 得分 0
to: do_do
> Again，this is not an implementation issue but design issue。
>是有可能因为某种方法的缺陷，使你在做设计时不得不增加复杂性。
>它往往予示这种方法将取代，新方法将会出现。
是的，可能是某种方法的缺陷。
如果一个语言/class library 实现一些系统的时候，非常频繁地需要
用代码处理非应用领域的问题，证明这个 语言/class library 在这方面
提供的支持还不够。
> 当电脑的应用使某一方法的潜在问题暴露的时候，即使是有时间长期
> 打磨一个系统的人也无可耐何。就象用面向过程的方法来解决现今的
> 许多应用时的问题，即使你是很有经验且有许多时间打磨，你也无法
> 使问题消失。
呵呵，如果不是目标领域相对稳定，还是可以慢慢地写出好的代码的。
例如 apache 这类的基础东西。
否则的话，就是你说的情况了。
>> C++ 的 gc, 怎么区分一个 object 目前有一个成员函数还在调用过程中呢？
>>我没有跟踪最近 gc 的进展，总是觉得编译器不支持的话，难以做到。您如果
>>有心得，请不吝指教。
> 它不需要知道是否“有一个成员函数还在调用过程中”，因为那owner不会做
>delete，它只要知道对象的生命周期就行了。
前面 百宝箱 给了我一个回答，可以部分解决问题。
但是，"不需要知道成员函数还在调用过程中" 还是不行的吧，想象成员函数
引发的调用序列使得 owner 将指向 object 的指针指向 null 了, 但是此刻调用
栈中还存在成员函数的调用。
>> 看来您也是有多年开发的程序员了。
>唉！老了^_^
不知道我们谁的年纪大，呵呵。
我的 nick, 就是指我已经是不合时宜的古董了。虽说当年还是快的。
>> 但是比起面向过程，OO 比编程基础设施(process, thread, stack, >memory,
>> resource, 呵呵 RDBMS 也算吧 等)稍微又远了一点。
> 你是说他们本来不是OO的东西，要加层wrapper来使它变成OO从而得出OO离它远了点？
> 如果是，我不苟同。通过对象使用和通过函数来>使用它们，我觉得很难说是近了还
> 是远了。当然如果你的意思是别的又另当别论。
不是指 wraaper.
拿 rdbms 来说, OO 设计的objects(包括基础类，派生类), 怎么在 rdbms 中组织
存储，是一个需要动脑筋的问题。
其他方面就比较不直观了，主要是较复杂的程序中，相关部分考虑不当，设计不良
会带来一些危险。解决的方法，当然还是要动脑筋，但是我希望语言，类库的设计，
能够设法引导人们避免问题。
> “OO实现的程序从function call layer的层次上粒度更细”你是说因为要定义
> 成类，所以它的成员函数就要尽量定义得完整些(well defined method)从而会导
> 致许多小的成员函数，对吗？
是的。
> 这是有可能。面向过程，你的粒度是过程，一个过程可以做许多的事。而面向对
> 象的一个成员函数你不能不管合不合适都塞一大堆东西进去。所以，一个面向过程
> 的过程可能对应好些个面向对象的成员函数甚至几个对象间的协调工作。对控制流
> 复杂的程序，你OOA/D做得好，看上去你增加了它的复杂度(多加了些类做控制/管理)。
> 但它实际上使理解更容易，能提高usability和flexibility。所以，从这种意义上看，
> 它其实是降低了复杂度。
对，您说得很对。
从我的论题来说，我希望基础语言对这些设计给予一定的帮助，不要每次实现复杂
系统的时候，都要再来做一套协调，控制类。
而且，对于经验不足的人来说，很有可能做到后面才发现问题。如果有一些机制放到
那里，可能能够更早地提醒设计者，或者出现问题也更好解决。
> 我是觉得许多我们觉得的不便或问题不是改进C++能解决的。我等待另一种方法和语言
> 的出现来彻底解决。
呵呵，这一点上面我有同感。
> 在美国，基本情况是C++程序员一般在开发某种技术的core，Java等程序员主要是做它
> 的application。C++程序员的工作较稳定，因为需求量较少所以工资随国家经济状况的
> 起伏也不大。
鉴于 C++ 的学习较困难，而且应用的领域开始缩减，所以我的看法是，不够勤奋聪颖
的人，转到别的语言上面去好了 :)
>> ( 昨天和朋友聊起来，他们带的两个团队的开发，普通程序员连 new/delete
>>都不能使用的, 必须通过特定的申请释放函数。为什么？普通程序员 能力/ 细致
>>程度不够。)
> 前几年的IT boom，使美国也有不少这样的程序员。前些天带孩子上中文学校就碰到一位
> 在国内学声乐的，现在在加州州政府做程序员。他的歌唱得可真好！
> 普通程序员本就不应该花精力于此。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
美国那边的 C++ 开发组织也是这样的吗 ?
希望您也给介绍一下。
Top
71 楼santaga（lynn）回复于 2002-04-20 16:19:58 得分 0
现在贬低c++提倡使用其它开发语言的人，都是那种在编程世界中摸爬滚打了几十年终于大撤大悟、看破红尘的高手之高高手。我这样的初级选手，连c++的特性还没有摸清楚，就又要转向什么java、delphi怎么能心甘情愿？
老大门，你总得让我精通了一门才泼冷水吧！！Top
72 楼hyt82cn（洋葱头）回复于 2002-04-20 16:25:44 得分 0
我对c++刚刚接触。。。。。
呵呵。。。
现在想问一下。。。。。
怎么才能证明你精通某一语言？？？
是多做程序么？？？
那程序都是什么样的？？？
有什么认证么？？？
呵呵。。。
Top
73 楼florist2000（我爱susan）回复于 2002-04-20 17:29:06 得分 0
他不过是不懂c/c++的人而已
我现在在用c/c++写一个视频编解码算法
连一个对数组的操作是应该采用数组下标方式还是采用指针方式都要考虑老半天(显然指针方式要快点,但危险点)
连用多维数组的明显要方便很多,我都采用线性的指针实现.
无论做什么东西,我首先考虑的就是用c/c++
他说的"我用 C有13年了，C++也有9年了"(时间长不一定有说话的权威)
我不相信一个真正的c/c++高手会放弃c++,绝对没有可能
国内外有名的c/c++高手有谁放弃了他们喜欢的c/c++那?
另外,我也不认为c/c++高手把精力投入到用delphi这样的东西开发简单的windows应用上来.
至少我认识的c/c++玩的好点的人中,都喜欢用c/c++开发 linux/unix程序.
其实我本人也用delphi,vb做开发,尤其是做数据库应用的时候,但是从来没有想过要放弃c++.
Top
74 楼florist2000（我爱susan）回复于 2002-04-20 17:31:12 得分 0
说真的,尤其是在做算法的时候
我真恨不得嵌入部分汇编程序
其他的语言根本不在我考虑当中Top
75 楼QQKiKi（哈哈）回复于 2002-04-20 17:52:50 得分 0
真不知道何年何月能学到各位的水平啊！Top
76 楼cloudwu（云风）回复于 2002-04-21 14:49:19 得分 0
"连一个对数组的操作是应该采用数组下标方式还是采用指针方式都要考虑老半天(显然指针方式要快点,但危险点)"
干嘛不用 vector 和 vector::iterator 啊
即保证安全,又有效率.
ps. 视频处理, 想有效率, 应该用 MMX/SSE 指令, 这种并行处理的运算
指令, 是 C/C++ 无法实现的盲点. 写这部分代码, 何必考虑用 C/C++ 实现.
汇编啊.
用 delphi 不等于做简单的 windows 运用.
见山是山,见山不是山,见山还是山 :) 呵呵.
真的耍C++ 有 9 年历史的人的想法, 跟玩了 3 年 C++ 的人还是有区别的.
"绝对"一词不要轻易说出口啦
Top
77 楼tass（怪物猪）回复于 2002-04-22 20:29:53 得分 0
ha ha !Top
78 楼nfxz（网中人）回复于 2002-04-23 13:48:03 得分 0
除了对各位表示敬仰之外，真的没有什么可说的，我等晚辈的学习路还很长呀。
非常想知道各位如何达到这个层次的，不过，估计各位都没空来搭理，因为跟楼主理论更显示真功夫。
希望这个还能继续下去。Top
79 楼zengsiyu（绝代编手）回复于 2002-04-23 17:52:30 得分 0
这不用你来泼冷水，c++ 的艰难谁都知道。什么语言都有长处，都有短处。再讨论哪个语言好，哪个语言不好，已经是老生长谈。说多了，只能让人搞不清方向，误人子弟。对中国的软件业一点都没有好处。为什么中国的软件很少用 c\c++ 开发，我想缺乏这方面的人才有很大的关系。大家都这么务实，都这么贪图方便，不用下什么工夫就可以学会的东西大家都蜂拥而上。21天能“精通” 的东西当然能吸引很多人去学了，不管是专业的还是非专业的，都一起去搞。今天 Java 流行，大家都去学 java , 明天 C#流行大家都去学 C#.到头来什么都不精，有什么用。谁说 c\c++有那么容易出错，那么复杂，21天”精通“当然会这样了。多学多用，日积月累，当你能熟练的驾御这种语言的时候，你就发现他的优点，你会发现他的魅力了。你要说 java 好，我也能说出他的一大堆缺点。什么跨平台，那东东不知道有什么用，你看 borland 公司会不会用 java 来开发 Delphi,照理论来说，borland 如果用java 来开发 delphi ，那只要写一次代码，那就可以用他来运行在 windows 和 unix,linux 上了。你说 borland 会不会这么傻了。Java 的效率问题。同样是一个 简单的 hello world 程序， c++ 编的一下就执行完了，java 编的等了 6，7秒才开始运行，你说他在后台干什么。你可以说我环境没有配置好，那好了，我才刚学java ，你叫我如何懂得配置他，安装程序难道连这工作都不帮我做吗。你想看 java 编的程序吗， oracle 8i的安装程序 和 jbuilder都是用java 编的，你看看效果吧。我的是 celeron 300 cpu，你不要说我的机器配置太差，其他语言编的程序跑得都很好。你用 c /c++ 有多少年跟你的水平没有什么必然的关系，有的人开了10年的电梯也不说明他肯定会修理电梯。或许你六年前的c++ 水平和现在相比并没有什么提高。不要用你的例子来说明问题，那只是个例。
不好意思，说的有点过了，我真的不是很喜欢人说这个不好，那个不好。我学c++历史不久，可能还没有算入门。刚决心学好他，不希望你这种言论来影响我自己和那些想学好这门语言的人，我想应该鼓励那些肯努力学习的朋友，而不应该给他们当头泼冷水，什么语言都好，他们为什么会流行起来，因为我们需要他，这个市场需要他，我们只要精通他，能用他来完成我们的工作，那就是对我们的最大的用处。
多探讨一些技术问题，比争吵哪个语言更好来得更好！Top
80 楼GuangFengJiYue（光风霁月）回复于 2002-04-23 19:45:45 得分 0
楼上这头菜鸟真搞笑
明明大伙在讨论技术问题,你还叫喊着"多讨论技术问题"
晕Top
81 楼caoxin（）回复于 2002-04-23 20:23:47 得分 0
偶认为
要振兴民族软件
就要从低层开发作起
寻找未开发的领域
高举民族软件的大旗！！！
哈哈Top