学习C++：实践者的方法（Beta）

[pongba]

旨在分析并总结学习C++的误区和正确的学习方法，为初学者或者学习了一段时间迷惘的中级学者提供一个可操作的guideline。
猛击这里浏览全文，欢迎砖头（尤其是，如果你是初学者或学习了一段时间比较迷惘的话，请一定找出你觉得不好的地方），这也许是我写的C++学习方法的最后一篇文章，我觉得我要说的全都说完了:)

--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

[莫华枫]

pongba，你这是在扔原子弹，还是大个的。:P

--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/

[red...@gmail.com]

我不说学习方法, 说说 C++ 本身.

> 而C++却有大量的既有代码，已经使用C++去做他们的产品的公司，在很长一段时间之内几乎是不可能用别的语言 重写代码的，
  这是肯定的.

> C++积累了庞大的代码基，这个代码基不是一朝一夕能够推翻的。
  这也是肯定的.

主要的问题的,

1. 这些代码基更多的是公司内部的代码基

2. 而公开可获得的代码中, C++ 好用的并不是很多, 在这些不多的代码中, 又主要是一些库, 例如 ace, asio, boost, zthread 之类的, 这些库呢, 还不一定能一起使用. 例如, 想用 zthread 里面的 thread, 加上 ace 里面的 log, 就会碰到麻烦.

   看看 C++ 的库,  boost, zthread 之类的东西, 他们是由于 C++ 本身能力不够强, 以及缺乏跨平台支持的能力, 才显得重要, 换个语言, 这些需求也都消失了 ---- 这些, 就不能归到资源丰富那一类了.

   ACE 这种, 我自己感觉他设计得过于复杂, 对于普通的应用, 太重; 对于高要求的应用, 又未必能够满足要求, 而且太复杂了, 不好改造(不少C++ 的库都有这个毛病). 
   真正可用, 好用的 C++ 库, 有多少个呢 ?

3. C++ 自身的标准库覆盖范围是非常小的.

这三个原因加起来, 结果就是, 对于一个新的公司而言, C++ 的可用资源其实是很少的, 比很多语言都少. 

如果新的公司, 新的项目采用 C++ 越来越少, C++ 慢慢就不会是一个活跃语言了; 或者它变成一个写部件/扩展模块的语言, 写小部件给其他高层语言用, 这样, 它的种种高级抽象能力, 由于面向的问题小, 也就缺乏发挥的空间了.

BTW:
  我自己的开发实践中, 即使用 C++ 写代码, 从网上拿来重用的库, 经常是 C 的, 而不是 C++ 的, 因为就没有 C++ 的版本.

  对 C++, 我个人很不满两点:
1. 库太少, 老是需要自己动手做轮子, 或者拿C的轮子改装, 编写跨平台的程序的时候, 尤甚, 浪费太多生命.

2. 编译速度太慢, 又浪费太多生命.
  结果是, C++的强大表达能力, 强大的STL, 使得其他语言要花100天才能做完的那部分事情, C++ 33 天就做完了; 但是他的库缺乏以及编译速度慢, 使得另外一部分工作, 其他语言100天就可以做完, 他要花 300天 , 总共是 333 天 vs 200 天.

  他的种种陷阱, 是让人非常不爽, 但是只要团队中没有那种水平不够, 而又什么东西都要在实际项目去尝试的人, 那倒确实不是很有机会踩到.

pongba 写道:

旨在分析并总结学习C++的误区和正确的学习方法，为初学者或者学习了一段时间迷惘的中级学者 提供一个可操作的guideline。
猛击这里浏览全 文，欢迎砖头（尤其是，如果你是初学者或学习了一段时间比较迷惘的话，请一定找出你觉得不好的地方），这也许是我写的C++学习方法的最后一篇文章，我觉 得我要说的全都说完了:)

[Atry]

其实 Linus 炮轰 C++ 这个事件，对我的认识影响很大。我感受到了一些更本质的东西，比语言更本质的东西，我不知道这个帖子怎么表述出来。
怎么说呢，算了，就当我吹吹牛吧。就是说那些我迷惑的问题，再也不能迷惑我。我知道什么是真理，就算现在再有我不懂的东西，我也仅仅是不懂这一件东西本身，而我知道这件东西本身我是可以弄懂的。说的直接一点，我找到了心中的那一把尺子。也就是"什么是对的"这个标准我找到了。

在 07-12-11，red...@gmail.com<red...@gmail.com> 写道：

[安德尔斯]

永远的C++

在07-12-11，Atry <pop....@gmail.com> 写道：

[red...@gmail.com]

他的帖子有这么大的功效 ?

Atry 写道:

[Atry]

那段时间我正热衷于 boost ，云凤的日志里面写到这个，简直给我是当头一棒啊。我觉得版主应该也和我一样有同感吧。那之后版主就不写关于
C++ 特性或者 boost 的文章了……

在 07-12-12，red...@gmail.com<red...@gmail.com> 写道：

[Atry]

Linus 炮轰 C++ 这个事件以后，我就把 C++ 多出来的有意思的特性，都看成是语法糖来使用了。这个转变可以说就是丢下了"心智包袱"吧。
那之后我新写的 C++ 程序都用了新的编码规范，这个编码规范我明天发出来。
因为我是在这个事件以后接触 D 的，所以我对 D 解决这些问题尤其赞赏。
此外，和老莫不同，我没那么热衷于 concept ，也是因为我仅仅把这些语言特性当成一个工具，而不是面向 XX 之类的思想。

在 07-12-12，Atry<pop....@gmail.com> 写道：

[Atry]

http://blog.codingnow.com/2007/09/c_vs_cplusplus.html
我又把这个帖子读了一遍，每读一遍就感慨一遍。刚才又感慨了一遍。

[hayate]

写得真好，pongba

On Dec 11, 2007 6:12 PM, pongba <pon...@gmail.com> wrote:

[莫华枫]

伐木不自其本，必复生；塞水不自其源，必复流；灭祸不自其基，必复乱。
                                                                                        ——国语。晋语

此外，和老莫不同，我没那么热衷于 concept ，也是因为我仅仅把这些语言特性当成一个工具，而不是面向 XX 之类的思想。

呵呵，这可能同我们的背景差异有关吧。我的公司业务比较杂，多为事业单位、学校的软件，也做些企业软件。这些东西就事论事地开项目做，效率很低，重复劳动严重。那么比较好的还是建立企业级的基础组件和平台。做这些东西，对于语言的抽象和性能的综合能力提出很高的要求。之所以热衷于concept，还是希望能够用更少的劳动，得到更多更好的代码。这几天在做一个基础组件，需要进行类型转换。如果有了concept，那么只需大约四分之一到五分之一的代码就可以完成，而且代码可靠性更高。
另外，我的机械专业背景可能也促使我寻求更本质的解决方法。举个例子：现代加工中心要加工一个工件，必须用夹具把它夹住。而且，夹具夹持的牢固程度，直接影响到加工精度。但是对于形状复杂的工件，必须用专用的夹具才能固定住。专用夹具价格很贵，而且经常一次性使用就废弃，很浪费。后来有人发明了组合夹具，通过一些基本模块的组合，形成特定的形状，夹持工件。但是组合夹具的应用范围有限，没法处理复杂结构的工件。而且采购成本高，使用复杂，生产效率很低。综合起来也没有比专用夹具合算多少。
但是，10年前，国外的新一代加工技术轻而易举地解决了这个问题。工件只需留一个柄，用简单的类似台虎钳的夹具夹住，便可以以很高的精度加工。其实方法也不复杂，通过提高刀具的旋转速度（两万专以上），便消除了这个问题。究其原因，就是刀具在切削工件的时候，会给工件施加一个压力，但是当刀具转速提高之后，这种切削应力会逐渐变小。这种高速加工技术已经在Boeing，Lockheed Marting等企业应用于新一代jsf战斗机的生产，可以不降低产品品质的情况下，大幅降低成本。
这里的关键在于只有认清提高刀具转速可以减少对工件的切削应力，从而降低对夹具的要求，这样一个基本规律。我对concept的学习和研究也是本着类似的思路而做的。
我对concept的热衷更大程度上是为了尽早地熟悉这种技术，发掘它的应用，为将来做好准备。根本的目的和你所说的"当成一个工具"是一回事。我希望能够尽可能多的发挥一件工具的作用，提高自己的开发效率。

至于"面向XX的思想"么，我倒没有刻意追求过。一般也是拿来当作一个公用术语使用而已。

[pongba]

On Dec 12, 2007 3:12 AM, Atry <pop....@gmail.com> wrote:

那段时间我正热衷于 boost ，云凤的日志里面写到这个，简直给我是当头一棒啊。我觉得版主应该也和我一样有同感吧。那之后版主就不写关于
C++ 特性或者 boost 的文章了……

版主很久不写C++特性&boost的文章了 :P

BTW. 我并不赞同Linus的观点。他的观点的前提是他所处的领域。不知道Atry对Linus话最大的感悟是什么。。

[pongba]

On Dec 12, 2007 3:46 AM, Atry <pop....@gmail.com> wrote:

http://blog.codingnow.com/2007/09/c_vs_cplusplus.html
我又把这个帖子读了一遍，每读一遍就感慨一遍。刚才又感慨了一遍。

Atry，我们讨论讨论云风的帖子吧，我也重看了一遍，云风的核心思想是：C++容易引诱人做出过多的抽象工作（并非与解决问题直接相关的），乃至在并不需要抽象的时候引诱人去抽象。
Bjarne对此的观点则是另一回事：我们的系统已经足够复杂了，仅仅因为害怕（被引诱&误用）而避开某些语言特性，无异于因噎废食。

你怎么看？

[buhongbo]

一点建议：

看了pangba的这片好文，解决了我心里的一些疑惑。

 

另外我有一个建议，以前也在想的，就是：抽象惩罚 ==〉抽象损失，效率惩罚==〉效率损失。

我觉得把惩罚换成损失，我在理解的时候更容易。

 

---

buhongbo

2007-12-12

---

发件人： Atry

发送时间： 2007-12-12 03:58:10

收件人： pon...@googlegroups.com

抄送：

主题： [TopLanguage] Re: 学习C++：实践者的方法（Beta）

[lordoffox]

写的不错，我也觉得C++社区过于喜欢讨论C++是什么而不是C++做什么，（我感觉这个论坛也在大量做这样的工作^.^），特别是虚函数的优点这段我
特别认可，很多人都喜欢吹一吹虚函数貌似自己懂了虚函数,oop,gp这些专业气息的术语就进入了大师的行列一样，很少人会去思考虚函数是怎么用来解决
问题的，我认为其实虚函数和回调函数（C里大量运用）都是提供一个间接层来抽象变化的。所以我反对风云这句话"C++容易引诱人做出过多的抽象工作"，
事实是人们都喜欢做过多的抽象工作，人都是有惰性的，而人更喜欢责备别人而不是自己，这就是C++如此尴尬的原因，也许是我使用C++多年稍微有一点点
驾驭C++的能力所以说话有一点点不靠谱，不过"C++确实不适合所有人，因为C++需要你思考更多东西，无论是写代码做设计，还是处事"，这就是我的
观点啦。

[pongba]

On Dec 12, 2007 10:32 AM, buhongbo <buho...@gmail.com> wrote:

一点建议：

看了pangba的这片好文，解决了我心里的一些疑惑。

 

thanks:)

另外我有一个建议，以前也在想的，就是：抽象惩罚 ==〉抽象损失，效率惩罚==〉效率损失。

我觉得把惩罚换成损失，我在理解的时候更容易。

不过抽象惩罚(abstraction penalty）是一个由来已久的词，擅改了估计会造成困惑:-)

[red...@gmail.com]

pongba, 我观察到这么一个现象, 不知道你是否同意:

在网络编程这一块, C++ 可重用库的使用覆盖程度, 似乎比这些库设计初衷覆盖程度要小. 不少的客户,服务器项目,例如不少游戏软件项目, 都没有使用 C++ 可重用库 ---- 无论是使用 C++ 通用网络库ACE, 或者专用的游戏库, 反倒libevent 这种轻量级的C 库, 被接受的程度似乎更高.

如果这个现象我没有看错, 那么表明了什么呢? 我来初步分析一下:

1. 用到C/C++ 来编程, 对系统的性能, 容量, 可扩展性要求都相对会更高, 否则, 为什么不用更简易的语言来编程 ?
   其他语言的库/框架有些不足的情况下, 多数还能够被使用者忍受, 例如 java 不支持非 block io 很多年, 搞得必须thread per connection, 也照样用下来.
   但是, C/C++ 碰到这种情况, 就肯定不能被忍受.

2. C++ 的不少库的设计太过野心勃勃, 缺乏专心做好一个工作, 和其它库配合好的思想
   ACE 的设计, 是想什么样的通信软件都可以用它, 一网打尽, 结果是很复杂很罗嗦, 做什么都不轻松, 和 C++ 语言的特点倒比较象. 结果是, 做简单的事情, 多数懒得用它, 做复杂的应用, 能不能用还要看应用的具体情况了.

   再说一些游戏编程的库, 底层有网络通信, log, thread, 高层有对象管理, 由于 C++ 标准库的缺乏, 以及 C++ 社区的习惯, 这些库都自立更生, 不需要和别的库协作, 也很难协作, 要接受它的设计和实现, 就全部接受, 顶多是自己重新其中的代码, 而很难将几个库中的优秀部分组合起来.

   这个因素影响更大, 使得现有的库难以组合发挥作用. 想想, 数学上的组合效应, 可以产生的变化有多少啊.

如果 C++ 的库可以协同工作, 那么现在 C++ 肯定就不至于陷入缺乏库的情况了, 现在是, 什么方面的库几乎都是有的, 但是由于经常只能接受一套, 顶多是一套大的, 加几个很小的.

这是一个很要命的状态, 但是眼下看不到改善的倾向.
 

pongba 写道:

[莫华枫]

说得好！
特别是这句：" 如果 C++ 的库可以协同工作, 那么现在 C++ 肯定就不至于陷入缺乏库的情况了, 现在是, 什么方面的库几乎都是有的, 但是由于经常只能接受一套, 顶多是一套大的, 加几个很小的."

[pongba]

On Dec 12, 2007 10:46 AM, <red...@gmail.com> wrote:

pongba, 我观察到这么一个现象, 不知道你是否同意:

在网络编程这一块, C++ 可重用库的使用覆盖程度, 似乎比这些库设计初衷覆盖程度要小. 不少的客户,服务器项目,例如不少游戏软件项目, 都没有使用 C++ 可重用库 ---- 无论是使用 C++ 通用网络库ACE, 或者专用的游戏库, 反倒libevent 这种轻量级的C 库, 被接受的程度似乎更高.

如果这个现象我没有看错, 那么表明了什么呢? 我来初步分析一下:

1. 用到C/C++ 来编程, 对系统的性能, 容量, 可扩展性要求都相对会更高, 否则, 为什么不用更简易的语言来编程 ?
   其他语言的库/框架有些不足的情况下, 多数还能够被使用者忍受, 例如 java 不支持非 block io 很多年, 搞得必须thread per connection, 也照样用下来.
   但是, C/C++ 碰到这种情况, 就肯定不能被忍受.

2. C++ 的不少库的设计太过野心勃勃, 缺乏专心做好一个工作, 和其它库配合好的思想
   ACE 的设计, 是想什么样的通信软件都可以用它, 一网打尽, 结果是很复杂很罗嗦, 做什么都不轻松, 和 C++ 语言的特点倒比较象. 结果是, 做简单的事情, 多数懒得用它, 做复杂的应用, 能不能用还要看应用的具体情况了.

   再说一些游戏编程的库, 底层有网络通信, log, thread, 高层有对象管理, 由于 C++ 标准库的缺乏, 以及 C++ 社区的习惯, 这些库都自立更生, 不需要和别的库协作, 也很难协作, 要接受它的设计和实现, 就全部接受, 顶多是自己重新其中的代码, 而很难将几个库中的优秀部分组合起来.

   这个因素影响更大, 使得现有的库难以组合发挥作用. 想想, 数学上的组合效应, 可以产生的变化有多少啊.

如果 C++ 的库可以协同工作, 那么现在 C++ 肯定就不至于陷入缺乏库的情况了, 现在是, 什么方面的库几乎都是有的, 但是由于经常只能接受一套, 顶多是一套大的, 加几个很小的.

这是一个很要命的状态, 但是眼下看不到改善的倾向.
 

肖兄，网络编程我不熟悉。不过你说的这个现象我觉得的确是广泛存在的，不仅是网络编程。而且不仅在C++里面。OOP的框架类库都有庞大和紧密耦合的毛病，C的库往往简洁，基本，比如Win32 API，容易在其上再造其它东西。那么，由此是不是得出结论说，库设计应该是分层的，底层用一层最简单的接口封装primitive的功能？

继续召唤这方面有经验的，以下为咒语：@#@$&#%$  :P

[pongba]

On Dec 12, 2007 10:57 AM, 莫华枫 <longsh...@gmail.com> wrote:

说得好！
特别是这句：" 如果 C++ 的库可以协同工作, 那么现在 C++ 肯定就不至于陷入缺乏库的情况了, 现在是, 什么方面的库几乎都是有的, 但是由于经常只能接受一套, 顶多是一套大的, 加几个很小的."

其实， 这个问题算是说到所有库设计的痛处了。其实这是个自有库以来一直都让人头疼的问题，即可组合性问题。C++ GP当时引入的初衷便是为了（一定程度上）解决可组合性问题（因为GP的接口是非侵入的，容易组合两个第三方库组件）。然而，就算有了非侵入的接口，还是不够。事实上，只要有接口这个玩意的存在，库向外暴露的功能就一定会受到接口的限制。接口一方面提供了一组规范的使用逻辑界面，然而另一方面却隐藏了信息。也许一个库能够做比接口呈现出来的多得多的事情，但由于只暴露了某些接口，所以功能便被削弱了。也正因此，Eric Raymond才会倡导接口设计的正交性，因为正如线性代数中的正交基可以线性组合出整个线性空间的任何一个向量一样，一组正交的接口最完备且最简约地暴露了整个库的capacity，使得用户可以基于对这组接口的组合来实现出自己需要的功能。

[莫华枫]

正交性可是很让人头大的事情。:)
很多设计都采用归纳法（不是数学归纳法），试图遍历各种情况，然后总结。当然这不会错，肯定可以得到正交。问题是：是否已经便利了所有情况，不能保证。
但是演绎法需要从原理和理论上分析一个问题，然后给出完整的模型。这种难度可想而知。更何况很多问题根本没有现成的理论。

[red...@gmail.com]

我觉得这不是 OOP 一定会带来的问题.

举个例来说, C++ 标准库中, 如果提供一个 log 库, 不用特别强, 不用特别完备, 只需要最终用户调用 log 语句这里, 给出一个标准, 能够带来什么好处呢 ?

以后其他家提供 log 功能, 可能功能更强大, 内部实现更复杂, 初始化语句也不同,但是, 给最终用户调用 log 语句这里, 99% 的可能会遵循这个标准, 这能够带来什么呢  ?   虽然, 初始化语句无法移植, 但是程序的主体部分代码, log  部分, 是可以适应多个框架的, 是可以更改 log 库的.

但是, C++ 什么都没有做, 后果就是各家的使用方法都不同, 假设现在 C++ 推一个新的标准, 又怎么样呢 ? 大量的代码已经绑定到不同的框架平台上了.

我觉得C++ 标准库的设计者, 老是想着, 倚天一出, 谁与争锋 ?  但是实际上问题就在这里.

1. 设计一个复杂的库, 用起来麻烦, 以后扩展起来也麻烦
2. 老是出不来标准, 什么事情都被坏掉了

还不如, 设计简单的库, 结构是简单的,  API 是清晰的, 存在扩充的余地的, 定好一个标准, 以后第三方可以在这里增强.

BJ 不希望推 C++ 的子集语言, 但是语言分裂. 好, 现在语言不分裂, 但是用户分裂 ---- 不同的用户使用不同的语言特性, 库分裂--- 不同的库不能协同工作.  现在, 即使标准库中加入 log, 网络编程, 线程, 那些已经用ace, zthread 很深入的程序, 难道就会改过去吗 ?  C++ 的分裂是最严重的.


D, 语言里面, 如果按照 phobos 的走法, 迟早会在这方面重蹈覆辙, 好在有个 tango, 即使 tango 现在的实现有缺点, 但是, 举例, 希望用到 log 的人, phobos 不够用, 会用 tango, 这就有一个相对标准, 以后的各个第三方库, API 之间起码可以兼容, 不至于写最终代码的人, 用一个第三方库就绑死在上面.




pongba 写道:

On Dec 12, 2007 10:46 AM, <red...@gmail.com> wrote:

pongba, 我观察到这么一个现象, 不知道你是否同意:

在网络编程这一块, C++ 可重用库的使用覆盖程度, 似乎比这些库设计初衷覆盖程度要小. 不少的客户,服务器项目,例如不少游戏软件项目, 都没有使用 C++ 可重用库 ---- 无论是使用 C++ 通用网络库ACE, 或者专用的游戏库, 反倒libevent 这种轻量级的C 库, 被接受的程度似乎更高.

如果这个现象我没有看错, 那么表明了什么呢? 我来初步分析一下:

1. 用到C/C++ 来编程, 对系统的性能, 容量, 可扩展性要求都相对会更高, 否则, 为什么不用更简易的语言来编程 ?
   其他语言的库/框架有些不足的情况下, 多数还能够被使用者忍受, 例如 java 不支持非 block io 很多年, 搞得必须thread per connection, 也照样用下来.
   但是, C/C++ 碰到这种情况, 就肯定不能被忍受.

2. C++ 的不少库的设计太过野心勃勃, 缺乏专心做好一个工作, 和其它库配合好的思想
   ACE 的设计, 是想什么样的通信软件都可以用它, 一网打尽, 结果是很复杂很罗嗦, 做什么都不轻松, 和 C++ 语言的特点倒比较象. 结果是, 做简单的事情, 多数懒得用它, 做复杂的应用, 能不能用还要看应用的具体情况了.

   再说一些游戏编程的库, 底层有网络通信, log, thread, 高层有对象管理, 由于 C++ 标准库的缺乏, 以及 C++ 社区的习惯, 这些库都自立更生, 不需要和别的库协作, 也很难协作, 要接受它的设计和实现, 就全部接受, 顶多是自己重新其中的代码, 而很难将几个库中的优秀部分组合起来.

   这个因素影响更大, 使得现有的库难以组合发挥作用. 想想, 数学上的组合效应, 可以产生的变化有多少啊.

如果 C++ 的库可以协同工作, 那么现在 C++ 肯定就不至于陷入缺乏库的情况了, 现在是, 什么方面的库几乎都是有的, 但是由于经常只能接受一套, 顶多是一套大的, 加几个很小的.

这是一个很要命的状态, 但是眼下看不到改善的倾向.
 

肖兄，网络编程我不熟悉。不过你说的这个现象我觉得的确是广泛存在的，不仅是网络编程。而且不仅在C++里面。OOP的框架类库都有庞大和紧密耦合的毛 病，C的库往往简洁，基本，比如Win32 API，容易在其上再造其它东西。那么，由此是不是得出结论说，库设计应该是分层的，底层用一层最简单的接口封装primitive的功能？

继续召唤这方面有经验的，以下为咒语：@#@$&#%$  :P

[red...@gmail.com]

> 肖兄，网络编程我不熟悉。不过你说的这个现象我觉得的确是广泛存在的，不仅
> 是网络编程。而且不仅在C++里面。
对了, 我开头是没有强调网络编程方面的, 后来一想, 不对, GUI 编程方面还是颇
有一些重用性的, 赶快缩小一些范围 :)

GUI 方面, 自己重新造轮子的代码太高, 而且除了游戏编程之外, 性能和内存耗用
也不会是特别问题, 所以, 找一个现成轮子用还是最轻松的.

[pongba]

On Dec 12, 2007 11:15 AM, <red...@gmail.com> wrote:

我觉得这不是 OOP 一定会带来的问题.

举个例来说, C++ 标准库中, 如果提供一个 log 库, 不用特别强, 不用特别完备, 只需要最终用户调用 log 语句这里, 给出一个标准, 能够带来什么好处呢 ?

以后其他家提供 log 功能, 可能功能更强大, 内部实现更复杂, 初始化语句也不同,但是, 给最终用户调用 log 语句这里, 99% 的可能会遵循这个标准, 这能够带来什么呢  ?   虽然, 初始化语句无法移植, 但是程序的主体部分代码, log  部分, 是可以适应多个框架的, 是可以更改 log 库的.

但是, C++ 什么都没有做, 后果就是各家的使用方法都不同, 假设现在 C++ 推一个新的标准, 又怎么样呢 ? 大量的代码已经绑定到不同的框架平台上了.

我觉得C++ 标准库的设计者, 老是想着, 倚天一出, 谁与争锋 ?  但是实际上问题就在这里.

1. 设计一个复杂的库, 用起来麻烦, 以后扩展起来也麻烦
2. 老是出不来标准, 什么事情都被坏掉了

还不如, 设计简单的库, 结构是简单的,  API 是清晰的, 存在扩充的余地的, 定好一个标准, 以后第三方可以在这里增强.

BJ 不希望推 C++ 的子集语言, 但是语言分裂. 好, 现在语言不分裂, 但是用户分裂 ---- 不同的用户使用不同的语言特性, 库分裂--- 不同的库不能协同工作.  现在, 即使标准库中加入 log, 网络编程, 线程, 那些已经用ace, zthread 很深入的程序, 难道就会改过去吗 ?  C++ 的分裂是最严重的.


D, 语言里面, 如果按照 phobos 的走法, 迟早会在这方面重蹈覆辙, 好在有个 tango, 即使 tango 现在的实现有缺点, 但是, 举例, 希望用到 log 的人, phobos 不够用, 会用 tango, 这就有一个相对标准, 以后的各个第三方库, API 之间起码可以兼容, 不至于写最终代码的人, 用一个第三方库就绑死在上面.

简而言之，就是一定要早标准化，哪怕是只标准化一个简约的API？

如果我没理解错的话，你的意思是说，C++中的库为什么标准化迟缓，就是因为库设计者总期望实现一个最完备的库出来？

我倒是觉得是因为C++语言的种种缺陷导致库设计的过程艰难重重，而且还会导致库接口的设计不够优雅，这样的库，怎么敢标准化？就拿GUI来说吧，到现在没有一个好的GUI标准，我认为根源既不在钱也不在政治，而是语言本身的缺陷， 这个缺陷导致了直到最近几年boost才出现了boost.signal/slot（而且还不够好），在之前几乎所有的C++ GUI库在event/handler机制上都各干各的（其中走得最远的是John Torjo的win32gui）。也就是说，语言缺陷=>没有一个好的event/handler机制可供标准化=>没有一个好的GUI库可供标准化。结果是只能在各个领域遵从事实标准。即，我觉得语言本身是最根本的障碍。

[red...@gmail.com]

>
> 简而言之，就是一定要早标准化，哪怕是只标准化一个简约的API？
我是这样看.
>
> 如果我没理解错的话，你的意思是说，C++中的库为什么标准化迟缓，就是因为
> 库设计者总期望实现一个最完备的库出来？
我是基于BJ在哪里说过, 力量不够, 所以开发库很慢. 实际上, 如果不要求开发的
库, 不必进行继承,组合直接可以满足n多领域的直接要求, 而且时间空间开销都要
很小, 开发库的难度, 会降低很多.
>
> 我倒是觉得是因为C++语言的种种缺陷导致库设计的过程艰难重重，而且还会导
> 致库接口的设计不够优雅，这样的库，怎么敢标准化？就拿GUI来说吧，到现在
> 没有一个好的GUI标准，我认为根源既不在钱也不在政治，而是语言本身的缺
> 陷，这个缺陷导致了直到最近几年boost才出现了boost.signal/slot（而且还不
> 够好），在之前几乎所有的C++ GUI库在event/handler机制上都各干各的（其中
> 走得最远的是John Torjo的win32gui）。也就是说，语言缺陷=>没有一个好的
> event/handler机制可供标准化=>没有一个好的GUI库可供标准化。结果是只能在
> 各个领域遵从事实标准。即，我觉得语言本身是最根本的障碍。

GUI 就不说了, 这方面要提供好用的框架, 确实不容易, 再说, 即使技术上能做出
来, 又怎样呢 ? 各个平台早有自己的主导框架, 有自己的小社区了, 操作系统提
供商主力肯定放在自己的 SDK 上.

但是其他方面, 文件系统, 目录枚举, 进程, 线程, 以及他们的同步和通信, log,
序列化, 网络, 内存池 等等, 这些方面语言能力是够的, 局面不是一样很乱 ?

[Atry]

Linus 那个事件以后的很多文章，属于瞎子摸象，各自摸到一部分。我和云风是两个不同的瞎子，摸到的东西不同，结论也不同。

同样从"心智包袱"出发，云风和 Linus 认为 C++
引诱程序员去做过多的抽象。我则认为是程序员引诱自己去做过多的抽象。所以我得出的结论是，只要放下包袱， C++ 照样可以用嘛；云风得出的结论是
C++ 不能用。

"在绝不对效率进行妥协的前提下进行抽象"，这是 C++ 的目标，C++
FQA（http://yosefk.com/c++fqa/index.html） 把这一点抓出来冷嘲热讽，云风和 Linus
则说这是"低效的抽象编程模型"。我这样的 C++
死忠者是不能接受这样的观点的。我认为"在绝不对效率进行妥协的前提下进行抽象"是可行的，问题在于 C++
程序员进行了过多的抽象和错误的抽象，而不在于 C++ 不能正确的抽象。

所以，当我们看到 D 的时候，D 抨击 C++ 抨击得越厉害，我们这些 C++
的死忠就越高兴："看,'在绝不对效率进行妥协的前提下进行抽象'是能做到的， D 不就做到了吗"

此外，C++ 追求到了极致的类型安全， D 也一样认可，而 C 只是半拉子的类型安全。

对比 std::string 、 std::vector 和 D
的动态数组，这三个东西里面，越靠后的越简单，越靠后的所做的事情越少，越靠后的越好用，越靠后的越透明。

关于抽象， D 所做的事情并不比 C++ 更多，但是比 C++ 更对！

D 做对了！

过几天我会开始写一个新游戏的服务器的代码，我会考虑用 C++ 、 D 或者 Java 。 C++
的优势在于我个人编写经验要多得多，劣势在于没有垃圾收集以及编译速度慢。 D 的优势在于他更容易做对，劣势在于缺乏第三方库，需要移植一些 C
库。 Java 的优势在于 IDE 强大和虚拟机所保证的安全，劣势在于他放弃了极致的性能（当然这也可能是优势）

在 07-12-12，pongba<pon...@gmail.com> 写道：

[WaterWalk]

这里的"初学者"还是要细分一下
1）C++的初学者，他们已经熟悉了一门或多门其它语言，因为某种需要来学习c++
2）程序设计的初学者，碰巧用C++来入门。

对于第1种初学者，他们已经对程序设计有了相当不错的了解了，再来学习C++会轻松一些。因为不需要同时对付程序设计概念和C++本身的复杂问题。这种
人在学习C++时虽然可能仍然会有些痛苦，但应该不至于茫然不知所措。

对于第2种初学者，在C++学习上花费更多的时间几乎是肯定的。因为他们不仅要学习程序设计本身，还要对付C++里面那些麻烦的概念。

所以其实很多人并不推荐第2类初学者刚开始就学习C++。起码我看gamedev.net上的很多入门帖的回答都是用C#, Python来入门，以后
需要再来学习C++。

至于BS常说的"我们的系统已经是极度复杂的了，为了避开C++的复杂性而干脆不用C++（Linus的做法），无异于因噎废食。"。这么说没错，有时
C++的确是最好的选择。但C++里面所谓"非本质复杂性"很多也的确是事实。而且这些复杂性还有很多来源于"历史包袱"。所以很多时候用C++更像是
一种妥协，如果有更好得替代品或者没有什么庞大的遗留代码，不知道还会有多少人仍然选择C++。所以这里我想问个问题，C++打算一直妥协下去么？

C++0x按照圈子内人士说，大大有助于简化以后写库的复杂度。可我觉得这里有几个风险：
1。C++0x会象C++98那样获得广泛的支持么？C99M就是一个典型。当初C89很快就获得了一批支持的编译器，可能够完全支持C99的就寥寥无
几了，两大编译器主力VC++和GCC更是没能完整支持（带了个坏头？）。
2。C++0x是在c++98的基础上添加了一堆新特性。这些新增加的特性会减少人们的学习成本么。我意思是在一个本身已经复杂的语言上，再添加一堆特
性，然后说这些特性可以让人们学习和写代码轻松，我不知道事实会不会是这样。

关于楼主文章中所说的"心理因素"，或称之为某种"迷信"，我觉得虽然有道理，不过很难有什么做为。 可能在小范围内有所影响，但大范围让人们改变很
难。除非C++社群里出了个"圣人"之类的人物， 可以用简单的办法让人们轻松学会C++，或者人们可以看到写C++可以不用在语言本身上费力挣扎，否
则人们会改变看法么？（bs的新书不知道会有什么效果。）

On Dec 11, 6:12 pm, pongba <pon...@gmail.com> wrote:
> 旨在分析并总结学习C++的误区和正确的学习方法，为初学者或者学习了一段时间迷惘的中级学者提供一个可操作的guideline。

> 猛击这里 <http://docs.google.com/View?docid=dczfp64v_86hptcvtg5>

[pongba]

On Dec 12, 2007 1:46 PM, Atry <pop....@gmail.com> wrote:

Linus 那个事件以后的很多文章，属于瞎子摸象，各自摸到一部分。我和云风是两个不同的瞎子，摸到的东西不同，结论也不同。

同样从"心智包袱"出发，云风和 Linus 认为 C++
引诱程序员去做过多的抽象。我则认为是程序员引诱自己去做过多的抽象。所以我得出的结论是，只要放下包袱， C++ 照样可以用嘛；云风得出的结论是
C++ 不能用。

总算触摸到你的观点了，不容易啊～:-)

话说回来，放下包袱，一句话，做起来谈何容易啊，我blog上有人建议我应该在书单里面加上《设计模式》、《敏捷软件开发：原则，模式与实践》两本。就拿设计模式来说吧，这本书太容易误导人了。当我们手头有一堆fancy的工具的时候，真的很难从心理上摆脱用一用他们的倾向，上次我记得7猫转的douban上的一个讨论里面也有人提到说是C++的特性放着不用觉得暴殄天物，典型心态啊。

我甚至觉得OO都不应该过早介入。等到实践当中体会到ADT的不足时再去看或许更好。我们的学习之路往往是一溜小跑把一堆语言特性装脑子里面，根本不知所以然，不知道动机和适用场景，所以，知识有了，能力没有。思考也没有。非得经过了一次次的痛苦挫折才会发现一些道理。而到那个时候，有人就会走得更远，走向另一个极端，认为要简约到...我不知道...过程式编程。我认为这种转变乃是心理所致，并非客观的。

此外，我不认为非得经历痛苦挫折才会发现设计的真谛。而是这些书都讲解得不够深刻。所谓不够深刻，比如说设计模式吧，里面就有大把的模式根本就是在C++语言的静态性质的限制之下衍生出来的workarounds，如果拿到ruby里面就消失了。但关键是书中并没有把这个"背景"讲出来，背景被忽略了，也许作者本人也跟所有人一样，并没有意识到这个背景吧，虽然这个背景其实是适用场合的一个重要部分。结果就是大家都只看到了一个形式，一个花架子，不知道本质是什么。

我的感觉是，读了《设计模式》和《敏捷软件开发》这类书，最大的可能性（绝大多数人）是离好的程序员又远了一步。

[redsea]

多年以来, 我升级计算机的主要目的就是为了提高 C++ 的编译速度, 等待编译过程, 很难受.

看到很多不错的轮子不能用, 需要自己做凑合的轮子, 也很难受.

本来用 C++ 写程序倒也算顺手, 然后看到 effective c++ 之类的书, 读到前几本的时候, 感觉还可以, 再看到 n 多本这样的
书的时候, 感觉很惶恐, 哇, 好多陷阱啊.

再加上, 找合适的 C++ 程序员也很难, 这个时候, 对 C++ 已经感觉很疲惫了, 但是, 仍然只能继续用C++, 因为没有一个合适的
替代品.

待发现D, 尝试过D, 感觉和 Arty 差不多, "D 做对了", 加上编译速度那么快, 我为什么不试试转过去呢?

D的编译器, 经过尝试, 后端代码生成是可靠的, 前端有时候碰到复杂的情况, 可能会出错, 但这问题咱可以克服.

D的库不丰富? C++ 的库难道丰富了? 一个一个列举出来是蛮多的, 但是项目中真正可以一起用的, 却没有几个. 而且按照D社区的局面看,
D 的库应该不会像 C++ 的库一样四分五裂.

所以就开始转过去了, 现在已经有一些程序 24*7 地在现场跑了一个多月了, 没有出现什么问题.

[pongba]

On Dec 12, 2007 1:58 PM, WaterWalk <toolm...@163.com> wrote:

这里的"初学者"还是要细分一下
1）C++的初学者，他们已经熟悉了一门或多门其它语言，因为某种需要来学习c++
2）程序设计的初学者，碰巧用C++来入门。

这个分类有建设性！

对于第1种初学者，他们已经对程序设计有了相当不错的了解了，再来学习C++会轻松一些。因为不需要同时对付程序设计概念和C++本身的复杂问题。这种
人在学习C++时虽然可能仍然会有些痛苦，但应该不至于茫然不知所措。

对于第2种初学者，在C++学习上花费更多的时间几乎是肯定的。因为他们不仅要学习程序设计本身，还要对付C++里面那些麻烦的概念。

所以其实很多人并不推荐第2类初学者刚开始就学习C++。起码我看gamedev.net上的很多入门帖的回答都是用C# , Python来入门，以后
需要再来学习C++。

我的第一个感觉是赞同。可我仍然担心用C#、Python入门会让人走入OOP的误区。比如我们假设一个用C#入门的去看《Beginning C# Objects》，这本书amazon评价不错，但我觉得非常差劲。里面上来讲了一大堆C#语言特性，先把人的脑袋绑住，然后又用一些不切实际的例子来介绍OO（殊不知一个方法学最重大的问题就是——在什么场合之下用）。那么，看完这本书，这个初学者学到了什么呢？我很怀疑。

我现在认为应该从TCPL（C语言）学起。因为最接近编程的本质——数据结构加算法。在这条路上怎么都不会走歪。而后再去学抽象机制，也许更能体会到为什么需要形式化的这些东东。
 

至于BS常说的"我们的系统已经是极度复杂的了，为了避开C++的复杂性而干脆不用C++（Linus的做法），无异于因噎废食。"。这么说没错，有时
C++的确是最好的选择。但C++里面所谓"非本质复杂性"很多也的确是事实。而且这些复杂性还有很多来源于"历史包袱"。所以很多时候用C++更像是
一种妥协，如果有更好得替代品或者没有什么庞大的遗留代码，不知道还会有多少人仍然选择C++。所以这里我想问个问题，C++打算一直妥协下去么？

我认为用C++的确是妥协。不过话说回来，用Java和C#不是妥协吗？用Python不是妥协吗？妥协的大小问题。C++要求为大量的复杂性妥协，付出不菲的学习开销。

如果有更好的替代品，不会。
 

C++0x按照圈子内人士说，大大有助于简化以后写库的复杂度。可我觉得这里有几个风险：
1。C++0x会象C++98那样获得广泛的支持么？C99M就是一个典型。当初C89很快就获得了一批支持的编译器，可能够完全支持C99的就寥寥无
几了，两大编译器主力VC++和GCC更是没能完整支持（带了个坏头？）。

GCC连concept都已经支持了。VC的支持估计要滞后标准发布3年。话说回来，0X的语言特性其实实现起来非常容易的，这是因为与其说它们是特性，不如说是对语言的一种完善。
 

2。C++0x是在c++98的基础上添加了一堆新特性。这些新增加的特性会减少人们的学习成本么。我意思是在一个本身已经复杂的语言上，再添加一堆特
性，然后说这些特性可以让人们学习和写代码轻松，我不知道事实会不会是这样。

那些特性早就应该在语言当中了，长久以来人们因为没有它们，逼不得已用各种workarounds。举个C的例子，C89的宏不支持可变参数，C99支持（了吗？），这能算是一个"特性"吗？对于本就该在那里的东西，学习成本几乎是没有的，反而是因为不在那里，导致了workarounds的制造和学习成本。
 

关于楼主文章中所说的"心理因素"，或称之为某种"迷信"，我觉得虽然有道理，不过很难有什么做为。 可能在小范围内有所影响，但大范围让人们改变很
难。

我的认为相反。我认为只有指出了最深层的原因（了解人们为什么会这样，C++的文化为什么会发展成这样），才有可能真正摆脱它的影响。
使用心理学解释我认为解释到了问题的症结上，如果影响不够大或者大不起来，我认为是我的个人影响力不够大，并非因为这个表达方法不够好。
 

除非C++社群里出了个"圣人"之类的人物， 可以用简单的办法让人们轻松学会C++，或者人们可以看到写C++可以不用在语言本身上费力挣扎，否
则人们会改变看法么？（bs的新书不知道会有什么效果。）

让有影响力的人直接拨乱反正（而无需加以解释深层的心理原因）的确有其用处，但不是长远之计。人们终究还是会被吸引到细节和workarounds上面去的。事实是，人太容易往下钻，却很难做到把头抬起来。人太容易把事情看复杂，却很难把事情看简单。

bs的新书我也很期待，我期望这是迄今为止最佳的C++入门教材。但整个编程书籍市场呈现这样一种势态：被大众所称为经典的书，技巧书为多。这很能反映一些事情。因此我觉得bs的一本书不能改变太多东西，但是一个好的开始。

[pongba]

肖兄，冒昧的邀请你写D的实践系列，我觉得你的讨论是最实践最用本的，我觉得这方面的积累非常宝贵，正如鲍志云同学说的，分享经验是一种最大的复用！
你可以到我blog上客座:-) 也可以开一个blog啊:-)

[red...@gmail.com]

pongba 写道:
> 肖兄，冒昧的邀请你写D的实践系列，我觉得你的讨论是最实践最用本的，我觉

> 得这方面的积累非常宝贵，正如鲍志云同学说的，分享经验是一种最大的复用！
> 你可以到我blog上客座:-) 也可以开一个blog啊:-)

哈哈, 一鳞半爪地说几句我还可以, 系统地讲述事情, 我就不行了, 会乱七八糟的.

最近几个月, 其实工作任务都很重, 空闲时间不多, 这两天在groups上发了很多厥
词, 是因为有点头痛, 集中不起精神来, 于是乱吐口水 :)

[pongba]

一鳞半爪就很好，不用系统，实际上一旦系统地整理，倒是可能会出现很多废话:P
我有一个建议，见这里： http://groups.google.com/group/pongba/browse_frm/thread/4fc7a675fbb78e9e/d50e12e53f855404#d50e12e53f855404

[red...@gmail.com]

一鳞半爪就很好，不用系统，实际上一旦系统地整理，倒是可能会出现很多废话:P
我有一个建议，见这里： http://groups.google.com/group/pongba/browse_frm/thread/4fc7a675fbb78e9e/d50e12e53f855404#d50e12e53f855404

  口水吐在 group 和吐在 blog 上, 会有很大的不同吗 ;)

[SpitFire]

对这段深有同感，一个实践不够的程序员过早的接受OO等概念，过度设计的情况会经常出现

对于ruby，前段时间也是有这样的疑问，GOF中的好多模式发现在ruby中用不太上，写代码的过程中发现基本没用使用模式

在07-12-12，pongba < pon...@gmail.com> 写道：

我甚至觉得OO都不应该过早介入。等到实践当中体会到ADT的不足时再去看或许更好。我们的学习之路往往是一溜小跑把一堆语言特性装脑子里面，根本不知所以然，不知道动机和适用场景，所以，知识有了，能力没有。思考也没有。非得经过了一次次的痛苦挫折才会发现一些道理。而到那个时候，有人就会走得更远，走向另一个极端，认为要简约到...我不知道...过程式编程。我认为这种转变乃是心理所致，并非客观的。

此外，我不认为非得经历痛苦挫折才会发现设计的真谛。而是这些书都讲解得不够深刻。所谓不够深刻，比如说设计模式吧，里面就有大把的模式根本就是在C++语言的静态性质的限制之下衍生出来的workarounds，如果拿到ruby里面就消失了。但关键是书中并没有把这个"背景"讲出来，背景被忽略了，也许作者本人也跟所有人一样，并没有意识到这个背景吧，虽然这个背景其实是适用场合的一个重要部分。结果就是大家都只看到了一个形式，一个花架子，不知道本质是什么。

我的感觉是，读了《设计模式》和《敏捷软件开发》这类书，最大的可能性（绝大多数人）是离好的程序员又远了一步。

--

刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

--
SpitFire

[pongba]

某种程度上，写博客就是吐口水:P

正如Googol所说的，记录到blog上，以后也好翻查以及和更多人交互啊，这个groups现在的访问量已经每天2千了，在过阵子，也许大量有价值的信息就会很快淹没在贴海中了... :P

[pongba]

On Dec 12, 2007 3:23 PM, SpitFire <spit...@gmail.com> wrote:

对这段深有同感，一个实践不够的程序员过早的接受OO等概念，过度设计的情况会经常出现

对于ruby，前段时间也是有这样的疑问，GOF中的好多模式发现在ruby中用不太上，写代码的过程中发现基本没用使用模式

不仅不用模式，也不用啥啥Idiom的（我总是把这个词同Idiot搞混:P）。我感觉这就是为什么那么多程序员觉得Ruby用起来解放了的原因。
用Javascript我都觉得解放了许多:P sigh~

[red...@gmail.com]

pongba 写道:

On Dec 12, 2007 3:23 PM, SpitFire <spit...@gmail.com> wrote:

对 这段深有同感，一个实践不够的程序员过早的接受OO等概念，过度设计的情况会经常出现

对于ruby，前段时间也是有这样的疑问，GOF中的好多模式发现在ruby中用不太上，写代码的过程中发现基本没用使用模式

不仅不用模式，也不用啥啥Idiom的（我总是把这个词同Idiot搞混:P）。我感觉这就是为什么那么多程序员觉得Ruby用起来解放了的原因。
用Javascript我都觉得解放了许多:P sigh~

  设计模式我就没有看完过.
  一些模式, 我觉得是太浅显, 做那些事情就应该这样做啊, 已经不知道用了多少次了.
  另外一些模式, 我觉得太复杂, 太弯弯绕, 有没有必要为了这么严密的封装而绕这么远啊 ? 多了这么多层 .

  就没有耐心看完它.

[Atry]

我也很不屑模式。不过我一般不告诉别人。

在07-12-12，red...@gmail.com <red...@gmail.com> 写道：

[Googol Lee]

呵呵，设计模式看的时候就会想：这个我不是用过了么？原来叫这个名字。

看一遍可以，了解精髓：对接口编程而不是对实现编程。至于使用的时候，具体问题具体分析。

在 07-12-12，Atry<pop....@gmail.com> 写道：

--
新的理论从少数人的主张到一统天下，并不是因为这个理论说服了别人抛弃旧观点，而是因为一代人的逝去。

My blog: http://googollee.blog.163.com

[Atry]

"面向接口"这个词的确切含义是什么？如果是指的"封装性"，那么我同意。
但是问题的关键在于，暴露数据结构并不等于不封装。有的时候，数据结构就是接口本身。

在07-12-12，Googol Lee <goog...@gmail.com > 写道：

[李扬]

模式。最重要的作用是用来沟通--我是这样觉得对。

GOF写的无非是一些前人经验的总结。

一个最简单的例子职责链模式。看看unix下人们怎么工作就知道什么是职责链了（find ./ | grep *）。说到职责。。我们会想到单一职责原则，google下"unix的精神"你会发现unixer们几十年前就在提倡这个东西了，但是他们用的是c。其实我倒觉得模式是一种知识传承的一种方法而已，能够更好的沟通交流。如果两个人都懂模式。那么一个模式名就可以代表一大堆东西。一个不好的比喻，这个就像是编程领域的黑话（切口？）

 

在07-12-12，Googol Lee <goog...@gmail.com> 写道：

呵呵，设计模式看的时候就会想：这个我不是用过了么？原来叫这个名字。

[Googol Lee]

恩，对。这个接口是指概念上的接口，而不是java里的那个概念。

实际上，系统提供的api就是一系列接口。所有应用程序都是对这个接口编程的。虽然系统升级了，应用程序却不用做改动。

[Googol Lee]

恩，对。这个接口是指概念上的接口，而不是java里的那个Interface。

实际上，系统提供的api就是一系列接口。所有应用程序都是对这个接口编程的。虽然系统升级了，应用程序却不用做改动。

在 07-12-12，Atry<pop....@gmail.com> 写道：

[red...@gmail.com]

问题是, 我经常能够记住某些时候可以怎么做, 但是很难记住别人给它去的名字,
因为某些名字和他做的事情, 似乎对应起来有点含糊, 而机械记忆力我是最差了.

BTW:
读中学的时候, 大家都知道, 咱们中国考历史最喜欢考年号, 发生地点之类的, 我
机械记忆力差, 曾经考过19分 --- 其实本来是应该是不止的 --- 至少有20 嘛
--- 有一道题目, 我记得事件前后相关地点肯定是意大利三个城市, 但是我记住了
三个城市的名字, 却记不住对应关系, 所以全部填了其中一个城市的名 --- 我至
少对了一个啊, 但是老师就是不给我分, 还将我作为坏人的典型 :(

当年本科毕业的时候, 同学问我考不考研; 后来工作之后, 有个前辈问, 有个博导
找学生, 问我考不考, 我都是赶快摇头, 好不容易捱过了要背书的学生年代, 还要
自己扎进去 ?

BTW again:
本科有个同学, 平时一起逃课, 但是很多课就是考得好, 没办法, 别人脑袋聪明.
搞笑的是, 马列当时是开卷考, 他老人家居然考不及格, 一个年级不多的几个不及
格就有他 ---- 不就是根据题目翻目录抄内容嘛, 虽然目录咱几个都是第一次翻.
这人幸好没有学图书检索专业.
最牛的是一个女同学, 上课总是坐在最后一排开小差, 据说晚上也不学习, 但是别
人次次考试, 都是年级前几名, 不服不行; 到了考研, 也不见她老人家怎么复习,
就考取北大的研究生 ---- 这才知道, 相比之下, 自己的脑袋是绝对的差劲啊.

李扬 写道:

[WaterWalk]

On Dec 12, 2:40 pm, pongba <pon...@gmail.com> wrote:

> On Dec 12, 2007 1:58 PM, WaterWalk <toolmas...@163.com> wrote:
>
> > C++0x按照圈子内人士说，大大有助于简化以后写库的复杂度。可我觉得这里有几个风险：
> > 1。C++0x会象C++98那样获得广泛的支持么？C99M就是一个典型。当初C89很快就获得了一批支持的编译器，
> > 可能够完全支持C99的就寥寥无
> > 几了，两大编译器主力VC++和GCC更是没能完整支持（带了个坏头？）。
>
> GCC连concept都已经支持了。VC的支持估计要滞后标准发布3年。话说回来，0X的语言特性其实实现起来非常
> 容易的，这是因为与其说它们是特性，不如说是对语言的一种完善。
>

对这一点还是有点怀疑。实在是因为C99的缘故。C99增加的新特性也不算多，但GCC没能完整支持（好像是说一些新特性和GCC的扩展冲突）。VC+
+支持就更少了，压根就没什么动作。ms给出的官方理由是"没有大规模的开发者要求"。如果不能获得广泛的支持，那么新特性自然不会有多少人去用，或者
说已经就不推荐用了。

所以并不在于新特性是不是好实现，而是在于能不能广泛实现。我之所以感到不确定，就是因为不知道C++0x能不能获得大家的一直青睐，以致于不实现它就
无法忍受。正如你所说，c89有一些缺陷，c99做了完善和扩充，但对很多人来说c89已经可以了，所以没必要费心再支持新的特性。在
comp.lang.c上的确是见过这样的观点，只是不知道实际这个理由所占的比重有多少。也可能是不想破坏c在很大程度上是c++的一个子集。也可能
是和编译器厂商的决策有关。对于C++0x的态度，我不知道那些编译器厂商是怎么想的，如果他们的态度和C99一样，那么C++0x即使再好，也是用不
起来。而且目前的情况是，正如各位老大所说，"C++的阵地正在收到各方面的挤压"。等C++0x出来，不知道大家对这个新标准的热情还能有多大。

[sean...@gmail.com]

accelerated c++中文版翻译的怎么样？

在 07-12-12，WaterWalk<toolm...@163.com> 写道：

[莫华枫]

这个还是取决于应用。0x的新特性有助于大幅降低代码量和复杂度。这两天我正在做的东西，0x下只需1/5左右就得了，大概两天就能搞定。但现在已经做了快一礼拜了。boost库中的很多内容在新特性下，只需1/10的代码，而且更可靠。1/10？是1/10吧，pongba？

longsh...@gmail.com
http://blog.csdn.net/longshanks/

[八大]

c++ 0x添加的特性是c++社区急切需要的，编译器应该会很快跟上吧。gcc下个版本（4.3）会添加tr1，vc明年也会添加tr1，速度已经很快了。
在 07-12-12，莫华枫<longsh...@gmail.com> 写道：

[Eli]

很长见识 :)

On Dec 12, 9:31 am, "莫华枫" <longshank...@gmail.com> wrote:
> 伐木不自其本，必复生；塞水不自其源，必复流；灭祸不自其基，必复乱。
>
> ----国语。晋语
>
> 此外，和老莫不同，我没那么热衷于 concept ，也是因为我仅仅把这些语言特性当成一个工具，而不是面向 XX 之类的思想。
>
> 呵呵，这可能同我们的背景差异有关吧。我的公司业务比较杂，多为事业单位、学校的软件，也做些企业软件。这些东西就事论事地开项目做，效率很低，重复劳动严重。那么比较好的还是建立企业级的基础组件和平台。做这些东西，对于语言的抽象和性能的综合能力提出很高的要求。之所以热衷于concept，还是希望能够用更少的劳动，得到更多更好的代码。这几天在做一个基础组件，需要进行类型转换。如果有了concept，那么只需大约四分之一到五分之一的代码就可以完成，而且代码可靠性更高。
> 另外，我的机械专业背景可能也促使我寻求更本质的解决方法。举个例子：现代加工中心要加工一个工件，必须用夹具把它夹住。而且，夹具夹持的牢固程度，直接影响到加工精度。但是对于形状复杂的工件，必须用专用的夹具才能固定住。专用夹具价格很贵，而且经常一次性使用就废弃，很浪费。后来有人发明了组合夹具，通过一些基本模块的组合，形成特定的形状，夹持工件。但是组合夹具的应用范围有限，没法处理复杂结构的工件。而且采购成本高，使用复杂，生产效率很低。综合起来也没有比专用夹具合算多少。
> 但是，10年前，国外的新一代加工技术轻而易举地解决了这个问题。工件只需留一个柄，用简单的类似台虎钳的夹具夹住，便可以以很高的精度加工。其实方法也不复杂，通过提高刀具的旋转速度（两万专以上），便消除了这个问题。究其原因，就是刀具在切削工件的时候，会给工件施加一个压力，但是当刀具转速提高之后，这种切削应力会逐渐变小。这种高速加工技术已经在Boeing，Lockheed
> Marting等企业应用于新一代jsf战斗机的生产，可以不降低产品品质的情况下，大幅降低成本。
> 这里的关键在于只有认清提高刀具转速可以减少对工件的切削应力，从而降低对夹具的要求，这样一个基本规律。我对concept的学习和研究也是本着类似的思路而做的。
> 我对concept的热衷更大程度上是为了尽早地熟悉这种技术，发掘它的应用，为将来做好准备。根本的目的和你所说的"当成一个工具"是一回事。我希望能够尽可能多的发挥一件工具的作用，提高自己的开发效率。
> 至于"面向XX的思想"么，我倒没有刻意追求过。一般也是拿来当作一个公用术语使用而已。
>
> --
> 反者道之动，弱者道之用
> m...@seaskysh.com
> longshank...@gmail.comhttp://blog.csdn.net/longshanks/

[Eli]

这个我倒是比Linus事件认识的早. 网上广泛流传着一篇Anders的访谈, 他轻蔑的语气让我觉醒了:

关于C#增加各种语法糖的问题:
1. 说到底, 对象不也就是语法糖吗?

关于委托和匿名委托的问题:
2. 这几乎就是函数式编程的全部了.

这两句话我印象深刻. 这厮不是个学院派, 但好歹也搞语言和开发工具很多年了, 同时身边又有一个最大的最容易产生各种问题和需求的团队. 说实
话, 我相信他的认识比世界上任何一个其它高手都会贴近一般的开发与应用. 虽然每个.NET程序员都嫌,NET变化的快, 我倒是觉得, 他还是太不
激进了, 以至于让.NET背上了的包袱, 提供那些更先进的手段太慢.

其实关于接口还是mixin的问题, 为什么VB9有了所谓的Dynamic Interface, 站在他们这些语言创造者的角度一看, 简直是一清
二楚. 20年前程序员们总是错用面向对象, 要用接口来限制, 省的折腾出问题又骂他们; 今天大家是觉得手段不方便了, 对于"组合"大多数人也有
了一定的经验, 于是就逐渐又开放限制了... 当然这些话不是他说的, 但是从他那个访谈, 详细解释为什么C#的virtual和Java设计的不
同, 就可以看得出来他的倾向性. 我觉得和Gosling相比(Gosling似乎近期具体工作也没有他做的多了), 我更在乎他的言论一些.

但这也一向是MS乃至Borland的风格, 即程序员如何编程, 应该由他们说了算..., 这又是我不喜的.

On Dec 12, 3:32 am, Atry <pop.a...@gmail.com> wrote:
> Linus 炮轰 C++ 这个事件以后，我就把 C++ 多出来的有意思的特性，都看成是语法糖来使用了。这个转变可以说就是丢下了"心智包袱"吧。
> 那之后我新写的 C++ 程序都用了新的编码规范，这个编码规范我明天发出来。
> 因为我是在这个事件以后接触 D 的，所以我对 D 解决这些问题尤其赞赏。

> 此外，和老莫不同，我没那么热衷于 concept ，也是因为我仅仅把这些语言特性当成一个工具，而不是面向 XX 之类的思想。
>

> 在 07-12-12，Atry<pop.a...@gmail.com> 写道：
>
> > 那段时间我正热衷于 boost ，云凤的日志里面写到这个，简直给我是当头一棒啊。我觉得版主应该也和我一样有同感吧。那之后版主就不写关于
> > C++ 特性或者 boost 的文章了......
>
> > 在 07-12-12，red...@gmail.com<red...@gmail.com> 写道：
> > > 他的帖子有这么大的功效 ?
>
> > > Atry 写道:
> > > > 其实 Linus 炮轰 C++ 这个事件，对我的认识影响很大。我感受到了一些更本质的东西，比语言更本质的东西，我不知道这个帖子怎么表述出来。
> > > > 怎么说呢，算了，就当我吹吹牛吧。就是说那些我迷惑的问题，再也不能迷惑我。我知道什么是真理，就算现在再有我不懂的东西，我也仅仅是不懂这一件东西本身，而我知道这件东西本身我是可以弄懂的。说的直接一点，我找到了心中的那一把尺子。也就是"什么是对的"这个标准我找到了。

[Googol Lee]

确实，如果对对象方法的调用可以做成类似C#扩展方法那样的语法糖，不用什么mixin，就可以方便扩展了。

能讲讲C#的virtual机制和java和c++的区别么？

在 07-12-14，Eli<Eli...@gmail.com> 写道：

[Eli]

Anders说的不是区别, 而是为什么区别.

他的意思大概是: virtual一个方法的同时你就背负上一个责任, 一个"override该方法如何折腾也不会出错的责任", 而他认为大多数类
作者其实根本不想负担这个责任, 所以C#的方法就被设计成默认是不可覆写的, 这样在程序员去打virtual这几个关键字的时候就会注意到这种责
任. 如果是默认virtual, 很多懒惰的程序员就会任由virtual传递给继承者, 同时又不负担这种责任.

类似的和Java不同的还有方法抛出的Exception是否应该被声明, 他说声明会抛出什么Exception, 这除了让每个人都烦, 没有任何
意义. 因为据他对程序员的了解, 大多数中间层次的类和方法, 只会简单的将Excption向上再次抛出. 因为一般的项目在设计时都会有一个集中
处理Exception的机制, 甚至在界面层简单的处理一下,这是因为这比较符合一个项目内部的总体成本(而不是这些开发者很蠢, 毕竟谁也不可能包
装或调用一次, 就要去考虑所有调用到的方法可能抛出的Excption), 最后任何方法关于Exception的声明, 都成了毫无意义的繁文缛
节. 而对于会去处理Excption的模块的作者, 却是怎么都会处理好的.

可以看到, 在virtual上他比Gosling谨慎, 而在Excpetion上反而放的开, 这些决定确实是非常击中使用者的要害的.嗯, 这家
伙十分的不信任程序员, 而且所有的观点基本都是从事实出发, 我觉得他很多看法还是相当有道理的. 说实话, 就惰性来讲, 我自己都不信任自己.
我感觉他不但懂得理论并且掌握大量的实践, 懂人这一点, 是最难得的.

毕竟这一路走来, 可以说使用(他自己开发过或间接参与的工具C/Pascal/C++/Delphi/.NET, 再加上他过去的对手现在的同事所开
发的工具C/C++/VB)的程序员, 非常有可能比的上包括Java在内的所有的语言使用者加起来的总和了...

[Googol Lee]

哦，我理解错了，以为是虚函数的实现区别。原来是指语法上的暗示。

Anders确实是大牛啊，这种细节都考虑的很周到。

[red...@gmail.com]

Eli 写道:

> Anders说的不是区别, 而是为什么区别.
>
> 他的意思大概是: virtual一个方法的同时你就背负上一个责任, 一个"override该方法如何折腾也不会出错的责任", 而他认为大多数类
> 作者其实根本不想负担这个责任, 所以C#的方法就被设计成默认是不可覆写的, 这样在程序员去打virtual这几个关键字的时候就会注意到这种责
> 任. 如果是默认virtual, 很多懒惰的程序员就会任由virtual传递给继承者, 同时又不负担这种责任.
>
>

D 的作者 Walter 的想法是, 到底什么函数应该 virtual, 什么函数不要
virtual, 对于库的原始设计者来说, 要做这个决定是不容易的, 要做出正确的决
定, 需要非常高超的预见力.

库的用户到时很清楚自己的需要, 所以他将职责转到库的用户那边去了, 库的用户
自己写 override, override 那个函数是不是有问题, 库的用户自己要负责.

Walter 的做法, 对 open source 世界, 实际项目的编写者很有实际意义.

Anders 的做法, 则主要对于库的作者有意义, 特别是, 不 open source 库, 库的
用户无法判断原来的实现是否适合 override, 此时 Walter 的做法行不通.

立场不同, 导致的技术决策都不同, 哈哈, 有意思.

[Eli]

没错 :)

不过, MS的.NET库, 其实是开源等价的.., 而且现在市面上那些免费工具(其实不用费多大劲就能自己写一个不错的出来)看起来比IDE翻阅源
代码还容易. MS本身现在也开始从1/4开源, 逐渐转变为羞羞答答的半开源了. 所以我觉得这倒未必是出于商业的考虑. 他那篇访谈, 似乎说到库
作者的心理和用户的心理, virtual也不全然是给真正的库作者用的, 而是往往被OO狂热者滥用.

但是, 我个人的经验确实是承受了很多的因为.NET运行库不virtual而带来的痛苦. 感觉Anders的出发点, 永远是考虑大多数人多些,
考虑真想改变些什么的人少些. 我虽然讨厌这种作风, 但是从他的立场上来说, 不得不说他的选择是合理的: 没人会怪自己不会写程序, 有了问题,
肯定是怪设计者, 尤其是设计者还收人家钱的情况下....

另外一点是, 能力越大责任越大.., 老实的Coder还好说, 最不好办的是那些觉得自己不错的瞎搞起来实在让人受不了. 既然都是库作者了, 自
然还是多下点功夫的好. 不过据我对最近一些MS代码实现的了解, Anders和微软一些其它技术方面的头头脑脑显然高估了MS其它team中实现者
的责任心....

[Eli]

另外一点是, 其实.NET给开发者了任意Hack的能力, 这方面能做到的事情简直和动态语言没区别了. 所以virtual也就无所谓了, 只是你
要Hack, 就要付出成本(劳动力, 丑陋, 效率), 这样Hack就会只发生在最必要的的时候. 在这样的前提下, 我即使不爽, 其实心里还是
支持Anders的做法的, 虽然承认自己支持微软的某一种设定, 感觉很邪恶... : - }

[pongba]

On Dec 15, 2007 12:52 PM, <red...@gmail.com> wrote:

Eli 写道:

> Anders说的不是区别, 而是为什么区别.
>
> 他的意思大概是: virtual一个方法的同时你就背负上一个责任, 一个"override该方法如何折腾也不会出错的责任", 而他认为大多数类
> 作者其实根本不想负担这个责任, 所以C#的方法就被设计成默认是不可覆写的, 这样在程序员去打virtual这几个关键字的时候就会注意到这种责
> 任. 如果是默认virtual, 很多懒惰的程序员就会任由virtual传递给继承者, 同时又不负担这种责任.
>
>

D 的作者 Walter 的想法是, 到底什么函数应该 virtual, 什么函数不要
virtual, 对于库的原始设计者来说, 要做这个决定是不容易的, 要做出正确的决
定, 需要非常高超的预见力.

这个正如：对于类的编写者来说，要预见这个类实现哪些接口也不是件容易的事情，因此，侵入式的接口应该永远被adapter式的非侵入接口替换。

[up duan]

>对比 std::string 、 std::vector 和 D
的动态数组，这三个东西里面，越靠后的越简单，越靠后的所做的事情越少，越靠后的越好用，越靠后的越透明。

不敢苟同。D的数组支持slice，这可是大多数主流语言都不支持的特性啊。

>关于C#增加各种语法糖的问题:
>1. 说到底, 对象不也就是语法糖吗?

>关于委托和匿名委托的问题:
>2. 这几乎就是函数式编程的全部了.

当然，这话没错，问题是：他只能在现在说，在别人折腾了n多年以后才拿过来然后说。为什么不能在别人没有发明以前就折腾出来呢？当然了，我承认Anders很牛，但毕竟只是跟随者而不是首创者，并且，C#【或者更深入的说：.net
framework】的Deleget的实现是很低效的。

关于OO继承以及相关的virtual，其实，C++的实现确实不好。给了类设计者太多的责任，太多的义务，导致扩展性很差。我想那本关于C++，Java，Eiffel比较的书【紫云英翻译的】讲的很透彻了。

[Eli]

不知道你说的低效是哪些? 如果是设计和实现, delegate即使作为语法糖, 在避免接口带来的限制和繁文缛节方面也是很方便的.

如果说执行效率, 肯定不能跟C函数指针比, 但绝对远胜接口, 这点Anders说过, 我也实测过. delegate对接口, 效率至少提高
20%~ 50%. 没有调查就没有发言权啊.... 要真说执行效率, C#的属性和Java的getter和setter效率比字段如何呢?

首创者与否也是相对的, 只要能站在前人肩膀上就是好的. Delphi算不算首创呢? 不照样被MS打败了, 我想Anders可能对追求所谓的首创
失去信心了吧, Java又有多少概念属于首创呢? 至于C++实现的好不好的问题, 我的感觉总是这样: 原则有了, 一切也就无所谓了, 陷阱总是
能避开的. 对于比较容易糊涂的程序员, 又经常涉及到比较复杂的用法的, 这样的人其实不多.

[Eli]

另外virtual的问题是我说的否定, Java否定了C++的什么, C#否定了Java的什么, 否定的是否有理(有理不代表全面正确)?

而delegate则是肯定, 虽然这个肯定来的有点晚, 而且还不那么地道, 但是对比观察者模式之类的技巧, 毕竟.NET在流行的大众文化内,
已经算是肯定的比较早且更有力度的了. 关于delegate与接口实现, 很多人单纯的认为delegate除了语法糖就没有更多意义, 或者紧盯
delegate实现方式相比纯FP的不彻底, 我觉得就有点过于求全责备了.

不过我不认同刘兄(pongba)对于接口的看法, 对灵活性的鼓励, 有时候更多的代表太过随意的代码诞生. 可能刘兄周围的程序员水平都够用吧.
我更多的认为应该同时保留两者, 让类作者可以通过付出更多的心力, 去保证类使用者被限制在一定的活动半径内, 限制和鼓励是两个重要的手段, 软件
构件的关键因素不仅仅只有语言提供多少能力, 还有如何保证人的行为的正确性吧

On Dec 17, 5:08 pm, "up duan" <fixo...@gmail.com> wrote:

[Eli]

对类的编写者来说, 我觉得无需考虑实现哪些接口吧? 这个类是被拿去用的, 至于怎样用这个类实现某个接口, 那不是类作者的事情. 是语言提供机
制, 还是使用者自己Wrapper, 我觉得更好的还是提供一个更外围但足够简单的手段就足够了. 类要求什么接口才是问题所在, 可要求的接口永远
可以通过对另一个类的包装得到满足. 所以说到底, 你重视的这个, 不过还是一个语法糖罢了.

接口更多的是对限制的一个显式的说明, 其目的是为了引起重视, 只是现在繁文缛节有点多, 甚至多的让人受不了, 但是否存在本质问题, 则是不见得
的事情了.

[pongba]

On Dec 17, 2007 7:02 PM, Eli <Eli...@gmail.com> wrote:

对类的编写者来说, 我觉得无需考虑实现哪些接口吧? 这个类是被拿去用的, 至于怎样用这个类实现某个接口, 那不是类作者的事情. 是语言提供机
制, 还是使用者自己Wrapper, 我觉得更好的还是提供一个更外围但足够简单的手段就足够了. 类要求什么接口才是问题所在, 可要求的接口永远
可以通过对另一个类的包装得到满足. 所以说到底, 你重视的这个, 不过还是一个语法糖罢了.

是的，是语法糖。

传统的侵入式接口，其实类的作者完全不必实现任何接口，留给使用者用adapter（适配器）模式来wrap即可。

这个办法在能力上没有任何下降，只有一点区别，即调用的时候是：

foo(new Adapter(obj));

而不是

foo(obj);

不过话说回来，这也不见得就是什么大事情。

有一个地方区别是大的。即，使用非侵入接口（C++09的concept），那么很多地方原先需要"implement IXXX"的就没有必要了，wrapper也不需要了（对应于auto concept）。

举个例子：

interface Resizable { void resize(int); }

List resizableWidgets;

有一个来自第三方的类MyWidget，要将MyWidget的对象myWidget插入resizableWidgets。
用interface的话，即便MyWidget类定义了resize函数，我们还是需要将它adapt到Resizable接口上，即：

class ResizableMyWidget implements Resizable
{
public ResizableMyWidget(ResizableMyWidget widget) { myWidget = widget; }
public void resize(int newSize) { myWidget.resize(newSize); }
private MyWidget myWidget;
}

resizableWidgets.put(new ResizableMyWidget(myWidget));

多出来的那个Adapter类是不是很没必要？

另一方面，如果Resizable是一个auto concept，那么任何定义了resize函数的类都自动符合这个"接口"。

[up duan]

其实有一个很好的度量标准，可以判定一个概念或者所谓的语法糖是否有效，那就是是否能减少代码量。

很多人觉得这个似乎无所谓，但实际上只要代码量能减少，生成效率就能提高。相比于不同语言百行代码的bug率来说，不同程序员百行代码的bug率差异更大。也就是说，bug数量几乎与语言没有什么关系，只与代码量相关。

>另外virtual的问题是我说的否定, Java否定了C++的什么, C#否定了Java的什么, 否定的是否有理(有理不代表全面正确)?

Java不再要求程序员指定那个函数是可以被override的，默认所有的函数都是，当然编译器会进行优化。这就是一种否认，对实现多态的机制暴露出来导致的复杂性的否认，显然，编译器可以看到哪个method被override，不需要我们告诉它哪个是virtual的。暴露出来实现机制永远都不能提升抽象层次，virtual如此，inline也如此，register也如此。能够优化的事情编译器比人更清楚。更何况C++给出的这些底层接口不能够直观的任意组合，这其实限制了表达能力。C#相对于Java来说，也是一个退步。

[Eli]

其实我当然愿意自动化, 只是觉得这样是不是太含糊了?

VBx好像是这么做的:

Dynamic Interface Resizable

使用的时候是这样:

Resizable resizableWidget = myWidget as Resizable

resizableWidgets.put(resizableWidget)

或者干脆:

resizableWidgets.put(myWidget as Resizable);

动态接口这种方式就无需实现一个Wrapper了, 但是还是在代码中保留了一些信息.

我不熟VB, 对VBx这种概念性的东西也不太了解还, 语法可能不对, 但大概是这个意思. 显式的声明一下myWidget是符合
Resizable的. 当然不排除最后VBx推出的时候, 不再要求显式的接口(现在的版本改成什么样了我也没了解). 但是我个人是赞成感觉逼迫使
用者显式的说出他的意图, 而不是由编译器给他处理. 这方面我说不出道道, 只是感觉太过于自动, 很多本来会明确表达的东西就丧失了. 我觉得只有
完全确定丧失的这些东西根本不必要的情况下, 才应该让它们消失. 但是对接口的实现带来的经验, 让我举双脚赞同, 能省的繁文缛节, 比如让我自己
去实现一个Wrapper, 还是省了吧... 现在.NET和Java都有很多自动生成符合某接口的代理的方式了, 当然语法糖会看起来更漂亮, 我
只是说, 语法糖的写法, 也许应该保留更多的信息, 而不是直接抹去.

关于那个virtual的问题也是, 全都是virtual, 并不代表不需要或者没有语法表达"这些方法你永远别动", 问题是普遍的来说, 一个类
到底是让继承者动的方法比例大, 还是不让继承者动的方法比例大? 我个人觉得这个才是客观衡量到底默认virtual, 还是相反的设定更合理的关键
问题. 如果默认virtual, 程序员再懒点, "安全第一"就成了空话了. Anders的访谈就说到, 其实virtual越多, 除了继承者
权限太大有可能瞎搞(这里头又有一个客观, 就是负责的程序员多, 还是不负责的程序员多?), 类作者的负担反而越大, 因为他不得不思考这个被
override了会产生什么情况, 那个被override了会产生什么情况, 这是两方面都有害处的. 对比Java或者D选择忽略由这方面视角
产生的问题, 至于这些害处作为理由是否足够, 先撇下不谈, 因为各有各的看法, 但是至少它们也是一个合理的视角.

所以我说, 否定归否定, 但一个否定是进步还是退步, 可不是那么容易衡量的. 这个话题不是机器能做什么, 而是我们要像别人表达什么, 从别人那
里接受些什么, 同时如何限制别人和被别人限制. 不是有人号称软件即人件吗? 我想对于Anders这样身边有着全球最大的软件团伙(都不是团
队), 且程序员素质残差不齐(这个我想大家都同意吧)的情况下, 他这个选择到底是对是错, 我只是个人倾向于相信他, 因为MS在程序员身上的吃的
亏, 一定比任何一家公司都多. 当然这种不信任程序员的态度和带来的限制, 又是我作为一个程序员讨厌的了.

[Eli]

其实关于virtual这个问题, 我的判断思路, 是个外沿法. 即我个人不认为自己能很好的判断是否合适, 我赞同与否, 是看这几个条件:

1. Anders有没有根据经验和样本作出判断的能力. (这个其实又有其它的判断做基础, 总之, 最后必须落实在事实支撑之上)
2. Anders获取经验和样本的渠道是否比别人好.

关于2, 我个人认为以身边的样本作为依据, 从有效性, 距离等方面, 肯定比社区反馈靠谱; 同时, Anders身边的样本也足够大, 如果一单
一组织而论, 也许是世界上最大的? 这样, 咱们碰见的各种情况, Anders得到第一手资料的可能性应该比某些其它设计者更大, 同时咱们没碰见
的情况, 在MS这样的程序员大杂烩里可能照样会碰到.

比如大家都说Google在软件上开始挑战微软, MS有一个搞测试的大牛, 被Google挖走了, 到Google工作了一年, 发现根本没法进行
良好的测试实践, 因为Google根本没有能进行这种实践的环境, 换句话说就是软件开发的整体水平, 太嫩了. 如果你说Google的开发方式不
需要良好的(或者换一个中性的说法, 类似于MS那样的)测试体系, 那Google挖MS墙角干嘛? MS做的东西, 很多很烂, 正是这种人多东西
烂的情况, 才让我相信, MS里那些有权力对各种选择做设定的, 一定会更加谨慎.... 存在即是有原因的, 我比较的不是谁的原因听起来可靠,
而是谁的原因更可能包含更多的事实去支撑.

当然, 我这样的做法去衡量或赞同某事, 非常苍白, 但我觉得总比我自己去调研(何况我根本没门路进行这种调研)舒服的多, 也省劲的多.

[pongba]

On Dec 18, 2007 3:26 AM, Eli <Eli...@gmail.com> wrote:

其实关于virtual这个问题, 我的判断思路, 是个外沿法. 即我个人不认为自己能很好的判断是否合适, 我赞同与否, 是看这几个条件:

1. Anders有没有根据经验和样本作出判断的能力. (这个其实又有其它的判断做基础, 总之, 最后必须落实在事实支撑之上)
2. Anders获取经验和样本的渠道是否比别人好.

关于2, 我个人认为以身边的样本作为依据, 从有效性, 距离等方面, 肯定比社区反馈靠谱; 同时, Anders身边的样本也足够大, 如果一单
一组织而论, 也许是世界上最大的? 这样, 咱们碰见的各种情况, Anders得到第一手资料的可能性应该比某些其它设计者更大, 同时咱们没碰见
的情况, 在MS这样的程序员大杂烩里可能照样会碰到.

比如大家都说Google在软件上开始挑战微软, MS有一个搞测试的大牛, 被Google挖走了, 到Google工作了一年, 发现根本没法进行
良好的测试实践, 因为Google根本没有能进行这种实践的环境, 换句话说就是软件开发的整体水平, 太嫩了. 如果你说Google的开发方式不
需要良好的(或者换一个中性的说法, 类似于MS那样的)测试体系, 那Google挖MS墙角干嘛? MS做的东西, 很多很烂, 正是这种人多东西
烂的情况, 才让我相信, MS里那些有权力对各种选择做设定的, 一定会更加谨慎.... 存在即是有原因的, 我比较的不是谁的原因听起来可靠,
而是谁的原因更可能包含更多的事实去支撑.

有意思:) ，这个大牛是谁？

[up duan]

重用的基础就是没有限制。如果我们限制了某些东西，我们就潜在的失去了某些可能的重用。

我相信，社会进步的动力是对最高的投入产出比的追求。而要想达到草最高的投入产出比，对于软件开发来说就是尽可能的重用。你或许觉得你能有把握的预测未来，你或许觉得你的控制比使用者的瞎用更高明，可是这不足以成为我们通过某种技术限制使用者的理由。Ruby之所以流行，就是因为继承了Smalltalk的无所限制的能力，而不是继承了C#的给出明确的限制手段的能力。

另外，给出限制手段【而实际上，限制手段很大程度上是一些不稳定的技术，换一个不同的抽象模型限制手段就完全没有价值了】，实际上限制了语言【或者编译器】的自由发展。C++在这方面的经验够丰富的了。

[Eli]

名字是个谜...， 只是我这人比较八卦(你也喜欢八卦？)，也可能再不止一个地方见过这事，就给记住了...， 想搜不知道什么关键词，只找到这么一
篇， 里面有一段提到这个事：

http://blog.joycode.com/mvm/archive/2007/10/22.aspx

嗯，印象里跟我在其它地方看见/听说的应该说的是一件事，版本不同不过差不多...，不过按照此信说法，这人最后也没回微软？

I worked with a Test Architect here at MS a few years ago who is very
highly regarded in the software testing industry ... very much top of
his game. He left MS about 2.5 years ago for Google to help them
create a testing discipline and launch quality assurance practices.
He just got in touch with me this morning and has left Google (Looking
for another job in the area, but not necessarily MS.) I asked him why
he left Google, and he said: "The short version of the Google story is
that they don't have the people, the background, or the infrastructure
for advanced testing, so my work didn't fare well there."

我觉得像这样被诱惑到Google魔掌里反而无事可做的工程师/科学家， 应该不在少数吧。

[Eli]

你说的有一定道理, 不过就我来说, 我可不敢把我的方法全都标成virtual的然后让有些程序员使用, 即使我的代码跟着我的类一起走, 你就真的
这么信任那些水平不如你的程序员? 再说了, C++/C#又不是说根本不能完全开放, 大不了多写一串virtual就是, 所以我觉得你这种说法有
点极端, 上升的高度也有点过. 我个人的体会是, 我做一个设计如果是给别人用的, 如何避免错误的使用一直是一个重头, 总不能全靠文档和源文件
吧...

还有, .NET的放开限制是渐进的, 但也是快速的, 这恐怕和C++要变一变就要等个好几年不同. 比如我上面说过, 在.NET上面只要你愿
意, 你可以通过各种手段达到突破限制的目的, 这些突破限制的手段同时也是被支持的, 而不能理解为纯粹的Tricks. 同时, 象VBx,
IronPython, 这些东西的Roadmap上, 可以看到从手段到语言支持的路也在继续. 我的感觉是, 因为人变了, 所以语言也要变. 否
则为什么Smalltalk没有流行起来呢? M$在这方面是最中庸的, 在开放的同时, 留下一个适当的记号(记号有强弱之别, 越强的记号就越靠
近限制, 但逐渐会像非限制甚至消除冗余的记号转变, 同时是不是冗余, 也是由程序员群体的整体水平和思路的变化而定的), 比把这种信息损失了
强. 当然, 将来会以健康的思维设计(东西)和使用(语言)的人越来越多, 那么可能一些信息也不必再显式的出现在代码里.

另外, 即使RoR更适合网站应用(还不说其它领域), 不过Ruby真象宣传的那么流行吗？ 至于像Java/C#这样的厂商出品的东西, 语言和其
支撑平台的发展还是比较自由的, 尤其是.NET, 已经一群一群的人大呼受不了了...

[Eli]

没编辑真是费劲...

感觉老兄你是真有信仰, 我可能是太保守了..., 即使限制带来的苦头也吃了不少, 嗯, 也许应该更激进一些.

[王磊]

上午没事干了，下午开忘年会。

 

所以仔细看了一遍。觉得写了很多，也很长 。从内容上应该很适合我这类C++中级初学者。

 

好的地方我就不说了，那样没什么意义。你的水平有目共睹哦。

谈谈自己看后的感觉吧。

首先没排版分段肯定是让我觉得too long to...

感觉思想不够明确，你说了太多的内容，以及你自己的感想，建议也提了太多，

虽然条理上还算清晰，可是全文读完就觉得有些空了，没突出你想说明的东西。

建议写成一系列文章，分成几个内容去分别阐述。beta版很不错了，期待完成版。还有终结版，以及改良版，和十年纪念版哈哈。。。。

 

pongba老大，我说的都是个人实话，无责任hoho

 

在07-12-18，Eli <Eli...@gmail.com> 写道：

[pongba]

On Dec 21, 2007 10:30 AM, 王磊 <wangle...@gmail.com> wrote:

上午没事干了，下午开忘年会。

 

所以仔细看了一遍。觉得写了很多，也很长 。从内容上应该很适合我这类C++中级初学者。

 

好的地方我就不说了，那样没什么意义。你的水平有目共睹哦。

谈谈自己看后的感觉吧。

首先没排版分段肯定是让我觉得too long to...

感觉思想不够明确，你说了太多的内容，以及你自己的感想，建议也提了太多，

虽然条理上还算清晰，可是全文读完就觉得有些空了，没突出你想说明的东西。

建议写成一系列文章，分成几个内容去分别阐述。beta版很不错了，期待完成版。还有终结版，以及改良版，和十年纪念版哈哈。。。。

 

pongba老大，我说的都是个人实话，无责任hoho

呵呵，哪里，我巴不得被拍砖呢。排版的问题是因为我用Live Writer发的，似乎排版功能不大强。说实话我在表达方面还是很注意的，不知道为什么你觉得我没有表达出想要表达的意思。也许是阐述（解释）的地方太多导致？我觉得阐述都是必要的啊（也许靠前部分的一些阐述可以去掉）。至于突出想说明的东西，我特意用了"事实""建议"这两个加粗的东东。所以，对于你的这个感觉我不太明白。也许你可以给出更具体的建议？:-) 期待。

[SpitFire]

可能是你的建议跟事实交错的方式会让人读起来有点乱，是不是改进一下结构

在07-12-21，pongba <pon...@gmail.com> 写道：

--
SpitFire

[pongba]

On Dec 21, 2007 10:43 AM, SpitFire <spit...@gmail.com> wrote:

可能是你的建议跟事实交错的方式会让人读起来有点乱，是不是改进一下结构

怎么改？有什么建议么？
我当时的想法是"建议"和"事实"是随着上文自然的逻辑延伸，所以...自然是夹在上下文中了。

[王磊]

首先格式分段成几个部分来比较好吧？

另外建议是不是太多了？或者说分太多部分了。

读起来感觉每部分说的都还很好，读完之后感觉联系不起来。

当然只是个人感觉，也许调整一下结构比较好？

或者干脆就分成2篇文字。

 

在07-12-21，pongba <pon...@gmail.com> 写道：

[pongba]

On Dec 21, 2007 10:51 AM, 王磊 <wangle...@gmail.com> wrote:

首先格式分段成几个部分来比较好吧？

啊，其实我是分了段的。该死的Blog把大字体缩小了。不过，是的，分段的方式需要调整。
 

读起来感觉每部分说的都还很好，读完之后感觉联系不起来。

那就Beta2对结构做一个调整吧:)

[王磊]

完善一下可以在程序员上发表一下也不错。

那样细节就需要准确一下，用词也要文一些了哈哈。

还有前期分析的太多了，觉得可以简单扼要。毕竟重点在后面。避免头重脚轻。

0.01版很不错了，都怪blog那格式，老恐怖了。

 

c++学习被说了太多了。读书是一个好办法，不过我也主张，实践之与前，而后读书。

 

不到实际的时候那些特性概念都是虚无的怪物而已。

推荐的书目，我感觉 c++ primer也很好，至于原因么，那里有很多小的有趣的思考。需要细心领会。而且对于c转c++很适合。

至于大部头的其他真的看的头晕。至于代码大全，我只能说，好书，书架一组必备。 如果仅仅学习c++，也许不一定要先看。

 

在07-12-21，pongba <pon...@gmail.com> 写道：

[pongba]

On Dec 21, 2007 11:09 AM, 王磊 <wangle...@gmail.com> wrote:

完善一下可以在程序员上发表一下也不错。

那样细节就需要准确一下，用词也要文一些了哈哈。

还有前期分析的太多了，觉得可以简单扼要。毕竟重点在后面。避免头重脚轻。

恩。Advice Taken :)
 

 推荐的书目，我感觉 c++ primer也很好，至于原因么，那里有很多小的有趣的思考。需要细心领会。而且对于c转c++很适合。

至于大部头的其他真的看的头晕。

ProgrammingRuby的语言部分也有500页。跟TC++PL一样。
底层知识的书最少需要一本，而《深入理解计算机系统》我觉得最好了。
至于其它大部头么...我没有建议预先看完啊:)

C++ Primer不建议；更多站在语言特性的角度来介绍语言。作为reference也许可以。作为入门读物我觉得是误导。

[up duan]

《编码的奥秘》作为入门书我觉得不错。

[pongba]

On Dec 21, 2007 11:40 AM, up duan <fix...@gmail.com> wrote:

《编码的奥秘》作为入门书我觉得不错。

《编码的奥秘》深刻有余，但细节不足啊:-) 对于程序员需要掌握的底层知识，不仅是知道与非门和逻辑电路设计的基本原理即可的:)

[up duan]

我倒是觉得，让大家从本质上理解code是什么。编码是对信息进行表达的过程，编码的奥秘也不仅仅是将数电，更确切的说，编码的奥秘跟数电没有任何关系，只是偶尔用它作为编码的一个实例来表达编码是什么而已。

对数据【或者信息】进行表达的手法就叫做code，就叫做编码。它是一种最最基本的抽象机制，使得我们可以用0xCCED表示'好'这个意义，使得我们可以用0x3D表示'+'这个动作，……没有这个东西，很难理解所谓的"计算机语言"，很难理解CPU【运算单元，寄存器】，很难理解IDL和WSDL，很难理解XML为什么，很难理解print
x + y为什么……

[roc lee]

在07-12-12，pongba <pon...@gmail.com> 写道：

On Dec 12, 2007 1:46 PM, Atry <pop....@gmail.com> wrote:

Linus 那个事件以后的很多文章，属于瞎子摸象，各自摸到一部分。我和云风是两个不同的瞎子，摸到的东西不同，结论也不同。

同样从"心智包袱"出发，云风和 Linus 认为 C++
引诱程序员去做过多的抽象。我则认为是程序员引诱自己去做过多的抽象。所以我得出的结论是，只要放下包袱， C++ 照样可以用嘛；云风得出的结论是
C++ 不能用。

总算触摸到你的观点了，不容易啊～:-)

话说回来，放下包袱，一句话，做起来谈何容易啊，我blog上有人建议我应该在书单里面加上《设计模式》、《敏捷软件开发：原则，模式与实践》两本。就拿设计模式来说吧，这本书太容易误导人了。当我们手头有一堆fancy的工具的时候，真的很难从心理上摆脱用一用他们的倾向，上次我记得7猫转的douban上的一个讨论里面也有人提到说是C++的特性放着不用觉得暴殄天物，典型心态啊。

我甚至觉得OO都不应该过早介入。等到实践当中体会到ADT的不足时再去看或许更好。我们的学习之路往往是一溜小跑把一堆语言特性装脑子里面，根本不知所以然，不知道动机和适用场景，所以，知识有了，能力没有。思考也没有。非得经过了一次次的痛苦挫折才会发现一些道理。而到那个时候，有人就会走得更远，走向另一个极端，认为要简约到...我不知道...过程式编程。我认为这种转变乃是心理所致，并非客观的。

此外，我不认为非得经历痛苦挫折才会发现设计的真谛。而是这些书都讲解得不够深刻。所谓不够深刻，比如说设计模式吧，里面就有大把的模式根本就是在C++语言的静态性质的限制之下衍生出来的workarounds，如果拿到ruby里面就消失了。但关键是书中并没有把这个"背景"讲出来，背景被忽略了，也许作者本人也跟所有人一样，并没有意识到这个背景吧，虽然这个背景其实是适用场合的一个重要部分。结果就是大家都只看到了一个形式，一个花架子，不知道本质是什么。

我的感觉是，读了《设计模式》和《敏捷软件开发》这类书，最大的可能性（绝大多数人）是离好的程序员又远了一步。

 

我学C++看的第一本书是《C++高效对象编程》，书的内容不错（虽然印刷质量低劣，

翻译和校对的更加垃圾）。加上后来看到的《敏捷软件开发》，至少多走了两年歪路。

 

培训和交流很重要，单单自己看书的时候眼界太狭小，太容易走入误区。

没有足够的动手的机会更会死的惨，呵呵。

[王磊]

在07-12-21，pongba <pon...@gmail.com> 写道：

On Dec 21, 2007 11:09 AM, 王磊 <wangle...@gmail.com> wrote:

完善一下可以在程序员上发表一下也不错。

那样细节就需要准确一下，用词也要文一些了哈哈。

还有前期分析的太多了，觉得可以简单扼要。毕竟重点在后面。避免头重脚轻。

恩。Advice Taken :)
 

 推荐的书目，我感觉 c++ primer也很好，至于原因么，那里有很多小的有趣的思考。需要细心领会。而且对于c转c++很适合。

至于大部头的其他真的看的头晕。

ProgrammingRuby的语言部分也有500页。跟TC++PL一样。
底层知识的书最少需要一本，而《深入理解计算机系统》我觉得最好了。
至于其它大部头么...我没有建议预先看完啊:)

C++ Primer不建议；更多站在语言特性的角度来介绍语言。作为reference也许可以。作为入门读物我觉得是误导。

 

 

确实，我想说的也是，在基础书看完之后，去看一下这本会重新认识C++。尤其一些细节的东西，很适合拿来当参考，经常记不住的东西里面都能查到。