并发讨论：C++已经死了吗？（C++的明天会怎样？）

[pongba]

以下讨论正发生在云风的mailist上，摘抄到目前为止的发言，大家说说：

Oscar.Ken:
浪费我20%的生命在等待编译上*;)，*还有5%是在string的各行其道下。

孟岩:
就用最朴素的那部分C++就可以了。C+ ADT + 一点点多态 + 异常 + 一点点STL。我想
不出有什么是做不到的。

C++中不要谈面向对象，除非你愿意用boost::share_ptr。

COM的想法还是不错的，就是太复杂，有必要自己实现一个简化版。

如果string的内部实现影响了你的工作，那表明你在写系统级程序，在这个级别上，不
要用string比较好，随便一个操作你都不知道会发生什么，不符合系统级开发的要求。

kenneth chia:
我在生活中从来没有发现一个是C++高手，忽悠的我看到好多。。。

Shuo Chen:
我觉得异常都可以不用，程序出错就死掉好了。

孟岩:
ANTLR本身是用Java写的语言识别器，但是它生成的C/C++代码运行速度比对应的Java版
快2倍，内存耗用只有1/3。

所以在单机系统里要求告诉执行的任务，比如图形图像处理，实时数据处理，很长时间
里都会继续使用C/C++。

但是用C++绝对不要去求奇妙，模仿其他语言的什么高深奇妙的功能，这绝对是个误
区。

Qutr:
其实回归到C语言才是最好的！

邓云:
我做的是视频编码，这个方向是明显的计算密集性工作，实时性压倒一切。除了汇编语言外，C/C++是唯一能接受的高级语言。而且C/C++对系统资源的使用，如内存的使用，有非常明显的可控制性。这在对资源要求很严格的情况下C/C++也是优先选择。从这个角度看，视频压缩和图形图像处理，实时系统处理领域里，短期内还不会有能代替C/C++的语言。
另外，说C/C++的编译时间问题，可以想到的是相对运行时间，编码时间的开销换来的运动效率绝对是值得的。
当然，要跨平台，要做WEB，那是另一回事了。C/C++也不是为WEB设计的。

Will Zhang:
其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。

事实上，有许多"高深"的功能C++已经使用了。
比如垃圾回收。你用C++开发大型项目的时候，经常会想到要做一个垃圾回收。

我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
然后想到，或许这种东西的使用应该更普遍，然后就开发了另一种语言。：）这个随便说说。

Siney:
在07-11-23，Will Zhang < lala.wi...@gmail.com> 写道：
>
> 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
通过ecx传递好像也只是ms的编译器的做法，而非标准规定，gcc我不清楚，不过即使是想通过寄存器来传递，c也可以申明register吧。

最后，我觉得这个问题应该这样来提问：

1. 目前C++的应用领域是哪些（要精确）。
2. 目前C++所占领的领域，是因为非C++不可，还是因为政治或历史原因？（逐个分析）
3. 这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing...）），为什么。
4. C++独一无二（不可取代）的优势到底是什么？

其实，以上的问题内可以把C++换成任意一门其他语言。

最后说说我的观点：以往，人们普遍认为C++的独一无二的优势是效率。而C为什么不更好呢？C同样效率且语言模型更简单。但语言模型更简单并不代表用该语言编程就更简单。OB/OO/GP是已经被实践证明的有效范式（虽然OO的定义似乎从来就没有明确过，但OB至少还是可以谈论的），如果没有first-class支持，而又要用到的话，就很难搞了。也就是说，当"鱼（first-class的范式支持）我所欲也；熊掌（效率）亦我所欲也"的时候，也就只剩下C++这个选手了。为此用C++编程的人宁可仍受各种各样的非本质复杂性，因为与刚才那两个需求相比，这些非本质复杂性至少是可以克服的。

以上这个论点建立在一个前提之上，及C++的某些特点导致了它的高效。什么特点？接近机器的抽象模型。（OO的实现方式，GP的实现方式）这使得语言在实现高级编程范式的时候做到了零惩罚（中间层几乎被削减到无）。这个零惩罚当然是有代价的（昂贵的代价），比如GP在C++中的实现就并非是"运行期+非绑定"的（ruby的是）。

而这个前提又建立在另一个前提之上，也就是：传统的程序是通过减少抽象惩罚来最大化执行效率的。这才使得C++这种语言实现抽象惩罚最小的语言在一些领域成为独一无二的选择。

那么，我们来看最后这一个前提到了并发时代还能满足吗？

显然，通过减少抽象惩罚而获得的效率提升跟通过提高并发程度获得的效率提升一比就微不足道了。

以上论点的前提是：该程序必须要能够并行化到一定程度。如果本质上决定了必须要串行执行或者并行化带来的收效甚微，那就白搭了。

于是，要证明C++的优势在并发时代会消失。我们只需证明，目前C++应用领域中的主体软件，是可以通过并行化来提到一个非平凡的效率的，这个非平凡的效率提升将使得通过减少抽象惩罚来获得的效率提升变得微不足道。

例如，传统上，图像处理和游戏被认为是C++的经典领域，但考虑到并发，这个领域还能保留吗？这两个领域可都是能够高度并发的。

我觉得这个结论基本就不需要证明了。

好，如果这个结论成立。那么随之就带来了一个重要推论：

原来C++是为了减少抽象惩罚从而在语言的抽象模型上做了很大的折中（比如前面提到的GP的实现），本来这个折中是个优点，因为它换来了效率。而现在突然换不到效率了，那就立即变成了大大的缺点。如果同样都能获得效率，难道不是用更自然的ruby更让人舒服吗？

回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的 决策是：通过实现零惩罚的抽象（OO、GP），来达到效率+抽象兼得的目的。而这个决策，在当前的背景下，由一个优点，变成了一个缺点，因为它折中了抽 象。如果我们不再需要通过零惩罚的抽象类来获得效率，"零惩罚的抽象"所带来的结果就只是不友好的编程范式。

有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。

剩下的问题是：

那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）

也许是有的，我可以列出两点：

1. 直接操纵硬件。
2. 静态类型系统。

第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。

第二点的优势目前我也不特别肯定。静态类型系统，众所周知，有助于尽早发现问题。动态语言为了"动"起来，其实也折中了静态类型系统的优点，导致了一些批评（比如ruby的ducktyping需要concept）。但我的看法是，ruby如果能够加上一定的静态类新成分，再加上程序自动验证领域的进展，最终会弥补这个缺陷。但这方面我也不是很了解，所以留给了解的人评说。

总之我得出的结论就是，并发的普及将导致C++的领域最终缩减到需要直接操纵硬件的领域，并且在这个领域还有可能被其他语言取代（因为通过减少抽象惩罚来获得效率不再必要，使得为了减少抽象惩罚而折中的语言模型成为一个极大的弱点）。这里只有一个漏洞，就是在这些需要直接操纵硬件的底层领域，又有多少是能够通过并发来获得效率的，如果不能并行化，那还是得借助于C++的零惩罚的语言模型。但无论如何，这样的领域怎么也不会太大了。

换句话说，一段时间之后，非C++不可的领域是什么呢？这个领域必须有以下特点：

1. 需要直接操纵硬件（C、D、C++）。
2. 需要效率。（C、D、C++）。
3. 无法通过并行化来获得想得到的效率，而只能依赖于语言抽象的零惩罚。（C、C++）
4. 需要用到方便的库。（C++）

满足这些条件的应用，有哪些呢？驱动开发，略高于驱动层面上的运行时开发，还有吗？

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

[hayate]

以后的掌上智能设备也许是条路 不光是驱动 上面应该有许多对性能要求高的应用 Java做不到 C又太轮子 或许CPP可以填补

> 回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的决策是：通过实现零惩罚的抽象（OO、GP），来达到效率+抽象兼得的目的。而这个决策，在当前的背景下，由一个优点，变成了一个缺点，因为它折中了抽象。如果我们不再需要通过零惩罚的抽象类来获得效率，"零惩罚的抽象"所带来的结果就只是不友好的编程范式。

[hayate]

还有 一些大型的科学计算 高性能服务器 它们都有抽象的需要

[pongba]

On Nov 26, 2007 10:14 PM, hayate <haya...@gmail.com> wrote:

以后的掌上智能设备也许是条路 不光是驱动 上面应该有许多对性能要求高的应用 Java做不到 C又太轮子 或许CPP可以填补

根据我的看法，如果这个性能可以通过并发获得的话，就没有必要用C++了。

[pongba]

On Nov 26, 2007 10:16 PM, hayate <haya...@gmail.com> wrote:

还有 一些大型的科学计算 高性能服务器 它们都有抽象的需要

那些更是并发的天下。在并发获得的性能提升面前，以往C++的优势（零惩罚的语言抽象模型）还存在吗？如果不存在，那为什么要忍受C++的二流抽象呢？为什么不用一流抽象并且支持并发的语言呢？

[hayate]

嗯 这个不好说。
如果真像你所说 可以接受有代价的抽象模型 换得更好的性能或者别的 那么不采用c++是自然的
我也不知道这样的应用是什么？应用广不广？

[Googol Lee]

在并发面前，还是要看0x的工作进展如何吧。如果0x标准广泛接受，那么整个社区都会动起来，包括广泛的跨平台库（不用再考虑pthread和CreateThread的区别），庞大的使用经验（Effective
Thread？）。像erlang，shhema这种天生并行语言确实是更有优势，但是，资源总是稀缺的，cpu内存资源也一样。而且，这种动态语言在内存管理上应该不占优势吧，虽然内存越来越便宜，但随便就用个1、2g的应用也越来越多了。

其实，ruby，shema，python在使用的时候一样有自己的经验技巧，尤其是在要求性能的时候。比如python里range和rangex的效率就有明显差异。C++因为用的人太多，而且经常用在强性能的地方，觉得这个问题被夸大了。

至于C，我觉得C现在相对于C++的最大优势就是编译器实现简单，所以各个平台（包括众多的嵌入式，比如国产青云51系列单片机）都有C编译器，但不一定有C++编译器（那种C++
to C的就别提了，没见过有开源的，更没见人用过）。至于编程思想，C缺少了C++构造和析构的自动机制，反而用起来很别扭，还未必比C++效率高，比如那套glib库……

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

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

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

[pongba]

On Nov 26, 2007 11:00 PM, Googol Lee <goog...@gmail.com> wrote:

在并发面前，还是要看0x的工作进展如何吧。如果0x标准广泛接受，那么整个社区都会动起来，包括广泛的跨平台库（不用再考虑pthread和CreateThread的区别），庞大的使用经验（Effective
Thread？）。像erlang，shhema这种天生并行语言确实是更有优势，但是，资源总是稀缺的，cpu内存资源也一样。而且，这种动态语言在内存管理上应该不占优势吧，虽然内存越来越便宜，但随便就用个1、2g的应用也越来越多了。

我的意思是,一旦效率的来源是并发.那么C++的零惩罚抽象模型就不再是优点,而是弱点.因为为了这个零抽象牺牲了抽象模型的能力(如果不是为了效率,template和class inheritance)其实是可以统一起来的,"模板"其实是可以二进制复用的). 以往这个牺牲是值得的,因为他带来了高效率,而且也只有这个办法能够带来高效率.如今可以通过并发获得更高的效率,那么这招就不需要了.于是这招的影响就只有负面的(受限的抽象模型)了.

其实，ruby，shema，python在使用的时候一样有自己的经验技巧，尤其是在要求性能的时候。比如python里range和rangex的效率就有明显差异。C++因为用的人太多，而且经常用在强性能的地方，觉得这个问题被夸大了。

什么问题被夸大了?

至于C，我觉得C现在相对于C++的最大优势就是编译器实现简单，所以各个平台（包括众多的嵌入式，比如国产青云51系列单片机）都有C编译器，但不一定有C++编译器（那种C++
to C的就别提了，没见过有开源的，更没见人用过）。至于编程思想，C缺少了C++构造和析构的自动机制，反而用起来很别扭，还未必比C++效率高，比如那套glib库……

我不把C和C++比,我把C++跟一门支持并发并且支持更自然的抽象机制的语言比.

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

>
>
> On Nov 26, 2007 10:16 PM, hayate < haya...@gmail.com> wrote:
> > 还有 一些大型的科学计算 高性能服务器 它们都有抽象的需要
> >
> >
> >
> >
> >
> 那些更是并发的天下。在并发获得的性能提升面前，以往C++的优势（零惩罚的语言抽象模型）还存在吗？如果不存在，那为什么要忍受C++的二流抽象呢？为什么不用一流抽象并且支持并发的语言呢？
>
>
> --
>
> 刘未鹏(pongba)|C++的罗浮宫
> http://blog.csdn.net/pongba
> TopLanguage
> http://groups.google.com/group/pongba
>  >
>

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

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

[red...@gmail.com]

驱动开发主要还是 C 的, C++ 开发驱动, 主要是给那些不是特别专业开发驱动的
厂商, 使用第三方 easy library 开发的时候, 才用 C++.

[Kimi Zhang]

C++0x绝对是对语言本身的一针强心剂。我很期待。

就应用领域而言，我所知道的有计算机图形学，部分嵌入式，部分小型操作系统，虚拟机，部分桌面软件。
对于程序员，选择语言的权力往往不多，都是跟着项目走。但是，话又说回来，那种犹犹豫豫怕学了C++而又后悔的人恐怕将一事无成。说白了我觉得还是设计
问题，是人自身的问题，而不是语言：设计模式，低藕和，KISS等。
很多人说C++的复杂性扰乱了设计，我还是不敢苟同的。充其量说影响了设计，那些人可以想想：设计模式本身就是受制于语言的。别的语言就没有扰乱了设计
了吗？
我见过太多的由C++转Java、C#的人（多半是因为觉得C++没前途），他们依然用"他们认为的强大的语言"写着蹩脚的，丑陋的代码，而以为自己还
在天堂中呢！

任何语言都要死，而且C++很可能是我们见证他的死亡，放平心态，见证历史！

[寒光]

我觉得大家讨论了问题的一个方面：
即C++能做到的，别的语言也能做到，为什么要用C++；
但问题的另一面呢，别的语言能做到的，C++也能做到，我为什么要换！

我觉得大家对C++的期望太高了，拔高到了一种近乎仰视的地步

[buhongbo]

我有一个很幼稚的问题：为什么一定要C++语言本身来支持并发呢？ 都知道，
unix系统为支持并发提供了许多基本的机制。让操作系统自己提供并发，
然后我们运用C++语言来把这种支持做到我们的应用中，难道不好吗？

我见过一个在Sun V240上运行一个软交换系统平台，它代码90%以上使用的是C++，
它整个系统的抽象程度很好，效率也很高（当然这少不了强劲服务器硬件本身的支撑），
特别是它提供了自己的内存管理方式，对效率的提升还是很显而易见的。
它其中运用了适度的继承，少量的模板（提供一些常见组件，比如单根类模板，链表模板等）。
当我们需要向其中增加新的特性时，开发非常方便，几乎不需要对架构做任何改动。只需要增加自己
所需要的组件就可以了。 我个人认为在大型的通信系统软件中，使用C++是非常合适的：
能提供适度抽象，能提供效率，程序相对容易维护。如果用C的话，我猜还是要更难于维护一些
（我还没有见过完全用C开发的大型通信系统软件，听说华为是用C开发的）。

我的观点是："并发"不需要做到C++语言本身中,因此C++也不会死。
------------------
buhongbo
2007-11-27

-------------------------------------------------------------
发件人：pongba
发送日期：2007-11-26 22:01:50
收件人：pon...@googlegroups.com
抄送：
主题：[TopLanguage] 并发讨论：C++已经死了吗？（C++的明天会怎样？）

以下讨论正发生在云风 <http://www.codingnow.com>的mailist上，摘抄到目前为止的发言，大家说说：

*Oscar.Ken:*
浪费我20%的生命在等待编译上*;)，*还有5%是在string的各行其道下。

*孟岩:*

就用最朴素的那部分C++就可以了。C+ ADT + 一点点多态 + 异常 + 一点点STL。我想
不出有什么是做不到的。

C++中不要谈面向对象，除非你愿意用boost::share_ptr。

COM的想法还是不错的，就是太复杂，有必要自己实现一个简化版。

如果string的内部实现影响了你的工作，那表明你在写系统级程序，在这个级别上，不
要用string比较好，随便一个操作你都不知道会发生什么，不符合系统级开发的要求。

*kenneth chia:*
我在生活中从来没有发现一个是C++高手，忽悠的我看到好多。。。

*Shuo Chen:*
我觉得异常都可以不用，程序出错就死掉好了。

*孟岩:*

ANTLR本身是用Java写的语言识别器，但是它生成的C/C++代码运行速度比对应的Java版
快2倍，内存耗用只有1/3。

所以在单机系统里要求告诉执行的任务，比如图形图像处理，实时数据处理，很长时间
里都会继续使用C/C++。

但是用C++绝对不要去求奇妙，模仿其他语言的什么高深奇妙的功能，这绝对是个误
区。

*Qutr:*
其实回归到C语言才是最好的！

*邓云:*

我做的是视频编码，这个方向是明显的计算密集性工作，实时性压倒一切。除了汇编语言外，C/C++是唯一能接受的高级语言。而且C/C++对系统资源的使用，如内存的使用，有非常明显的可控制性。这在对资源要求很严格的情况下C/C++也是优先选择。从这个角度看，视频压缩和图形图像处理，实时系统处理领域里，短期内还不会有能代替C/C++的语言。
另外，说C/C++的编译时间问题，可以想到的是相对运行时间，编码时间的开销换来的运动效率绝对是值得的。
当然，要跨平台，要做WEB，那是另一回事了。C/C++也不是为WEB设计的。

*Will Zhang:*

其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。

事实上，有许多"高深"的功能C++已经使用了。
比如垃圾回收。你用C++开发大型项目的时候，经常会想到要做一个垃圾回收。

我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
然后想到，或许这种东西的使用应该更普遍，然后就开发了另一种语言。：）这个随便说说。

*Siney:
*在07-11-23，Will Zhang <lala.wi...@gmail.com> 写道：

>
> 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
通过ecx传递好像也只是ms的编译器的做法，而非标准规定，gcc我不清楚，不过即使是想通过寄存器来传递，c也可以申明register吧。

*最后，我觉得这个问题应该这样来提问：

1. 目前C++的应用领域是哪些（要精确）。
2. 目前C++所占领的领域，是因为非C++不可，还是因为政治或历史原因？（逐个分析）
3.
这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing...）），为什么。
4. C++独一无二（不可取代）的优势到底是什么？

其实，以上的问题内可以把C++换成任意一门其他语言。

*

[pongba]

On Nov 27, 2007 9:04 AM, buhongbo <buho...@gmail.com> wrote:

我有一个很幼稚的问题：为什么一定要C++语言本身来支持并发呢？ 都知道，
unix系统为支持并发提供了许多基本的机制。让操作系统自己提供并发，
然后我们运用C++语言来把这种支持做到我们的应用中，难道不好吗？

答案很简单.
1. 为了可移植的代码.
2. 语言必须本身支持基本的并发内存模型,将并发完全建造在库中已经被证明是行不通的.(参考我的一篇blog)

[R.C Wu]

用TM来实现并行的话，C/C++还是很有优势的……

回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的决策是：通过实现零惩罚的抽象（OO、GP），来达到效率+抽象兼得的目的。而这个决策，在当前的背景下，由一个优点，变成了一个缺点，因为它折中了抽象。如果我们不再需要通过零惩罚的抽象类来获得效率，"零惩罚的抽象"所带来的结果就只是不友好的编程范式。

[red...@gmail.com]

我觉得 C++ 不会死掉, (甚至 cobol 都没有死啊), 用 C++ 已经写好的, 经典的
程序(很多啊), 也没有多少必要换语言重新写. 但是, 对于新项目, 特别是新公司
/新领域的新项目, C++ 的竞争力肯定在减退.

但是, 硬件的发展 (并发多核, 内存的廉价), 开发成本占整个系统成本的比重的
增加, C++ 的领域肯定持续萎缩.

就拿游戏编程领域来说, 游戏编程号称是很追求效率, 但是服务器端的业务逻辑,
现在多数都是用脚本语言编写. 客户端, 其实也就是网络和驱动 directx 那一层
用 C++ 好处较大, 更高一层, 现在也有用脚本的. 这都是因为开发, 调试, 热部
署等方面, C++ 并没有优势造成的.

排除掉很低层的应用, 拿稍高层来比较, C 由于有简单的 ABI, 可以作为操作系
统, 数据库或者其较基础性软件提供 api 的语言; 这样, 其他各种语言, 包括编
译的, 脚本的语言都容易调用这个 api, C++ 这点都做不到. 这些高性能要求的领
域本来用C的传统就强, OO 的帮助也不是太大, 用 C++ 编写要提供 API 反而需要
大量的 wrap. 这些位置, C 也很稳固.

C++ 的地位越发尴尬了.

[pongba]

重申讨论核心：

我的观点是C++当然目前还没有消亡；而且在并发普及到一定程度之前也不会消亡。
但一旦并发成为效率获得的唯一途径，C++的领土便只剩下需要跟机器接触的那一类程序了。
我无法预测这个事情多久会发生，但一旦某种程序员友好的并发编程范式（STM？Message-Passing？）被广泛工业化，这个事情便无可避免地会发生了。

BTW. 这里面一个重要的观点我需要重复一遍：即就算C++以后引入很好的并发编程支持，也无济于事。因为这不是他的唯一优点。另一方面，C++却总有唯一的缺点：就是为了达到零惩罚而折衷了的语言抽象模型。新生的语言既有并发支持，从而能够在效率上达到要求，又没有妥协了的语言抽象；于是将成为高性能开发的首选。

[这个前景对于热爱C++的人来说是阴暗的，但实际上正是自然选择的深刻反映：C++在特定历史背景下脱颖而出，因为那时候C++设计中作出的折衷换来的是更大的好处。现在，一旦我们不再需要通过这个折衷来换取这个好处，折衷便立即成了坏处。简而言之，环境发生了变化，在以往具有适应意义的特性不再适合，除了进化之外，只有淘汰。（不过语言进化始终都受到兼容性的影响，这是所有API设计者的切肤之痛。C++本身无法摆脱旧形骸，但新的语言会站立在C++倒下的地方，正如Bjarne所说，C++内部，有一门更小巧的语言急切地想要破壳而出！）]

On Nov 26, 2007 10:01 PM, pongba <pon...@gmail.com> wrote:

[莫华枫]

语言和人不一样。人寿命到了，就死了。语言只有在无法满足需要，并且出现替代物的时候才会被逐步替代。

1. 目前C++的应用领域是哪些（要精确）。

对于我而言，精确很难做到。我的业务领域比较狭窄，而且用周围人的观念来看，这个领域中根本没有c++什么事。但是，我可以提出足够的论据，表明一个在应用业务开发（如mis）中，在一定的情况下，c++的应用具有绝对的优势。这个观点往往引发口水仗。但是很多事实是无法改变的。多数持相反观点的人往往忽视一些关键性的问题。他们往往只考虑"做出一个软件"，而不是"做好软件"。这是完全两码事。我的观点很明确：如果贵公司是十来个人、七八条枪，并且只打算零敲碎打地做几个应用赚点幸苦钱，那么我的论调完全失效。但是，如果一个软件企业有一片完整的业务领域（不是某种单一业务，有时甚至会有好几片），并且需要持续发展的，那么我的观点在恰当不过。
问题的核心在于我们面向一个问题做软件，还是面向一类问题。如果面向一个问题，就事论事地做软件，那么对于一个宽泛的应用领域，我们就不得不翻来覆去地重复一些类似的开发工作。其中的重复劳动可想而知。同时，当我们持续地发展一套软件，并将其应用于不同的客户时，软件的修改成为不可避免的任务。就我的经历来看，大多数的客户间"移植"，都伴随着根本性的修改。以至于两三个版本后，不得不重做软件，以便重新构架，适应新的需求。我的一贯主张就是：如果软件注定要改，就把它弄得好改些。
综合以上两点，就对软件开发的技术运用提出了要求。已知最有效的途径在于两个方面：组件化和开放式结构。前者毋庸置疑，已经在工业界行之有效了百多年。后者对于自己攒过计算机的人而言，也不是什么新鲜玩意儿。
现有的诸多语言都或多或少地具备这些能力。但是，能够很好地将各种编程范式、静态类型系统、抽象机制整合起来的，也只有C++和ada。如果考虑运行效率和灵活性，那么C++更胜一筹（稳健和可靠当属ada）。而这些能力的综合运用，则有利于更快更方便地构建基础组件和开放式平台系统。
anti-c++的观点多半基于这样一种论调：高层编程，java、c#具备明显优势，底层编程比不上c，那么c++可以退出了。我先假设这种论断是正确的。那么在两层之间就没有c++的空间吗？很明显，还有很多"中间"型的应用被他们掠去了。比如数据库服务器、数据处理、图形处理、各类基础性的业务服务和组件等等。这类应用作为各种应用系统承上启下的支柱，规模足够庞大，有严格的性能要求，扩展性、灵活性的要求更高。这些应用要求语言有强大的抽象能力和足够的性能。c性能占优，但抽象不足，以至难以在成本约束下构建和维护如此复杂的系统。而Java的抽象能力尽管得到提升，非但以损失性能为代价，而且其抽象能力依然无法很好处理复杂系统（纯oop机制造的孽，使原本复杂的系统更复杂）。
很多主张回归c的人只看到c++带来的困难，但却忽视了另一个重要的问题，c++代码的各种软件工程统计数据远远优于c，非常接近ada。（我曾经给出过文档）。这也是很多程序员的局限，只考虑做软件，而不考虑付出的代价。
我们说c++应用有代价，而且不小。可问题是什么代价？学习代价？不错学通c++不是件易事。但是，学习是暂时的，使用是永远的。这几天，我在.net上做软件，使用c++/cli，很多方面的算法都可以做成通用的模板，一劳永逸。在这方面，我至少消减了10%～20%工作量。但是， 受限于.net库，相比标准c++，还是无法更优。在标准c++中，我可以直接复制、转换、过滤容器，并且做容器差集、并集等操作。在.net中不行（为此，我不得不手工用两个循环做差集操作）。.net尽管提供了空前庞大的类库，但却忽视了这些基本的操作。所有的容器接口不统一，以至大量的隐性"代码损耗"吞噬了程序员的劳动。这些损失是如此细微，以至于每个程序员都把手工循环作为一种"职业技能"；而这些损失是如此巨大，以至于至少有超过20%（有时甚至超过一半）的代码用于手工循环。而且当我打算玩上几把swap手法，以获得强异常保证，结果别别扭扭，最终还是放弃了。
人们往往只看到问题的一面，而忽视了另一面。
c++在应用方面的根本问题是它自身的缺陷。这些缺陷并非哪种强大功能的副作用，而是些"非受惑性失误"。如果c++消除了这些缺陷，问题便消除了一大半了。而那些伴随着各种特性出现的副作用，是不应代为受过的。毕竟c++的各种特性基本上都是平行的，是可以回避，而不影响使用的。
c++所有这些问题使得使用起来的一些成本，特别是培训成本增加。对于"短平快"的应用，这些成本是骇人的和不恰当的。但是对于那些基础性的复杂灵活的应用，这些增加的成本可以轻而易举地消化掉。更何况正确使用c++的技能并非象误传的那样困难。薄薄的一本101就能把所有的注意要领、基本方法、优化方法（性能和代码两方面）一网打尽。仅仅遵守几个基本条款，便能使程序员将c++运用到java那样便捷的水准，而其他方面则更进一步，使得我们得以构造更趋完善的软件。java等语言，则没有这种提升，令人感到悲哀。（我周边的c#er们没有一个听说过异常保证，更别说用了）。

2. 目前C++所占领的领域，是因为非C++不可，还是因为政治或历史原因？（逐个分析）

我觉得所有语言的应用都有政治性的内含，有的多些，有的少些。象java和c#之类语言几乎完全是政治（商业）推动的。而c++则随着时间推移，政治性内含越来越多。而新版的标准出现后，政治性意味会下降，因为新特性带来的好处促使人们重新审视语言。然后随着时间的推移，政治性又会增加。如此反复，直到正式退休。

3. 这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing...）），为什么。

这些领域应当被未来新兴的语言替代掉。毕竟c++不是最完善的语言。问题在于，现有的语言都没有在根本上first-class解决c++所面临的问题。c++面临最大的问题是，任何人都想把它放在某个领域中使用，并加以比较。结果，尽管c++已经强大到在任何一个领域进行这种对抗，但所付出的代价却抵消了很多领域中所作的努力。结果每个人都不满意。
未来是专业语言的天下。不大可能再出现通吃天下的语言。
或许gpl/mp混合语言可能会消除这类问题：一种简单基本的host语言，外带完整的mp能力，通过建库实现各类专业语言和语法特性的控制。大概只有这样，才能让贪得无厌的人们皆大欢喜。
换句话说，如果我们要替代C++那么应当在继承其能力的基础上有质的提升，而不仅仅是修修补补。c++打开了一扇门，但已经力竭。后来的语言不应当因为看到c++为此倒下，而裹足不前。只要能够勇敢地进入c++已经打开的新世界，那么即便是从他的身上踩过去，也是值得的。

4. C++独一无二（不可取代）的优势到底是什么？

c++独一无二的优势自然是其不损失性能和静态特性抽象能力。在09之后，这方面能力更是无人能及。这方面的应用没有被充分地发展，甚至被有意无意地忽视或掩盖了。这是软件行业的一种损失。很多人没有意识到c++在这方面的优势，及其带来的好处。
试想一下，如果我们手头一种语言拥有全面stl化的库，包括基础算法和容器，gui，io，net等等。那么当我们在构造软件时，有多少workaround可以被消除呢？
gp所带来的静多态使得我们在软件开发时可以仅仅考虑各种符号的语义，而无须关心具体选择的算法和对象版本。
如此等等，众多特性对于软件项目而言是弥足珍贵的。
c++的问题是带来这些特性的同时，也带来了大量的"不和谐音"。很多观点都是把c++存在的问题，看作那些特性的问题，加以回避。这种追本求末的认识直接误导了众多不更世事的芸芸众生。以至于在论坛上，java也在那里同c++叫板比抽象。

至于并发么，我不太清楚问题的所在。只是觉得并发在这里并不是问题的关键。未来提升性能的手段很多，并发是其中之一，这些手段对于各种语言来讲也都是透明的，等同的。而语言本身的特性是真正"个性"的东西。是决定语言兴亡的基本要素。问题还是人们的认识，人们是否愿意为了获得一些好处而付出另一些代价。多数时候，代价存在一个阈值，小于阈值的时候，人们很容易地接受，而大于阈值时，无论有多大的好处，都很难接受的。有的人阈值比较高，比如说我。而多数人阈值比较低，倾向于代价较低的特性，尽管可能在其他方面付出更大的代价。这也就是很多人说C++专家亲和的原因吧。

On Nov 26, 2007 10:01 PM, pongba <pon...@gmail.com> wrote:

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

[pongba]

On Nov 27, 2007 12:39 PM, 莫华枫 <longsh...@gmail.com> wrote:

语言和人不一样。人寿命到了，就死了。语言只有在无法满足需要，并且出现替代物的时候才会被逐步替代。

1. 目前C++的应用领域是哪些（要精确）。

对于我而言，... 

那么在两层之间就没有c++的空间吗？很明显，还有很多"中间"型的应用被他们掠去了。比如数据库服务器、数据处理、图形处理、各类基础性的业务服务和组件等等。这类应用作为各种应用系统承上启下的支柱，规模足够庞大，有严格的性能要求，扩展性、灵活性的要求更高。这些应用要求语言有强大的抽象能力和足够的性能。c性能占优，但抽象不足，以至难以在成本约束下构建和维护如此复杂的系统。而Java的抽象能力尽管得到提升，非但以损失性能为代价，而且其抽象能力依然无法很好处理复杂系统（纯oop机制造的孽，使原本复杂的系统更复杂）。

我提出质疑的关键就在这个地方。
在以往，以上这个论述是绝无问题的。然而，在并发普及之后，我猜测这些对性能要求高的应用完全可以通过并发来获得远高于"减少抽象惩罚而榨取出来"的效率。这么一来，也就是说"减少抽象惩罚"不再成为效率的来源。于是为了减少抽象惩罚而折衷了的语言设计便成了纯粹没好处的缺点了。
 

很多主张回归c的人只看到c++带来的困难，但却忽视了另一个重要的问题，c++代码的各种软件工程统计数据远远优于c，非常接近ada。（我曾经给出过文档）。这也是很多程序员的局限，只考虑做软件，而不考虑付出的代价。
我们说c++应用有代价，而且不小。

是的，一来这个代价是可以克服的。二来更关键的是，以前C++付出折中语言设计从而换取效率的决策是一个好的决策。
但现在的问题是，一旦折中语言设计不能换来效率。那么我们便不再需要去迎合二等的语言设计了。比如，C++/JAVA/C#这些传统语言其实都有两套OO机制。一个是基于类继承的多态，一个则是泛型。本质上，这可以归约为一种范式，即ruby的duck-typing+C++0x的concept（非侵入的接口）。而为什么这些语言有两套OO，就是因为传统的基于接口的多态是特定时代背景下为了效率而实施的折衷。
 

可问题是什么代价？学习代价？不错学通c++不是件易事。但是，学习是暂时的，使用是永远的。这几天，我在.net上做软件，使用c++/cli，很多方面的算法都可以做成通用的模板，一劳永逸。在这方面，我至少消减了10%～20%工作量。但是， 受限于.net库，相比标准c++，还是无法更优。在标准c++中，我可以直接复制、转换、过滤容器，并且做容器差集、并集等操作。在.net中不行（为此，我不得不手工用两个循环做差集操作）。.net尽管提供了空前庞大的类库，但却忽视了这些基本的操作。所有的容器接口不统一，以至大量的隐性"代码损耗"吞噬了程序员的劳动。这些损失是如此细微，以至于每个程序员都把手工循环作为一种"职业技能"；而这些损失是如此巨大，以至于至少有超过20%（有时甚至超过一半）的代码用于手工循环。而且当我打算玩上几把swap手法，以获得强异常保证，结果别别扭扭，最终还是放弃了。

...

4. C++独一无二（不可取代）的优势到底是什么？

c++独一无二的优势自然是其不损失性能和静态特性抽象能力。在09之后，这方面能力更是无人能及。

实际上，C++为了实现零惩罚的抽象，损害了抽象的自然性。C++中的两种复用机制，一个基于接口的，是动态紧绑定。另一个是基于template的，则是静态非绑定。而实际上，为什么人们喜欢ruby，就是因为ruby里面的复用机制是动态非绑定的，最自然的。C++的这种区分动静两个世界的做法带来了学习成本，以往这个成本是必须付出的，因为它带来的好处——效率——远远大于坏处（学习成本）。然而如今（不久的将来），当并发成为效率的来源，我们不再需要利用零惩罚的抽象来榨取效率；那么可想而知，谁还愿意或者有必要去付出这个非平凡的学习成本呢？
 

这方面的应用没有被充分地发展，甚至被有意无意地忽视或掩盖了。这是软件行业的一种损失。很多人没有意识到c++在这方面的优势，及其带来的好处。
试想一下，如果我们手头一种语言拥有全面stl化的库，包括基础算法和容器，gui，io，net等等。那么当我们在构造软件时，有多少workaround可以被消除呢？
gp所带来的静多态使得我们在软件开发时可以仅仅考虑各种符号的语义，而无须关心具体选择的算法和对象版本。
如此等等，众多特性对于软件项目而言是弥足珍贵的。
c++的问题是带来这些特性的同时，也带来了大量的"不和谐音"。很多观点都是把c++存在的问题，看作那些特性的问题，加以回避。这种追本求末的认识直接误导了众多不更世事的芸芸众生。以至于在论坛上，java也在那里同c++叫板比抽象。

至于并发么，我不太清楚问题的所在。只是觉得并发在这里并不是问题的关键。未来提升性能的手段很多，并发是其中之一，

除开通过算法提高效率之外。传统上提高效率的办法基本就是减少抽象惩罚来榨取效率。而我的意思是，在并发这个更强大的武器面前，通过减少抽象惩罚来榨取效率的手法将失去用处。于是就意味着一类语言的生命期结束（包括C#/JAVA/C++），这类语言为了减少抽象惩罚而付出了折衷语言设计的代价。比如C#里面的值类型和引用类型的分裂，Java里面的基本类型和对象类型的分裂，都属此类折衷。

[SpitFire]

sutter不是发文是并发是c++新的机会么，近来并发领域是个什么情况

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

[莫华枫]

哦，看来是我理解有问题，还有些跑题。
刘兄的意思是说下一代语言整个按最强大最完善的抽象设计，然后在尽量在语言特性上考虑性能。剩下的，就依赖各种优化手段处理。最后那些无法弥补的，也可以从并发上基本得到补偿。这样的话，同c++相比也不会有明显的性能差异。反正抽象第一位，性能地位降低。
是这意思吧？
这完完全全是我盼望的东西。:)
c++在性能方面早年似乎有些不可理喻（从现在的观点来看）。c++似乎打算一下举起抽象和性能这两串杠铃，结果砸了自己的脚。我觉得c++是因为不肯放下性能这副担子，导致不得不拼凑特性，采用添油战术，外加上不愿像兼容性问题低头，把问题搞复杂了。
ruby的类型系统形式更加合理，但损失了静态类型的好处。如今，concept浮出水面，使得泛化类型系统由"离散"变为"连续"，于是c++便有机会很好地处理ducktyping同static typing的矛盾。同时，也多少弥合了性能同最佳抽象之间的差距。但是，c++的多态形式已经定死，不可能再变换到更好的形式上去。就是说，09以后，c++多态能力达到了极致，但是却穿着件长满荆棘的外套。而这件外套原本用来防御的问题已经大大地弱化，这一身刺毫无用处，平添累赘。
如果想要消弭此中问题，看来不敲掉几面墙是不可能的了。关键在于敲掉哪些墙。有些是装饰墙，敲掉无碍，而有些是承重墙，动则伤及根本。c++09不敢动一砖一瓦，也只能以涂料粉饰。java、c#声称在c++上改进，实际上敲掉了很多承重墙，摇摇欲坠。而d似乎也没有完全敲对地方。
此间根本，我难以看清，尚在迷雾之中，还需高人指点呐。:)

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

[王磊]

关于并发什么的不是很明白，可是对于一个语言是不是会消亡，我想对于软件行业来说，接触过项目开发的人多少都会知道这样一个规律，就是只要这段代码还能完成我们对业务的要求，就绝不会推翻重写。即使只有上百行。同理目前大型设备企业中运行的系统用c++写成的还是很大比例的。因此除非这些系统不能满足需求，不然客户就会不断的在原有的系统上继续开发下去。

 

别说什么新的语言新的技术如何如何。最简单的道理就是对于商业系统来说，稳定才是第一位。你可以说我用新技术新语言能实现省很多代码，节省很多时间，可是客户不会同意你重写一个系统，每多写一本程序所引入的bug及新的问题都会呈几何级数的增加，直到崩溃。

 

只是c++对未来的竞争力却是堪忧。

 

在07-11-27，莫华枫 <longsh...@gmail.com> 写道：

[pongba]

On Nov 27, 2007 4:24 PM, 王磊 <wangle...@gmail.com> wrote:

关于并发什么的不是很明白，可是对于一个语言是不是会消亡，我想对于软件行业来说，接触过项目开发的人多少都会知道这样一个规律，就是只要这段代码还能完成我们对业务的要求，就绝不会推翻重写。即使只有上百行。同理目前大型设备企业中运行的系统用c++写成的还是很大比例的。因此除非这些系统不能满足需求，不然客户就会不断的在原有的系统上继续开发下去。

 

没错，所以说遗留代码也是C++现在领域的一个主要原因呢。
但是值得注意的是，新系统将不会用一个二等语言开发，遗留系统终将结束寿命。一段时间之后，必然是全盘更新换代。遗留系统不会永远长存。

[redsea(肖海彤)]

这就是我前段时间碰到的问题,  我面对自己的一个新领域, 同时也是一个新公司起步阶段, 急着寻找 C++ 的替代品的原因. 一旦公司的积累在这个语言上了, 就不容易改变了, 毕竟我们不是做 MIS 的公司, 改动起来伤筋动骨的.
 

现在决定积累在 C, D, 和 Python 上面.
 

在07-11-27，王磊 <wangle...@gmail.com> 写道：

[liang]

我和荣耀老师聊天的时候，他指出一个C++的绝对领域：那些已经被C++ fans占领的领域。
你能指望Photoshop team的人用C#或Java把Photoshop重写一遍？
即便C#或Ruby的性能强劲到无以复加，他们也不会放弃C++的。

此外，C++还是在发展的。
不是所有的原则都会50年不变，C++1x标准就真的不会引入"可选的"元数据和反射么？
与时俱进么，只要不停的发展，C++5x也是有希望的。

CPU性能提升得很快，但是还是有人抱怨Vista太占资源。
虽然Managed code是未来绝对的主流，但是对于Windows team，Native code就是唯一。这就是现实。
C++的领域即便缩小，也没有什么，人尽其才、物尽其用么。

On 11月26日, 下午10时01分, pongba <pon...@gmail.com> wrote:
> 以下讨论正发生在云风 <http://www.codingnow.com>的mailist上，摘抄到目前为止的发言，大家说说：
>
> *Oscar.Ken:*
> 浪费我20%的生命在等待编译上*;)，*还有5%是在string的各行其道下。
>
> *孟岩:*

> 就用最朴素的那部分C++就可以了。C+ ADT + 一点点多态 + 异常 + 一点点STL。我想
> 不出有什么是做不到的。
>
> C++中不要谈面向对象，除非你愿意用boost::share_ptr。
>
> COM的想法还是不错的，就是太复杂，有必要自己实现一个简化版。
>
> 如果string的内部实现影响了你的工作，那表明你在写系统级程序，在这个级别上，不
> 要用string比较好，随便一个操作你都不知道会发生什么，不符合系统级开发的要求。
>

> *kenneth chia:*
> 我在生活中从来没有发现一个是C++高手，忽悠的我看到好多。。。
>
> *Shuo Chen:*
> 我觉得异常都可以不用，程序出错就死掉好了。
>
> *孟岩:*

> ANTLR本身是用Java写的语言识别器，但是它生成的C/C++代码运行速度比对应的Java版
> 快2倍，内存耗用只有1/3。
>
> 所以在单机系统里要求告诉执行的任务，比如图形图像处理，实时数据处理，很长时间
> 里都会继续使用C/C++。
>
> 但是用C++绝对不要去求奇妙，模仿其他语言的什么高深奇妙的功能，这绝对是个误
> 区。
>

> *Qutr:*
> 其实回归到C语言才是最好的！
>
> *邓云:*

> 我做的是视频编码，这个方向是明显的计算密集性工作，实时性压倒一切。除了汇编语言外，C/C++是唯一能接受的高级语言。而且C/C++对系统资源的使用，如-内存的使用，有非常明显的可控制性。这在对资源要求很严格的情况下C/C++也是优先选择。从这个角度看，视频压缩和图形图像处理，实时系统处理领域里，短期内-还不会有能代替C/C++的语言。

> 另外，说C/C++的编译时间问题，可以想到的是相对运行时间，编码时间的开销换来的运动效率绝对是值得的。
> 当然，要跨平台，要做WEB，那是另一回事了。C/C++也不是为WEB设计的。
>

> *Will Zhang:*

> 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
> 事实上，有许多"高深"的功能C++已经使用了。
> 比如垃圾回收。你用C++开发大型项目的时候，经常会想到要做一个垃圾回收。
>
> 我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
> 然后想到，或许这种东西的使用应该更普遍，然后就开发了另一种语言。：）这个随便说说。
>

> *Siney:
> *在07-11-23，Will Zhang <lala.willzh...@gmail.com> 写道：

>
> > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
> 这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
> 通过ecx传递好像也只是ms的编译器的做法，而非标准规定，gcc我不清楚，不过即使是想通过寄存器来传递，c也可以申明register吧。
>

> *最后，我觉得这个问题应该这样来提问：

>
> 1. 目前C++的应用领域是哪些（要精确）。
> 2. 目前C++所占领的领域，是因为非C++不可，还是因为政治或历史原因？（逐个分析）
> 3.

> 这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing...-）），为什么。

> 4. C++独一无二（不可取代）的优势到底是什么？
>
> 其实，以上的问题内可以把C++换成任意一门其他语言。

> *
> 最后说说我的观点：以往，人们普遍认为C++的独一无二的优势是效率。而C为什么不更好呢？C同样效率且语言模型更简单。但语言模型更简单并不代表用该语言编程-就更简单。OB/OO/GP是已经被实践证明的有效范式（虽然OO的定义似乎从来就没有明确过，但OB至少还是可以谈论的），如果没有first-class支-持，而又要用到的话，就很难搞了。也就是说，当"鱼（first-class的范式支持）我所欲也；熊掌（效率）亦我所欲也"的时候，也就只剩下C++这个选手-了。为此用C++编程的人宁可仍受各种各样的非本质复杂性，因为与刚才那两个需求相比，这些非本质复杂性至少是可以克服的。
>
> 以上这个论点建立在一个前提之上，及C++的某些特点导致了它的高效。什么特点？接近机器的抽象模型。（OO的实现方式，GP的实现方式）这使得语言在实现高级-编程范式的时候做到了零惩罚（中间层几乎被削减到无）。这个零惩罚当然是有代价的（昂贵的代价），比如GP在C++中的实现就并非是"运行期+非绑定"的（ru-by的是）。
>
> 而这个前提又建立在另一个前提之上，也就是：传统的程序是通过减少抽象惩罚来最大化执行效率的。这才使得C++这种语言实现抽象惩罚最小的语言在一些领域成为独-一无二的选择。

>
> 那么，我们来看最后这一个前提到了并发时代还能满足吗？
>
> 显然，通过减少抽象惩罚而获得的效率提升跟通过提高并发程度获得的效率提升一比就微不足道了。
>
> 以上论点的前提是：该程序必须要能够并行化到一定程度。如果本质上决定了必须要串行执行或者并行化带来的收效甚微，那就白搭了。
>

> 于是，要证明C++的优势在并发时代会消失。我们只需证明，目前C++应用领域中的主体软件，是可以通过并行化来提到一个非平凡的效率的，这个非平凡的效率提升-将使得通过减少抽象惩罚来获得的效率提升变得微不足道。

>
> 例如，传统上，图像处理和游戏被认为是C++的经典领域，但考虑到并发，这个领域还能保留吗？这两个领域可都是能够高度并发的。
>
> 我觉得这个结论基本就不需要证明了。
>
> 好，如果这个结论成立。那么随之就带来了一个重要推论：
>

> 原来C++是为了减少抽象惩罚从而在语言的抽象模型上做了很大的折中（比如前面提到的GP的实现），本来这个折中是个优点，因为它换来了效率。而现在突然换不到-效率了，那就立即变成了大大的缺点。如果同样都能获得效率，难道不是用更自然的ruby更让人舒服吗？

>
> 回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的
> 决策是：通过实现零惩罚的抽象（OO、GP），来达到效率+抽象兼得的目的。而这个决策，在当前的背景下，由一个优点，变成了一个缺点，因为它折中了抽
> 象。如果我们不再需要通过零惩罚的抽象类来获得效率，"零惩罚的抽象"所带来的结果就只是不友好的编程范式。
>
> 有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。
>
> 剩下的问题是：
>
> 那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）
>
> 也许是有的，我可以列出两点：
>
> 1. 直接操纵硬件。
> 2. 静态类型系统。
>

> 第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用-什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具-有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
>
> 第二点的优势目前我也不特别肯定。静态类型系统，众所周知，有助于尽早发现问题。动态语言为了"动"起来，其实也折中了静态类型系统的优点，导致了一些批评（比-如ruby的ducktyping需要concept）。但我的看法是，ruby如果能够加上一定的静态类新成分，再加上程序自动验证领域的进展，最终会弥补这-个缺陷。但这方面我也不是很了解，所以留给了解的人评说。
>
> 总之我得出的结论就是，并发的普及将导致C++的领域最终缩减到需要直接操纵硬件的领域，并且在这个领域还有可能被其他语言取代（因为通过减少抽象惩罚来获得效-率不再必要，使得为了减少抽象惩罚而折中的语言模型成为一个极大的弱点）。这里只有一个漏洞，就是在这些需要直接操纵硬件的底层领域，又有多少是能够通过并发来-获得效率的，如果不能并行化，那还是得借助于C++的零惩罚的语言模型。但无论如何，这样的领域怎么也不会太大了。

[sean...@gmail.com]

c++把兼容性看的如此重要也是不想失去遗留代码领域的支持，话说，是不是进了标准库的东西就没法剔除了，c++倾向于用库来解决问题而不是语言进化，理由是库方便进化，而兼容性。。。

在 07-11-27，liang<adam...@gmail.com> 写道：

[莫华枫]

c++1x还是真的诱人。可这5x就...
managed code是否会成为主流还得看。sutter在ms的正是任务是搞c++/cli的标准化，这件事已经完了。现在的任务是开发一个统一的内存模型，统一ms所有的系统，包括各类windows、ce等等。0.9版的论文里提到managed内存将会在这个内存模型上建立。这似乎表明ms还有一个更大的系统。但是，ms不会把宝压在一个东西上，什么东西都会尝试，而什么东西都没有绝对性。

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

[Sean Lin]

并发并不是免费的呀,说实话，现在单cpu多核，不过是因为现在cpu的主频做不上去，不得已而为之。
并发有多种，像多任务的并发，不在语言的讨论范围之内。单任务的并发，基本上是很难做到1+1 = 2， 数据同步，不是锁，就是erlang之类纯粹
的消息传递，都是要消耗资源的。所以并发本质上没有提高cpu的利用率。集群也是这样。所以并发决不会是解决性能问题的银弹

资源永远不会是无限的，关键是和开发成本,维护成本之间的平衡。如果有业务不需要频繁的变更，但是要求高性能，有合适库支持下，为什么不用C＋＋，
比如图形处理，如果要对3d场景进行实时渲染，用ruby，用erlang，有可能会需要多出几倍的机器，维护这些机器的正常运行的成本(机房，水
电)，也不是小数呀.


On Nov 26, 10:20 pm, pongba <pon...@gmail.com> wrote:

[wing fire]

C++貌似看不出任何死亡的征兆，Java和C#也在走C++的老路。至于Python和Ruby,我看不可能达到C++的高度，跟在Ruby和Python后面的敌人更凶狠。
C++的复杂，很大一部分是和C兼容造成的，但是，理智的C++程序员应该意识到，这些特性就差打上deprecated标记了。C++抛不掉这一部分固然遗憾，但是并不成为致命的问题。
C++固然复杂，Java和C#也开始不简单了。谁要是觉得anotation看上去很美，全当我没说。 那东西压根就不能配得上language这个词.况且本来复杂的东西，看起来复杂没什么大错。C#的template是简单，不过那是被阉割了的。Java根本就是个骗局。
至于OO，那种华丽的巴洛克式的类设计简直就是犯罪。所以，Java,C#在这方面就算本事大，屠龙技而已。倒是应该研究一下怎么加强对组合技术的支持。C++对组合的支持也很烂，不过，比起Java和C#还是要好一点。FP组合能力很强，但是，一来大家不熟悉，二来性能有时候有点问题，第三，对ADT的支持总觉得不顺手。
Java在concurrency方面的贡献值得尊敬。但是，在并行领域，C++并不落后。MPI,OpenMP那种东西，语法上简直有反人类的嫌疑。充其量，也只能算是并行领域的汇编语言。用这些东西，对我来说，基本没有精力去思考和问题本身相关的事情了。并发的大门还没完全打开，现在就下结论为时过早。如果用操作系统来打比方，现在还是设计原子操作，中断门，重入的阶段。离完整的内存管理，进程调度还早着呢。

在07-11-28，Sean Lin <NetS...@gmail.com> 写道：

[Atry]

在07-11-29，wing fire <wing...@gmail.com> 写道：

C++貌似看不出任何死亡的征兆，Java和C#也在走C++的老路。至于Python和Ruby,我看不可能达到C++的高度，跟在Ruby和Python后面的敌人更凶狠。
C++的复杂，很大一部分是和C兼容造成的，但是，理智的C++程序员应该意识到，这些特性就差打上deprecated标记了。C++抛不掉这一部分固然遗憾，但是并不成为致命的问题。
C++固然复杂，Java和C#也开始不简单了。谁要是觉得anotation看上去很美，全当我没说。 那东西压根就不能配得上language这个词.况且本来复杂的东西，看起来复杂没什么大错。C#的template是简单，不过那是被阉割了的。Java根本就是个骗局。
至于OO，那种华丽的巴洛克式的类设计简直就是犯罪。所以，Java,C#在这方面就算本事大，屠龙技而已。倒是应该研究一下怎么加强对组合技术的支持。C++对组合的支持也很烂，不过，比起Java和C#还是要好一点。FP组合能力很强，但是，一来大家不熟悉，二来性能有时候有点问题，第三，对ADT的支持总觉得不顺手。
Java在concurrency方面的贡献值得尊敬。但是，在并行领域，C++并不落后。MPI,OpenMP那种东西，语法上简直有反人类的嫌疑。充其量，也只能算是并行领域的汇编语言。用这些东西，对我来说，基本没有精力去思考和问题本身相关的事情了。并发的大门还没完全打开，现在就下结论为时过早。如果用操作系统来打比方，现在还是设计原子操作，中断门，重入的阶段。离完整的内存管理，进程调度还早着呢。

全篇都是废话 

[holmescn]

我觉得，在C++的使用上，应该以达到程序设计目的为目标。
现在好像更多的是以炫耀为目标。
将C++神圣化，也是各种语言与之争论不断，不停攀比的原因之一。

应该用更平和的心态去接受和使用所有的语言。

[CAXSOFT]

同意。

没有见过哪门语言真正的死去，因为总有它的用武之地。

 

在07-11-29，holmescn <holme...@gmail.com> 写道：

[cherokee]

开了眼了，呵呵。尽管内中技术太半都未曾深入了解，但这样的讨论倒是增长见识的好机会。
这篇博：
http://blog.csdn.net/longshanks/
里边c++相关的资料也颇为过瘾。
only mark.
甚谢甚谢！

[Jian Wang]

我觉得之所以大家批评C++这么激烈，主要还是应为现在C++坚守的领域缺乏接班人。C++就算问题再多，大家也只能咬牙忍下去，或者对着0X望梅止渴一下。
好在D看上去还不错，说不定能成为一个不错的接班人。希望能赶快成熟起来。

另
CPU里的SIMD技术推出了无数指令，现在软件能用上多少呢？
C++的话，在语言上明显没有办法显式的利用这些指令。直接汇编也吃不消。靠编译器优化的话能有多大效果？
X86-64增加了好多寄存器，实际软件的性能得到多大的提升？
希望有达人出来解说一番。

在 07-11-29，cherokee<tec...@gmail.com> 写道：

[pongba]

On Nov 29, 2007 9:57 PM, Jian Wang <oxygen.j...@gmail.com> wrote:

我觉得之所以大家批评C++这么激烈，主要还是应为现在C++坚守的领域缺乏接班人。

主要是理性分析，有批评也是理性的批评。
理由我已经在第一篇帖子里面陈述得很清楚了，感觉真正看的人很少，因为除了莫兄基本没有人对我的想法提出具体的意见。也许我没有说清楚什么是"通过折衷抽象模型来获得效率"？
 

C++就算问题再多，大家也只能咬牙忍下去，或者对着0X望梅止渴一下。
好在D看上去还不错，说不定能成为一个不错的接班人。希望能赶快成熟起来。

另
CPU里的SIMD技术推出了无数指令，现在软件能用上多少呢？

"现在的事实"不代表"未来的趋势"。好的并发编程模型定会出现的。好的优化技术也定会出现的。
 

C++的话，在语言上明显没有办法显式的利用这些指令。直接汇编也吃不消。靠编译器优化的话能有多大效果？
X86-64增加了好多寄存器，实际软件的性能得到多大的提升？

我们讨论的不是C++在并发时代下的前景吗？

[Jian Wang]

> 主要是理性分析，有批评也是理性的批评。
> 理由我已经在第一篇帖子里面陈述得很清楚了，感觉真正看的人很少，因为除了莫兄基本没有人对我的想法提出具体的意见。也许我没有说清楚什么是"通过折衷抽象模型来获得效率"？

楼上的发言我很仔细的阅读了。
"通过折衷抽象模型来获得效率"的意思也说的很清楚。

从长期来看，随着硬件的发展，抽象程度必然会越来越高。为了效率而折衷的模型必定会被淘汰。C++不光有为了效率的折衷，还有承重的历史包袱。我希望能有新的语言出来顶替C++的位置。

但是从短期来看，多核的出现反而会降低抽象。
比如说现在的编程语言基本上把内存和CPU都抽象掉了。
但是核的增加会使得统一内存模型无以为继。每个核都会有自己的本地内存。这样的话，为了利用多个核，就必须把内存模型暴露给程序员。

> > C++就算问题再多，大家也只能咬牙忍下去，或者对着0X望梅止渴一下。
> > 好在D看上去还不错，说不定能成为一个不错的接班人。希望能赶快成熟起来。
> >
> > 另
> > CPU里的SIMD技术推出了无数指令，现在软件能用上多少呢？
>
> "现在的事实"不代表"未来的趋势"。好的并发编程模型定会出现的。好的优化技术也定会出现的。

这个地方我没说清楚，抱歉。我这里并不是反问。而是疑问，我对这方面的情况不了解，希望有了解的人出来说明一下。
下面的问题也是一样。

[SevenCat]

On 11月29日, 下午10时45分, "Jian Wang" <oxygen.jian.w...@gmail.com> wrote:
> > 主要是理性分析，有批评也是理性的批评。

> > 理由我已经在第一篇帖子里面陈述得很清楚了，感觉真正看的人很少，因为除了莫兄基本没有人对我的想法提出具体的意见。也许我没有说清楚什么是"通过折衷抽象模型-来获得效率"？
>
> 楼上的发言我很仔细的阅读了。
> "通过折衷抽象模型来获得效率"的意思也说的很清楚。
>
> 从长期来看，随着硬件的发展，抽象程度必然会越来越高。为了效率而折衷的模型必定会被淘汰。C++不光有为了效率的折衷，还有承重的历史包袱。我希望能有新的语-言出来顶替C++的位置。

>
> 但是从短期来看，多核的出现反而会降低抽象。
> 比如说现在的编程语言基本上把内存和CPU都抽象掉了。
> 但是核的增加会使得统一内存模型无以为继。每个核都会有自己的本地内存。这样的话，为了利用多个核，就必须把内存模型暴露给程序员。

据我的理解，目前只有内核每个核有自己的本地内存（每CPU的数据），普通的应用程序还是基本上以线程方式来运行，我觉得大家也没必要把并行看得太重，
根据实际情况，需要并行时我们再去想办法就可以了。现在多核概念满天飞，但基本是厂商做宣传，应用呢？应用在哪里？需要我们去了解CPU内部结构的应用
在哪里呢？

我一直认为多核这个东东对普通程序员来说意义不大，我们最多做到多线程编程就可以了，而这是老早就成熟了的技术。

>
> > > C++就算问题再多，大家也只能咬牙忍下去，或者对着0X望梅止渴一下。
> > > 好在D看上去还不错，说不定能成为一个不错的接班人。希望能赶快成熟起来。
>
> > > 另
> > > CPU里的SIMD技术推出了无数指令，现在软件能用上多少呢？

其实好像早就开始用了，以前HL2泄漏出来的代码里面，数学库里面有一个很大的文件夹，基本都是用汇编来写的，来做各种各样的优化。xvid里面好像也
有很多的汇编代码用到了。

>
> > "现在的事实"不代表"未来的趋势"。好的并发编程模型定会出现的。好的优化技术也定会出现的。
>
> 这个地方我没说清楚，抱歉。我这里并不是反问。而是疑问，我对这方面的情况不了解，希望有了解的人出来说明一下。
> 下面的问题也是一样。
>
>
>
> > > C++的话，在语言上明显没有办法显式的利用这些指令。直接汇编也吃不消。靠编译器优化的话能有多大效果？
> > > X86-64增加了好多寄存器，实际软件的性能得到多大的提升？
>
> > 我们讨论的不是C++在并发时代下的前景吗？
>
> > --
> > 刘未鹏(pongba)|C++的罗浮宫
> >http://blog.csdn.net/pongba
> > TopLanguage
>

> >http://groups.google.com/group/pongba- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[SevenCat]

抛开应用空洞的谈论并行，多核，我认为跟抛开程序空空的谈语言的概念一样。

[SevenCat]

http://downloads.xvid.org/downloads/xvidcore-1.1.3.tar.gz
这里是xvid的代码,我刚才又看了一下，里面已经大量运用了SSE，3DNOW之类的指令（我们看到的很多mp4就是用他来放或者压缩的）
icc也增加了一些C++的封装，但我想大部分人还是会选用汇编的方式。

对我来说，C++明天怎么样跟我没有太大的关系，能用则用，不能用就换。

[莫华枫]

对，我半年多前对c++的态度还是fans级的。但是自从看过pongba的几篇blog之后，我开始认识到c++的问题。c++毕竟30多的高龄了，如果一门语言能够在主流中生存超过50年，那就是不正常的，说明没有发展了。
我们这里多数讨论都是本着"探讨c++的特性" ，而不是"探讨c++"的宗旨的。因为探讨特性有助于我们理解语言中那些东西是重要的，哪些东西是可以发展的，以及哪些东西是未来等等。特性对于任何语言都是平等的。
而探讨语言（特别是争论语言）则关注的是语言在文化层面的内容，更多的应该是那些"学者"而不是我们这类技术人员所做的事。
我感觉在这里我们所探讨的都是：肯定c++好的特性，并且考虑如何让这些特性更好；批评那些丑陋的东西，并考虑如何避免。
所以，我们不是在"批判c++"，而是在批判c++的丑陋的东西。
问题在于，我们批判c++的丑陋特性，并不是为了抛弃c++。c++终究会被抛弃，从目前而言，c++能够解决问题，很多时候还能够更好地解决问题。只是在到达这个目标的时候，付出了很大的代价。这里讨论的便是：是否有可能在获得这些好处的时候，少付出，甚至不付出代价。
至于c++的接班人，我什么都不敢说，我认为要抵消c++的应用惯性，新语言必须全面地，本质地超越c++，彻底解决c++的核心问题（当然我们不能要求全部解决，对吧）。
说句异想天开的话，或许我们这里的讨论也能催生一门替代语言，也未可知哦。:)

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

[王磊]

一门语言何必遭到这么多的批判评价和指责呢？还是大家对他的关心超过了应有的程度。

任何语言都可以实现的东西我们就把他当作一天路，适合就走，不适合就换。

 

多做做项目，就会知道，没有考虑语言好坏的权利。

 

D语言会是新的霸主？乱世阿~

 

在07-11-30，莫华枫 <longsh...@gmail.com> 写道：

[buhongbo]

就是，就是。我总觉得莫总和pangba讨论的东西太玄了！有点像历史书上讲的那些士人清谈！

------------------
buhongbo
2007-11-30

-------------------------------------------------------------
发件人：SevenCat
发送日期：2007-11-29 23:41:42
收件人：TopLanguage
抄送：
主题：[TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）

抛开应用空洞的谈论并行，多核，我认为跟抛开程序空空的谈语言的概念一样。

[liang]

以我的所知，在Visual Studio语言家族里C++/CLI的重要性已经下降。它的目标应该是处于Managed和Native两个世界之间的
互操作语言，是一种胶合语言。

C++/CLI并不符合程序员的文化。对于native code programmer，他们根本不使用managed heap，他们依赖于
system heap and lock-free data structure去获得高性能。对于managed code
programmer，他们为什么要去使用两种指针类型的语言呢？而且，C++/CLI的调试一直是困难的问题，其难度大于典型的native
programs。

On 11月27日, 下午8时12分, "莫华枫" <longshank...@gmail.com> wrote:
> c++1x还是真的诱人。可这5x就...
> managed

> code是否会成为主流还得看。sutter在ms的正是任务是搞c++/cli的标准化，这件事已经完了。现在的任务是开发一个统一的内存模型，统一ms所有-的系统，包括各类windows、ce等等。

> 0.9版的论文里提到managed内存将会在这个内存模型上建立
> 。这似乎表明ms还有一个更大的系统。但是，ms不会把宝压在一个东西上，什么东西都会尝试，而什么东西都没有绝对性。
>

> > 我做的是视频编码，这个方向是明显的计算密集性工作，实时性压倒一切。除了汇编语言外，C/C++是唯一能接受的高级语言。而且C/C++对系统资源的使用，如--内存的使用，有非常明显的可控制性。这在对资源要求很严格的情况下C/C++也是优先选择。从这个角度看，视频压缩和图形图像处理，实时系统处理领域里，短期-内-还不会有能代替C/C++的语言。

> > > 另外，说C/C++的编译时间问题，可以想到的是相对运行时间，编码时间的开销换来的运动效率绝对是值得的。
> > > 当然，要跨平台，要做WEB，那是另一回事了。C/C++也不是为WEB设计的。
>
> > > *Will Zhang:*
> > > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
> > > 事实上，有许多"高深"的功能C++已经使用了。
> > > 比如垃圾回收。你用C++开发大型项目的时候，经常会想到要做一个垃圾回收。
>
> > > 我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
> > > 然后想到，或许这种东西的使用应该更普遍，然后就开发了另一种语言。：）这个随便说说。
>
> > > *Siney:
> > > *在07-11-23，Will Zhang <lala.willzh...@gmail.com> 写道：
>
> > > > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
> > > 这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
> > > 通过ecx传递好像也只是ms的编译器的做法，而非标准规定，gcc我不清楚，不过即使是想通过寄存器来传递，c也可以申明register吧。
>
> > > *最后，我觉得这个问题应该这样来提问：
>
> > > 1. 目前C++的应用领域是哪些（要精确）。
> > > 2. 目前C++所占领的领域，是因为非C++不可，还是因为政治或历史原因？（逐个分析）
> > > 3.
>

> > 这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing...--）），为什么。

> > > 4. C++独一无二（不可取代）的优势到底是什么？
>
> > > 其实，以上的问题内可以把C++换成任意一门其他语言。
> > > *
>

> > 最后说说我的观点：以往，人们普遍认为C++的独一无二的优势是效率。而C为什么不更好呢？C同样效率且语言模型更简单。但语言模型更简单并不代表用该语言编程--就更简单。OB/OO/GP是已经被实践证明的有效范式（虽然OO的定义似乎从来就没有明确过，但OB至少还是可以谈论的），如果没有first-class-支-持，而又要用到的话，就很难搞了。也就是说，当"鱼（first-class的范式支持）我所欲也；熊掌（效率）亦我所欲也"的时候，也就只剩下C++这个-选手-了。为此用C++编程的人宁可仍受各种各样的非本质复杂性，因为与刚才那两个需求相比，这些非本质复杂性至少是可以克服的。
>
> > 以上这个论点建立在一个前提之上，及C++的某些特点导致了它的高效。什么特点？接近机器的抽象模型。（OO的实现方式，GP的实现方式）这使得语言在实现高级--编程范式的时候做到了零惩罚（中间层几乎被削减到无）。这个零惩罚当然是有代价的（昂贵的代价），比如GP在C++中的实现就并非是"运行期+非绑定"的（r-u-by的是）。
>
> > 而这个前提又建立在另一个前提之上，也就是：传统的程序是通过减少抽象惩罚来最大化执行效率的。这才使得C++这种语言实现抽象惩罚最小的语言在一些领域成为独--一无二的选择。

>
> > > 那么，我们来看最后这一个前提到了并发时代还能满足吗？
>
> > > 显然，通过减少抽象惩罚而获得的效率提升跟通过提高并发程度获得的效率提升一比就微不足道了。
>
> > > 以上论点的前提是：该程序必须要能够并行化到一定程度。如果本质上决定了必须要串行执行或者并行化带来的收效甚微，那就白搭了。
>

> > 于是，要证明C++的优势在并发时代会消失。我们只需证明，目前C++应用领域中的主体软件，是可以通过并行化来提到一个非平凡的效率的，这个非平凡的效率提升--将使得通过减少抽象惩罚来获得的效率提升变得微不足道。

>
> > > 例如，传统上，图像处理和游戏被认为是C++的经典领域，但考虑到并发，这个领域还能保留吗？这两个领域可都是能够高度并发的。
>
> > > 我觉得这个结论基本就不需要证明了。
>
> > > 好，如果这个结论成立。那么随之就带来了一个重要推论：
>

> > 原来C++是为了减少抽象惩罚从而在语言的抽象模型上做了很大的折中（比如前面提到的GP的实现），本来这个折中是个优点，因为它换来了效率。而现在突然换不到--效率了，那就立即变成了大大的缺点。如果同样都能获得效率，难道不是用更自然的ruby更让人舒服吗？

>
> > > 回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的
> > > 决策是：通过实现零惩罚的抽象（OO、GP），来达到效率+抽象兼得的目的。而这个决策，在当前的背景下，由一个优点，变成了一个缺点，因为它折中了抽
> > > 象。如果我们不再需要通过零惩罚的抽象类来获得效率，"零惩罚的抽象"所带来的结果就只是不友好的编程范式。
>
> > 有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。
>
> > > 剩下的问题是：
>
> > > 那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）
>
> > > 也许是有的，我可以列出两点：
>
> > > 1. 直接操纵硬件。
> > > 2. 静态类型系统。
>

> > 第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用--什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又-具-有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
>
> ...
>
> 阅读更多 >>- 隐藏被引用文字 -
>
> - 显示引用的文字 -

[莫华枫]

vc team目前很重要的一个任务就是使得managed和native的类型可以交叉使用。这一点sutter承诺过，lippman也提到过。实际上两种内存的差别在于对象模型，而不是内存本身。ms可能已经通过修改对象模型，在c++的标准下统一两种模型。
managed内存对于native实际上是开放的。我曾经将一个数组pin住，指针传给win32 api，照样可以正常工作。
.net平台本身存在不少缺陷，开放度不够，没有扩展余地。ms不可能在未来长期的发展中，完全绑死在这么一棵树上。.net是同java对抗的结果，而不是技术发展的结果。从长远来看，.net无法支撑未来将会出现的新一代编程技术。.net很可能也只是一个过渡，ms总会不时地冒出一个新东西，然后驱赶人们进去。然后在哪一天躯干人们进入另一个东西。
在技术方面，ms往往是迟钝和落后的。这取决于他的商业性，激进的技术往往是商业的死敌。商业要求稳定，可靠。但ms往往缺乏前瞻性，思维的任意性很强，经常使得众多程序员跟着他误入歧途。

[shark]

SSE用到的地方挺多的，Mplayer里面就有。
其次，ICC,IFORT,GCC,G++,GFORTRAN都有auto-vectorize的能力。
Intel为了推广SSE,已经搞了不少东西了，除了直接内嵌汇编，还可以用intrisnic, intel提供的vector类，再懒点的可以把循环写清晰些去让编译器自己搞。

[pongba]

On Nov 29, 2007 10:45 PM, Jian Wang <oxygen.j...@gmail.com> wrote:

> 主要是理性分析，有批评也是理性的批评。
> 理由我已经在第一篇帖子里面陈述得很清楚了，感觉真正看的人很少，因为除了莫兄基本没有人对我的想法提出具体的意见。也许我没有说清楚什么是"通过折衷抽象模型来获得效率"？

楼上的发言我很仔细的阅读了。
"通过折衷抽象模型来获得效率"的意思也说的很清楚。

从长期来看，随着硬件的发展，抽象程度必然会越来越高。为了效率而折衷的模型必定会被淘汰。C++不光有为了效率的折衷，还有承重的历史包袱。我希望能有新的语言出来顶替C++的位置。

呵呵，我倒是希望C++会进化出（脱胎换骨的）新版本。Bjarne说迟早要通过不兼容版本之间的源代码转换来支持脱胎换骨式的进化的:-)
 

但是从短期来看，多核的出现反而会降低抽象。

是的，短期似乎的确如此。比如昨天看到这篇关于concurrent haskell的：
http://cgi.cse.unsw.edu.au/~dons/blog/2007/11/29#smoking
 

比如说现在的编程语言基本上把内存和CPU都抽象掉了。
但是核的增加会使得统一内存模型无以为继。每个核都会有自己的本地内存。这样的话，为了利用多个核，就必须把内存模型暴露给程序员。

这个就未必了。编程模型仍然可以抽象掉CPU的概念。只需要暴露"多个执行线程"这一抽象即可。不管是通过Message Passing还是通过Shared-State都可以。虽然暴露了多个执行线程这个抽象也可说是弱点（因为人脑习惯的似乎是单线程），但目前隐式并行化的编译技术仿佛没有啥进展。说不得也只能借助ErLang或STM这样的技术来简化并发编程了。

[pongba]

On Nov 29, 2007 11:35 PM, SevenCat <BastE...@gmail.com> wrote:

我一直认为多核这个东东对普通程序员来说意义不大，我们最多做到多线程编程就可以了，而这是老早就成熟了的技术。

 
从一个意义上讲，的确如此。多线程编程已经存在了N年，可以说早就"成熟"了。
然而从另一个意义上讲，基于锁的多线程编程（乃至于erlang那样的基于message-passing的）都从来没有达到过真正使多线程编程达到他应该达到的容易程度（即消除不必要的非本质复杂性）。基于锁的多线程编程有诸多问题：过细、过粗的锁、死锁、优先级倒置、忘记加锁。。。这些全都是非本质复杂性。只不过人都有一种心理，就是只要suffice（足够用），那就satisfactory（满足）了，逐渐也就忽略了这些非本质复杂性，当成"本就该那样的"。另一个典型的例子就是C++程序员对C++中各种非本质复杂性的适应。
但实际上呢？远非如此，否则Lock-Free算法也不会出现，STM也不会出现，Map/Reduce也不会出现。这些东东虽然都不是银弹，但本来就不是要银弹，只要能一定程度上简化问题，消除非本质复杂性，减小程序员不必要的精力消耗，就达到目的了。

[pongba]

On Nov 30, 2007 8:52 AM, 王磊 <wangle...@gmail.com> wrote:

一门语言何必遭到这么多的批判评价和指责呢？还是大家对他的关心超过了应有的程度。

任何语言都可以实现的东西我们就把他当作一天路，适合就走，不适合就换。

 

多做做项目，就会知道，没有考虑语言好坏的权利。

 

D语言会是新的霸主？乱世阿~

我们就是在讨论"适合不适合"、"什么时候才是适合的"不是么？
此外，项目中总会有人去选择语言的，如果有一天你也需要自己去选择的话，权衡哪种语言最合适难道不是重要的？
再说，没有看到reddit上前阵子总有：Why Learning XXX (e.g. Python) make me a good XXX (e.g. C++) Programmer这样的帖子？
当一个人只熟悉一门语言，并且只熟悉这门语言可以做什么事情的时候，就会很容易坠入一种因这门语言"能够做到某事"从而觉得它"是做某事的最佳方式"的心理陷阱。所以我的感觉是，理性的分析反面的因素是有必要的，（如果不也是有意思的话:-)）

一般我只讨论语言的某个特性，并不特定于哪门语言吧。

[王磊]

只是觉得c++这门安静的语言最近被风风火火的推上了政治舞台。

越来越多的人开始考虑c++的诸多特性是不适该被XXX或者被YYY。以后该被ZZZ。

 

可怜的c++。要是像 lisp 那样成为历史就好了。

 

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

On Nov 30, 2007 8:52 AM, 王磊 <wangle...@gmail.com> wrote:

一门语言何必遭到这么多的批判评价和指责呢？还是大家对他的关心超过了应有的程度。

任何语言都可以实现的东西我们就把他当作一天路，适合就走，不适合就换。

 

多做做项目，就会知道，没有考虑语言好坏的权利。

 

D语言会是新的霸主？乱世阿~
 

我们就是在讨论"适合不适合"、"什么时候才是适合的"不是么？
此外，项目中总会有人去选择语言的，如果有一天你也需要自己去选择的话，权衡哪种语言最合适难道不是重要的？

再说，没有看到reddit上前阵子总有：Why Learning XXX (e.g. Python) make me a good XXX ( e.g. C++) Programmer这样的帖子？

[pongba]

On Nov 30, 2007 11:41 AM, 王磊 <wangle...@gmail.com> wrote:

只是觉得c++这门安静的语言最近被风风火火的推上了政治舞台。

越来越多的人开始考虑c++的诸多特性是不适该被XXX或者被YYY。以后该被ZZZ。

 

可怜的c++。要是像 lisp 那样成为历史就好了。

啊哈哈，该来的总是要来的。一门语言刚出现的时候，就着新鲜劲儿，人们基本都只会看其好处，以及解决了旧有语言的哪些缺点。
当时间足够长了，真正应用了很久了，像C++这种，缺陷就会逐渐暴露出来（没有哪个设计者能够预料将来所有情况的不是？），这个时候，就是下神坛的时候了:-) 没有什么不好的，弃旧迎新嘛，再说我还是对C++有信心的，毕竟B老大也说了，总会通过versioning来脱胎换骨的:-) 此外，并发对C++造成的影响，我也根本不知道什么时候才会真正到来:-) 不过不影响看看趋势嘛。

Lisp也没成为历史啊，Lisp这不在Haskell中得到重生了嘛。而且，Common Lisp最近还是蛮火的。总有一小撮Geeks会推崇或偏门或巴洛克语言的，也是一种心理作祟。君不见Lispers们也其实都喜欢像C++ers那样戴着脚铐跳舞，用Lisp模拟出各种各样的语言特性？还有Ruby社群，这个趋势也开始愈发明显了。

[SevenCat]

这些锁你用得到吗？
lock_free算法也不是现在就有的，MS的内部有个常用的链表就是lock free的。我也见到过一个内存分配器，也是lock free的，
也没有用太多复杂的技巧。在99%的场合，目前的锁都够用了吧。

On Nov 30, 11:27 am, pongba <pon...@gmail.com> wrote:

> On Nov 29, 2007 11:35 PM, SevenCat <BastEt.W...@gmail.com> wrote:
>
> > 我一直认为多核这个东东对普通程序员来说意义不大，我们最多做到多线程编程就可以了，而这是老早就成熟了的技术。
>
> 从一个意义上讲，的确如此。多线程编程已经存在了N年，可以说早就"成熟"了。

> 然而从另一个意义上讲，基于锁的多线程编程（乃至于erlang那样的基于message-passing的）都从来没有达到过真正使多线程编程达到他应该达到-的容易程度（即消除不必要的非本质复杂性）。基于锁的多线程编程有诸多问题：过细、过粗的锁、死锁、优先级倒置、忘记加锁。。。这些全都是非本质复杂性。只不过-人都有一种心理，就是只要suffice（足够用），那就satisfactory（满足）了，逐渐也就忽略了这些非本质复杂性，当成"本就该那样的"。另一个-典型的例子就是C++程序员对C++中各种非本质复杂性的适应。
> 但实际上呢？远非如此，否则Lock-Free算法也不会出现，STM也不会出现，Map/Reduce也不会出现。这些东东虽然都不是银弹，但本来就不是要银-弹，只要能一定程度上简化问题，消除非本质复杂性，减小程序员不必要的精力消耗，就达到目的了。

[SevenCat]

在细锁上面，CRITICALSECTION的效率足够满足应用层大部分的应用，我不知道有多少人碰到过写应用层的时候CS也无法满足效率的情况。

On Nov 30, 11:49 am, SevenCat <BastEt.W...@gmail.com> wrote:
> 这些锁你用得到吗？
> lock_free算法也不是现在就有的，MS的内部有个常用的链表就是lock free的。我也见到过一个内存分配器，也是lock free的，
> 也没有用太多复杂的技巧。在99%的场合，目前的锁都够用了吧。
>
> On Nov 30, 11:27 am, pongba <pon...@gmail.com> wrote:
>
>
>
> > On Nov 29, 2007 11:35 PM, SevenCat <BastEt.W...@gmail.com> wrote:
>
> > > 我一直认为多核这个东东对普通程序员来说意义不大，我们最多做到多线程编程就可以了，而这是老早就成熟了的技术。
>
> > 从一个意义上讲，的确如此。多线程编程已经存在了N年，可以说早就"成熟"了。

> > 然而从另一个意义上讲，基于锁的多线程编程（乃至于erlang那样的基于message-passing的）都从来没有达到过真正使多线程编程达到他应该达到--的容易程度（即消除不必要的非本质复杂性）。基于锁的多线程编程有诸多问题：过细、过粗的锁、死锁、优先级倒置、忘记加锁。。。这些全都是非本质复杂性。只不-过-人都有一种心理，就是只要suffice（足够用），那就satisfactory（满足）了，逐渐也就忽略了这些非本质复杂性，当成"本就该那样的"。另-一个-典型的例子就是C++程序员对C++中各种非本质复杂性的适应。
> > 但实际上呢？远非如此，否则Lock-Free算法也不会出现，STM也不会出现，Map/Reduce也不会出现。这些东东虽然都不是银弹，但本来就不是要银--弹，只要能一定程度上简化问题，消除非本质复杂性，减小程序员不必要的精力消耗，就达到目的了。
>
> > --
> > 刘未鹏(pongba)|C++的罗浮宫http://blog.csdn.net/pongba
> > TopLanguagehttp://groups.google.com/group/pongba- Hide quoted text -
>
> - Show quoted text -

[shark]

比如矩阵插值，最好是硬件原子锁

[Yong Yuan]

嗯，模拟又不是什么好事。每次哪门语言加入类的支持，总有用Lisp的人跳出来说其实高端函数就够了。问题是，放不方便啊？函数模拟OO就好比用OO模拟函数，虽说二者基本等价，但用上去感觉就是不一样。这次es4新特性出来，好多人都说类没有必要。其实呢，没有类的结果就是出现各种互不兼容模拟的类的框架。

[莫华枫]

现在的这种格局让我感觉就像罗马帝国崩溃之后的中世纪。各种民族不断兴起，但还处在黑暗时代，等待着文艺复兴的到来。:)

[pongba]

On Nov 30, 2007 11:52 AM, SevenCat <BastE...@gmail.com> wrote:

在细锁上面，CRITICALSECTION的效率足够满足应用层大部分的应用，我不知道有多少人碰到过写应用层的时候CS也无法满足效率的情况。

套用Linus的话，非本质复杂性是"思想包袱"啊。再套用Joe Sposky的话，"抽象漏洞"啊。多线程的应用出了篓子debug的时间可比出内存问题还要大吧。
关于Critical-Section的一个抽象漏洞问题：
http://blogs.msdn.com/sloh/archive/2005/05/27/422605.aspx
如果遇到的话，可叫程序员怎么办啊。。。

[pongba]

On Nov 30, 2007 12:06 PM, Yong Yuan <y...@cs.toronto.edu> wrote:

嗯，模拟又不是什么好事。每次哪门语言加入类的支持，总有用Lisp的人跳出来说其实高端函数就够了。问题是，放不方便啊？函数模拟OO就好比用OO模拟函数，虽说二者基本等价，但用上去感觉就是不一样。这次es4新特性出来，好多人都说类没有必要。其实呢，没有类的结果就是出现各种互不兼容模拟的类的框架。

搞不好Fowler同学鼓吹DSL/Language-Oriented Programming也有这个动机在里头。一门语言再支持多少范式，都只是针对当前的应用需求的，甚至只针对部分领域的需求的。连OO都被Armstrong骂个狗血淋头，别说别的范式了。而LOP的牛逼就在于它是终极范式支持，支持一个定义语言的语言，于是DSL的设计就相当于我们熟悉的API设计了，要什么菜自己炒一个就得了:-)

BTW. 其实我感觉带着脚镣跳舞是大家都喜欢做的事情。一门语言出现，大家逐渐熟悉，然后把这门语言的所有特性（好的坏的）都当成背景了，当成理所当然了。这个时候能够打破旧时代，在现有框架下捣鼓出新东西的人，就能赢得众多目光:-) （《Modern C++ Design》可不就是这个例子）而我也得承认，当年我也是如此，当你原本以为一门语言就只有这点东西的时候，突然有人告诉你，嘿，N特性和M特性还能组合，实现XX功能，那叫兴奋啊。殊不知，在其他地方XX特性早就是first-class支持了。所以，真正应该的思维方式是站在一个决不妥协的程序员角度去思考，"俺到底想要实现什么，俺需要什么样的语言特性才能够直接达到目的，而不用去管什么非本质复杂性（缺陷、陷阱）啥的"。

还有更可怕的是，当一个人熟悉一门语言之后，这门语言就变得不再是一门工具，而是一门信仰。因为学习语言的代价比起学习用榔头可大多了。尤其是，代价越大，这个信仰越强烈，Java社群信仰为什么也大，因为大家虽然不学Java语言本身，但有无穷无尽的框架（EverFramework？）。谁也不希望自己花大代价学的东西被否定。于是有色眼镜戴起来，防卫姿势摆起来，就开始FlameWar了:P

[pongba]

On Nov 30, 2007 8:58 AM, buhongbo <buho...@gmail.com> wrote:

就是，就是。我总觉得莫总和pangba讨论的东西太玄了！有点像历史书上讲的那些士人清谈！

这个，误会我还是要答复的:-)
我讨论的正是C++里面无比实际的问题啊，玄在哪了？
1. 我们不能修改C++语言的设计，不代表我们不能去认识其缺点，从而更理性地区运用它。
2. 我们讨论的都是C++实际的缺点，而不是玄而又玄的东西。
3. 我的观点其实非常简单。就是C++以前以折衷抽象模型换取了效率，值得，但到了并发时代就未必值得了。什么是折衷抽象模型，为什么template不是最自然的设计，我在回帖里面似乎解释过了。

[怀宇范]

赞成。。。
在C++擅长的领域。C++还没有一个真正够分量的对手。也就是，我们没有其他更好的选择。

--
bool ContactMe(person you)
{
   if(you.GoTo("14#344, Tsinghua") && you.Find("Fan Huaiyu"))return true;
   if(you.MailTo (" dugu...@gmail.com ") || you.MailTo(" fan...@mails.tsinghua.edu.cn "))return true;
   if(you.PhoneTo ("13488810330") || you.PhoneTo("01062778689"))return true;
   if(you.QQTo("120628812") || you.MSNTo("dugu...@hotmail.com"))return true;
   if(you.NetTo(" www.cnblogs.com/duguguiyu "))return true;
   return false;
}

[SevenCat]

说实话，我不太理解你的这个回复，我说的是起码绝大部分的锁都可以用CS完成，你提到的只是一个很特别的情况，我相信我们中的绝大部分人都不会碰到。即
使碰到我也会想办法去解决。除了CS，你还用其他什么类型的细锁，在win用户平台下面？在linux平台下你也没有太多的选择。


On Nov 30, 12:10 pm, pongba <pon...@gmail.com> wrote:

[red...@gmail.com]

SevenCat 写道:

> 说实话，我不太理解你的这个回复，我说的是起码绝大部分的锁都可以用CS完成，你提到的只是一个很特别的情况，我相信我们中的绝大部分人都不会碰到。即
> 使碰到我也会想办法去解决。除了CS，你还用其他什么类型的细锁，在win用户平台下面？在linux平台下你也没有太多的选择。
>
>

Linux 平台的细锁可以用 futex, fast userspace locking system call.
不过我还没有用过, API 很低级的样子.

[SevenCat]

pthread新版中的mutex就是用futex实现的，这个大概只有2.6内核才支持，edonkey的作者曾经说过他受益于这个锁。假如用了
pthread_mutex,你也许已经用了futex了。

[pongba]

On Dec 3, 2007 10:01 PM, SevenCat <BastE...@gmail.com> wrote:

说实话，我不太理解你的这个回复，我说的是起码绝大部分的锁都可以用CS完成，你提到的只是一个很特别的情况，我相信我们中的绝大部分人都不会碰到。即
使碰到我也会想办法去解决。除了CS，你还用其他什么类型的细锁，在win用户平台下面？在linux平台下你也没有太多的选择。

我认同你的这个判断。而我说的正是除了那些之外的小部分情况（好吧，也许是"极小部分"）。之所以引用Joel的"抽象渗漏法则"就是为了说明，小部分情况下的问题可能会带来大部分的头疼，进而分野了那些"高手"和"低手"（所谓的高手往往就是那些能在遇到抽象漏洞时快速解决问题的人）。举个例子，vector::operator[]曾被人抨击说应该和vector::at()对调（后者有check），从而避免误用[]带来的头大。（当然，[]的正确/错误使用比例和锁的正确/错误使用比例也许有差别，但idea是差不多的）

[SevenCat]

其实有可能碰到的，而且头痛的可能不是你说的这个，而是锁太多了，有时候出现的一些情况，另外在很少的情况下，这个函数会抛MS异常，所以MS在ATL
库里把这个相关函数用　__try了。

On Dec 3, 10:50 pm, pongba <pon...@gmail.com> wrote:

> On Dec 3, 2007 10:01 PM, SevenCat <BastEt.W...@gmail.com> wrote:
>
> > 说实话，我不太理解你的这个回复，我说的是起码绝大部分的锁都可以用CS完成，你提到的只是一个很特别的情况，我相信我们中的绝大部分人都不会碰到。即
> > 使碰到我也会想办法去解决。除了CS，你还用其他什么类型的细锁，在win用户平台下面？在linux平台下你也没有太多的选择。
>

> 我认同你的这个判断。而我说的正是除了那些之外的小部分情况（好吧，也许是"极小部分"）。之所以引用Joel的"抽象渗漏法则"就是为了说明，小部分情况下的-问题可能会带来大部分的头疼，进而分野了那些"高手"和"低手"（所谓的高手往往就是那些能在遇到抽象漏洞时快速解决问题的人）。举个例子，vector::o-perator[]曾被人抨击说应该和vector::at()对调（后者有check），从而避免误用[]带来的头大。（当然，[]的正确/错误使用比例和锁-的正确/错误使用比例也许有差别，但idea是差不多的）

[SevenCat]

但目前还没有好办法，因为这基本属于逻辑和OS层的，不是什么语法层简单能解决的。

On Dec 3, 10:50 pm, pongba <pon...@gmail.com> wrote:

> On Dec 3, 2007 10:01 PM, SevenCat <BastEt.W...@gmail.com> wrote:
>
> > 说实话，我不太理解你的这个回复，我说的是起码绝大部分的锁都可以用CS完成，你提到的只是一个很特别的情况，我相信我们中的绝大部分人都不会碰到。即
> > 使碰到我也会想办法去解决。除了CS，你还用其他什么类型的细锁，在win用户平台下面？在linux平台下你也没有太多的选择。
>

> 我认同你的这个判断。而我说的正是除了那些之外的小部分情况（好吧，也许是"极小部分"）。之所以引用Joel的"抽象渗漏法则"就是为了说明，小部分情况下的-问题可能会带来大部分的头疼，进而分野了那些"高手"和"低手"（所谓的高手往往就是那些能在遇到抽象漏洞时快速解决问题的人）。举个例子，vector::o-perator[]曾被人抨击说应该和vector::at()对调（后者有check），从而避免误用[]带来的头大。（当然，[]的正确/错误使用比例和锁-的正确/错误使用比例也许有差别，但idea是差不多的）

[bipe...@gmail.com]

In my opinion, the power of community is the life line of a
programming language.

> > 我做的是视频编码，这个方向是明显的计算密集性工作，实时性压倒一切。除了汇编语言外，C/C++是唯一能接受的高级语言。而且C/C++对系统资源的使用，如-内存的使用，有非常明显的可控制性。这在对资源要求很严格的情况下C/C++也是优先选择。从这个角度看，视频压缩和图形图像处理，实时系统处理领域里，短期内-还不会有能代替C/C++的语言。

> > 另外，说C/C++的编译时间问题，可以想到的是相对运行时间，编码时间的开销换来的运动效率绝对是值得的。
> > 当然，要跨平台，要做WEB，那是另一回事了。C/C++也不是为WEB设计的。
>
> > *Will Zhang:*
> > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
> > 事实上，有许多"高深"的功能C++已经使用了。
> > 比如垃圾回收。你用C++开发大型项目的时候，经常会想到要做一个垃圾回收。
>
> > 我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
> > 然后想到，或许这种东西的使用应该更普遍，然后就开发了另一种语言。：）这个随便说说。
>
> > *Siney:
> > *在07-11-23，Will Zhang <lala.willzh...@gmail.com> 写道：
>
> > > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
> > 这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
> > 通过ecx传递好像也只是ms的编译器的做法，而非标准规定，gcc我不清楚，不过即使是想通过寄存器来传递，c也可以申明register吧。
>
> > *最后，我觉得这个问题应该这样来提问：
>
> > 1. 目前C++的应用领域是哪些（要精确）。
> > 2. 目前C++所占领的领域，是因为非C++不可，还是因为政治或历史原因？（逐个分析）
> > 3.

> > 这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing...-）），为什么。

> > 4. C++独一无二（不可取代）的优势到底是什么？
>
> > 其实，以上的问题内可以把C++换成任意一门其他语言。
> > *

> > 最后说说我的观点：以往，人们普遍认为C++的独一无二的优势是效率。而C为什么不更好呢？C同样效率且语言模型更简单。但语言模型更简单并不代表用该语言编程-就更简单。OB/OO/GP是已经被实践证明的有效范式（虽然OO的定义似乎从来就没有明确过，但OB至少还是可以谈论的），如果没有first-class支-持，而又要用到的话，就很难搞了。也就是说，当"鱼（first-class的范式支持）我所欲也；熊掌（效率）亦我所欲也"的时候，也就只剩下C++这个选手-了。为此用C++编程的人宁可仍受各种各样的非本质复杂性，因为与刚才那两个需求相比，这些非本质复杂性至少是可以克服的。
>
> > 以上这个论点建立在一个前提之上，及C++的某些特点导致了它的高效。什么特点？接近机器的抽象模型。（OO的实现方式，GP的实现方式）这使得语言在实现高级-编程范式的时候做到了零惩罚（中间层几乎被削减到无）。这个零惩罚当然是有代价的（昂贵的代价），比如GP在C++中的实现就并非是"运行期+非绑定"的（ru-by的是）。
>
> > 而这个前提又建立在另一个前提之上，也就是：传统的程序是通过减少抽象惩罚来最大化执行效率的。这才使得C++这种语言实现抽象惩罚最小的语言在一些领域成为独-一无二的选择。

>
> > 那么，我们来看最后这一个前提到了并发时代还能满足吗？
>
> > 显然，通过减少抽象惩罚而获得的效率提升跟通过提高并发程度获得的效率提升一比就微不足道了。
>
> > 以上论点的前提是：该程序必须要能够并行化到一定程度。如果本质上决定了必须要串行执行或者并行化带来的收效甚微，那就白搭了。
>

> > 于是，要证明C++的优势在并发时代会消失。我们只需证明，目前C++应用领域中的主体软件，是可以通过并行化来提到一个非平凡的效率的，这个非平凡的效率提升-将使得通过减少抽象惩罚来获得的效率提升变得微不足道。

>
> > 例如，传统上，图像处理和游戏被认为是C++的经典领域，但考虑到并发，这个领域还能保留吗？这两个领域可都是能够高度并发的。
>
> > 我觉得这个结论基本就不需要证明了。
>
> > 好，如果这个结论成立。那么随之就带来了一个重要推论：
>

> > 原来C++是为了减少抽象惩罚从而在语言的抽象模型上做了很大的折中（比如前面提到的GP的实现），本来这个折中是个优点，因为它换来了效率。而现在突然换不到-效率了，那就立即变成了大大的缺点。如果同样都能获得效率，难道不是用更自然的ruby更让人舒服吗？

>
> > 回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的
> > 决策是：通过实现零惩罚的抽象（OO、GP），来达到效率+抽象兼得的目的。而这个决策，在当前的背景下，由一个优点，变成了一个缺点，因为它折中了抽
> > 象。如果我们不再需要通过零惩罚的抽象类来获得效率，"零惩罚的抽象"所带来的结果就只是不友好的编程范式。
>
> > 有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。
>
> > 剩下的问题是：
>
> > 那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）
>
> > 也许是有的，我可以列出两点：
>
> > 1. 直接操纵硬件。
> > 2. 静态类型系统。
>

> > 第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用-什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具-有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
>
> > 第二点的优势目前我也不特别肯定。静态类型系统，众所周知，有助于尽早发现问题。动态语言为了"动"起来，其实也折中了静态类型系统的优点，导致了一些批评（比-如ruby的ducktyping需要concept）。但我的看法是，ruby如果能够加上一定的静态类新成分，再加上程序自动验证领域的进展，最终会弥补这-个缺陷。但这方面我也不是很了解，所以留给了解的人评说。
>
> ...
>
> 阅读更多 >>

[Linker M Lin]

有一个领域:
需要保证软件算法核心机密的软件.
比如 Autodesk公司的系列软件.
如果用C#/Java来写,怕是太容易被反编译.


On Nov 27, 7:59 pm, sean4y...@gmail.com wrote:
> c++把兼容性看的如此重要也是不想失去遗留代码领域的支持，话说，是不是进了标准库的东西就没法剔除了，c++倾向于用库来解决问题而不是语言进化，理由是库-方便进化，而兼容性。。。
>
> 在 07-11-27，liang<adamil...@gmail.com> 写道：

> > 我做的是视频编码，这个方向是明显的计算密集性工作，实时性压倒一切。除了汇编语言外，C/C++是唯一能接受的高级语言。而且C/C++对系统资源的使用，如--内存的使用，有非常明显的可控制性。这在对资源要求很严格的情况下C/C++也是优先选择。从这个角度看，视频压缩和图形图像处理，实时系统处理领域里，短期-内-还不会有能代替C/C++的语言。

> > > 另外，说C/C++的编译时间问题，可以想到的是相对运行时间，编码时间的开销换来的运动效率绝对是值得的。
> > > 当然，要跨平台，要做WEB，那是另一回事了。C/C++也不是为WEB设计的。
>
> > > *Will Zhang:*
> > > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
> > > 事实上，有许多"高深"的功能C++已经使用了。
> > > 比如垃圾回收。你用C++开发大型项目的时候，经常会想到要做一个垃圾回收。
>
> > > 我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
> > > 然后想到，或许这种东西的使用应该更普遍，然后就开发了另一种语言。：）这个随便说说。
>
> > > *Siney:
> > > *在07-11-23，Will Zhang <lala.willzh...@gmail.com> 写道：
>
> > > > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
> > > 这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
> > > 通过ecx传递好像也只是ms的编译器的做法，而非标准规定，gcc我不清楚，不过即使是想通过寄存器来传递，c也可以申明register吧。
>
> > > *最后，我觉得这个问题应该这样来提问：
>
> > > 1. 目前C++的应用领域是哪些（要精确）。
> > > 2. 目前C++所占领的领域，是因为非C++不可，还是因为政治或历史原因？（逐个分析）
> > > 3.
>

> > 这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing...--）），为什么。

> > > 4. C++独一无二（不可取代）的优势到底是什么？
>
> > > 其实，以上的问题内可以把C++换成任意一门其他语言。
> > > *
>

> > 最后说说我的观点：以往，人们普遍认为C++的独一无二的优势是效率。而C为什么不更好呢？C同样效率且语言模型更简单。但语言模型更简单并不代表用该语言编程--就更简单。OB/OO/GP是已经被实践证明的有效范式（虽然OO的定义似乎从来就没有明确过，但OB至少还是可以谈论的），如果没有first-class-支-持，而又要用到的话，就很难搞了。也就是说，当"鱼（first-class的范式支持）我所欲也；熊掌（效率）亦我所欲也"的时候，也就只剩下C++这个-选手-了。为此用C++编程的人宁可仍受各种各样的非本质复杂性，因为与刚才那两个需求相比，这些非本质复杂性至少是可以克服的。
>
> > 以上这个论点建立在一个前提之上，及C++的某些特点导致了它的高效。什么特点？接近机器的抽象模型。（OO的实现方式，GP的实现方式）这使得语言在实现高级--编程范式的时候做到了零惩罚（中间层几乎被削减到无）。这个零惩罚当然是有代价的（昂贵的代价），比如GP在C++中的实现就并非是"运行期+非绑定"的（r-u-by的是）。
>
> > 而这个前提又建立在另一个前提之上，也就是：传统的程序是通过减少抽象惩罚来最大化执行效率的。这才使得C++这种语言实现抽象惩罚最小的语言在一些领域成为独--一无二的选择。
>

> > > 那么，我们来看最后这一个前提到了并发时代还能满足吗？
>
> > > 显然，通过减少抽象惩罚而获得的效率提升跟通过提高并发程度获得的效率提升一比就微不足道了。
>
> > > 以上论点的前提是：该程序必须要能够并行化到一定程度。如果本质上决定了必须要串行执行或者并行化带来的收效甚微，那就白搭了。
>

> > 于是，要证明C++的优势在并发时代会消失。我们只需证明，目前C++应用领域中的主体软件，是可以通过并行化来提到一个非平凡的效率的，这个非平凡的效率提升--将使得通过减少抽象惩罚来获得的效率提升变得微不足道。

>
> > > 例如，传统上，图像处理和游戏被认为是C++的经典领域，但考虑到并发，这个领域还能保留吗？这两个领域可都是能够高度并发的。
>
> > > 我觉得这个结论基本就不需要证明了。
>
> > > 好，如果这个结论成立。那么随之就带来了一个重要推论：
>

> > 原来C++是为了减少抽象惩罚从而在语言的抽象模型上做了很大的折中（比如前面提到的GP的实现），本来这个折中是个优点，因为它换来了效率。而现在突然换不到--效率了，那就立即变成了大大的缺点。如果同样都能获得效率，难道不是用更自然的ruby更让人舒服吗？

>
> > > 回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的
> > > 决策是：通过实现零惩罚的抽象（OO、GP），来达到效率+抽象兼得的目的。而这个决策，在当前的背景下，由一个优点，变成了一个缺点，因为它折中了抽
> > > 象。如果我们不再需要通过零惩罚的抽象类来获得效率，"零惩罚的抽象"所带来的结果就只是不友好的编程范式。
>
> > > 有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。
>
> > > 剩下的问题是：
>
> > > 那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）
>
> > > 也许是有的，我可以列出两点：
>
> > > 1. 直接操纵硬件。
> > > 2. 静态类型系统。
>

> > 第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用--什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又-具-有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
>
> ...
>

> read more >>- Hide quoted text -

[Linker M Lin]

另外,最近尝试了一下OpenMP,觉得是一个不错的东东.
在未来多核心的环境里,OpenMP是低强度并发的首选.

On Dec 5, 4:23 pm, Linker M Lin <Linker.M....@gmail.com> wrote:
> 有一个领域:
> 需要保证软件算法核心机密的软件.
> 比如 Autodesk公司的系列软件.
> 如果用C#/Java来写,怕是太容易被反编译.
>
> On Nov 27, 7:59 pm, sean4y...@gmail.com wrote:
>
>
>

> > c++把兼容性看的如此重要也是不想失去遗留代码领域的支持，话说，是不是进了标准库的东西就没法剔除了，c++倾向于用库来解决问题而不是语言进化，理由是库--方便进化，而兼容性。。。

> > > 我做的是视频编码，这个方向是明显的计算密集性工作，实时性压倒一切。除了汇编语言外，C/C++是唯一能接受的高级语言。而且C/C++对系统资源的使用，如---内存的使用，有非常明显的可控制性。这在对资源要求很严格的情况下C/C++也是优先选择。从这个角度看，视频压缩和图形图像处理，实时系统处理领域里，短-期-内-还不会有能代替C/C++的语言。

> > > > 另外，说C/C++的编译时间问题，可以想到的是相对运行时间，编码时间的开销换来的运动效率绝对是值得的。
> > > > 当然，要跨平台，要做WEB，那是另一回事了。C/C++也不是为WEB设计的。
>
> > > > *Will Zhang:*
> > > > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
> > > > 事实上，有许多"高深"的功能C++已经使用了。
> > > > 比如垃圾回收。你用C++开发大型项目的时候，经常会想到要做一个垃圾回收。
>
> > > > 我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
> > > > 然后想到，或许这种东西的使用应该更普遍，然后就开发了另一种语言。：）这个随便说说。
>
> > > > *Siney:
> > > > *在07-11-23，Will Zhang <lala.willzh...@gmail.com> 写道：
>
> > > > > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
>
> > > > 这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
> > > > 通过ecx传递好像也只是ms的编译器的做法，而非标准规定，gcc我不清楚，不过即使是想通过寄存器来传递，c也可以申明register吧。
>
> > > > *最后，我觉得这个问题应该这样来提问：
>
> > > > 1. 目前C++的应用领域是哪些（要精确）。
> > > > 2. 目前C++所占领的领域，是因为非C++不可，还是因为政治或历史原因？（逐个分析）
> > > > 3.
>

> > > 这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing...---）），为什么。

> > > > 4. C++独一无二（不可取代）的优势到底是什么？
>
> > > > 其实，以上的问题内可以把C++换成任意一门其他语言。
> > > > *
>

> > > 最后说说我的观点：以往，人们普遍认为C++的独一无二的优势是效率。而C为什么不更好呢？C同样效率且语言模型更简单。但语言模型更简单并不代表用该语言编程---就更简单。OB/OO/GP是已经被实践证明的有效范式（虽然OO的定义似乎从来就没有明确过，但OB至少还是可以谈论的），如果没有first-clas-s-支-持，而又要用到的话，就很难搞了。也就是说，当"鱼（first-class的范式支持）我所欲也；熊掌（效率）亦我所欲也"的时候，也就只剩下C++-这个-选手-了。为此用C++编程的人宁可仍受各种各样的非本质复杂性，因为与刚才那两个需求相比，这些非本质复杂性至少是可以克服的。
>
> > > 以上这个论点建立在一个前提之上，及C++的某些特点导致了它的高效。什么特点？接近机器的抽象模型。（OO的实现方式，GP的实现方式）这使得语言在实现高级---编程范式的时候做到了零惩罚（中间层几乎被削减到无）。这个零惩罚当然是有代价的（昂贵的代价），比如GP在C++中的实现就并非是"运行期+非绑定"的（-r-u-by的是）。
>
> > > 而这个前提又建立在另一个前提之上，也就是：传统的程序是通过减少抽象惩罚来最大化执行效率的。这才使得C++这种语言实现抽象惩罚最小的语言在一些领域成为独---一无二的选择。

>
> > > > 那么，我们来看最后这一个前提到了并发时代还能满足吗？
>
> > > > 显然，通过减少抽象惩罚而获得的效率提升跟通过提高并发程度获得的效率提升一比就微不足道了。
>
> > > > 以上论点的前提是：该程序必须要能够并行化到一定程度。如果本质上决定了必须要串行执行或者并行化带来的收效甚微，那就白搭了。
>

> > > 于是，要证明C++的优势在并发时代会消失。我们只需证明，目前C++应用领域中的主体软件，是可以通过并行化来提到一个非平凡的效率的，这个非平凡的效率提升---将使得通过减少抽象惩罚来获得的效率提升变得微不足道。

>
> > > > 例如，传统上，图像处理和游戏被认为是C++的经典领域，但考虑到并发，这个领域还能保留吗？这两个领域可都是能够高度并发的。
>
> > > > 我觉得这个结论基本就不需要证明了。
>
> > > > 好，如果这个结论成立。那么随之就带来了一个重要推论：
>

> > > 原来C++是为了减少抽象惩罚从而在语言的抽象模型上做了很大的折中（比如前面提到的GP的实现），本来这个折中是个优点，因为它换来了效率。而现在突然换不到---效率了，那就立即变成了大大的缺点。如果同样都能获得效率，难道不是用更自然的ruby更让人舒服吗？

>
> > > > 回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的
> > > > 决策是：通过实现零惩罚的抽象（OO、GP），来达到效率+抽象兼得的目的。而这个决策，在当前的背景下，由一个优点，变成了一个缺点，因为它折中了抽
> > > > 象。如果我们不再需要通过零惩罚的抽象类来获得效率，"零惩罚的抽象"所带来的结果就只是不友好的编程范式。
>
> > > > 有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。
>
> > > > 剩下的问题是：
>
> > > > 那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）
>
> > > > 也许是有的，我可以列出两点：
>
> > > > 1. 直接操纵硬件。
> > > > 2. 静态类型系统。
>

> > > 第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用---什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，-又-具-有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。

[HanliInter]

据在autodesk实习的学长透露他们实习的主要工作是将Autocad向.net移植,也不知道情况怎么样了...

[Eli]

说两句挨骂的, 云风应该多读读西方哲学, 和数学史这样的东西, 就会发现形式化是一直在追求的; 比如Linus, 恐怕没人敢去想, Linus
那么说, 很有可能是因为他个人的某一方面素质(虽然在他的领域内他很强)不足以承担他所说的"心智包袱", 而并非用"心智包袱"去换取一些东西不值
得. 如果仅因为Linus这样的人的发言简介肯定了我们的某种感受, 我觉得这也许不是什么好事.

而刘兄你则应该去从事一些项目, 包括C#的, Java的, JavaScript的等等, 然后再回过头来考虑这个问题. 说实话, 我虽然早在
10年前就写过C/C++程序, 但是对C++反而是个新手, 因为近几年, 我从事的工作基本都围绕Web, 也就是C#和JS展开. 正好是你们认
为的能够继续瓜分C++市场的两类语言的两个还算广泛的代表. 但是最近重新关心了一下C++, 实际操作并没有给我带来太多的不爽快, 虽然
Anders说的不必要的繁文缛节确实太多了; 而理论上的学习恰恰让我更多的认识了C#这样的语言的不足, C#的各方面设定太在乎那些承受不了"心
智包袱"的家伙了, 比如其泛型与C++的模板比, 只能说是鸡肋. Java由于其JVM实现方式的诸多制约, 就更不要说了.

我个人恰恰认为, C#砍掉的东西, 实际上是在束缚而不是增强我的能力, 这跟是否直接操作硬件无关, 限於时间, 我不打算展开来讨论这种问题;
而JS这样的半LISP语言, 嗯.., 如果变成一个静态语言, 或者采取其它一些能接近静态语言的方式, 如象.NET那样运行时编译然后缓存,
可能大有所为. 但是C++本身也在进步不是么? 当然, C#也在进步, Ruby(不熟, 所以就没用它来说事)也在进步, 最终是殊途同归, 但
每种语言略有偏向的.

你说的问题, 我觉得最大的谬误在于, 你把不同层面的因素放到了一起. 并行带来的性能, 和静态语言的性能, 根本不是一码事. 主要是过程本身是
否可以分解. 如一个可分解的过程, 分为两个不可分解的过程可以放进两个CPU, 但每一个CPU上的效率, 照样是要追求的. 如运行在CPU1上
的一个不可分割的任务C++耗时1ms, 而Ruby耗时2ms, CPU2上的任务, 由于优化, C++和Ruby都是1ms, 但得出结果,
Ruby还是2ms, C++却是1ms. 所以关键还是C++提供的并行化的能力.

在这样的工作上, 没道理Ruby或任何一种语言就比C++提供的更多, 唯一可以担心的事情就是C++进步的太慢, 而C#这样的厂商推动的东西则进
化的很快. C++要是死, 也只能死在这个上面.

[pongba]

On Dec 10, 2007 12:52 AM, Eli <Eli...@gmail.com> wrote:

说两句挨骂的, 云风应该多读读西方哲学, 和数学史这样的东西, 就会发现形式化是一直在追求的; 比如Linus, 恐怕没人敢去想, Linus
那么说, 很有可能是因为他个人的某一方面素质(虽然在他的领域内他很强)不足以承担他所说的"心智包袱", 而并非用"心智包袱"去换取一些东西不值
得. 如果仅因为Linus这样的人的发言简介肯定了我们的某种感受, 我觉得这也许不是什么好事.

我不认为云风不知道这一点。实际上，从和云风的讨论中，我发现他对设计的认识是非常深刻的。而Linus所言也是对的，只不过前提是在他从事的领域之内。
此外，"心智包袱"是说非本质复杂性，而不是C++用于换取一些东西所必须付出的代价（比如分为明显的动静两种语言特性——OO和GP）。D语言就很大程度上消除了这些"心智包袱"；而同样保有了效率和抽象。C++则要等0x，不过C++的优势在于既有代码基。
 

而刘兄你则应该去从事一些项目, 包括C#的, Java的, JavaScript的等等, 然后再回过头来考虑这个问题. 说实话, 我虽然早在
10年前就写过C/C++程序, 但是对C++反而是个新手, 因为近几年, 我从事的工作基本都围绕Web, 也就是C#和JS展开. 正好是你们认
为的能够继续瓜分C++市场的两类语言的两个还算广泛的代表.

C#和JS这类语言与C++早就已经分道扬镳了，在领地方面几乎是没有竞争性可言，各管各的。
 

但是最近重新关心了一下C++, 实际操作并没有给我带来太多的不爽快,

写了多少代码呢？又涉及到了C++的多少成分呢？一般来说，写个上万行的代码，如果用现代风格写的话，连new/delete都用不上。
 

虽然Anders说的不必要的繁文缛节确实太多了; 而理论上的学习恰恰让我更多的认识了C#这样的语言的不足, C#的各方面设定太在乎那些承受不了"心

智包袱"的家伙了, 比如其泛型与C++的模板比, 只能说是鸡肋. Java由于其JVM实现方式的诸多制约, 就更不要说了.

不妨具体说说..
 

我个人恰恰认为, C#砍掉的东西, 实际上是在束缚而不是增强我的能力, 这跟是否直接操作硬件无关, 限於时间, 我不打算展开来讨论这种问题;
而JS这样的半LISP语言, 嗯.., 如果变成一个静态语言, 或者采取其它一些能接近静态语言的方式, 如象.NET那样运行时编译然后缓存,
可能大有所为.

语言本身与JIT与否没有直接联系；况且JS这种运行在浏览器里面的小型语言，需要动用JIT吗？
 

但是C++本身也在进步不是么? 当然, C#也在进步, Ruby(不熟, 所以就没用它来说事)也在进步, 最终是殊途同归, 但
每种语言略有偏向的.

殊途同归？meaning what？归到哪条路上？
 

你说的问题, 我觉得最大的谬误在于, 你把不同层面的因素放到了一起. 并行带来的性能, 和静态语言的性能, 根本不是一码事. 主要是过程本身是
否可以分解. 如一个可分解的过程, 分为两个不可分解的过程可以放进两个CPU, 但每一个CPU上的效率, 照样是要追求的. 如运行在CPU1上
的一个不可分割的任务C++耗时1ms, 而Ruby耗时2ms, CPU2上的任务, 由于优化, C++和Ruby都是1ms, 但得出结果,
Ruby还是2ms, C++却是1ms. 所以关键还是C++提供的并行化的能力.

你说的这个逻辑的漏洞在于认为性能是绝对的。然而性能是相对的。所有正确的关于优化的文章都会说：除非必要否则不要提早优化，而且还要"测量两次，优化一次"。关键是：性能一旦达到一定要求，便出现严重的边际效应递减（接着往下优化便开始不值得起来）；否则岂不是所有的应用都要用C++做（越快越好嘛）。"并发"作为一个强劲的优化手段，在那些可通过并发优化的应用上，会把C++的零惩罚的抽象模型的风头抢掉，于是在这个时候也许就未必需要用C++，而只需要一门良好支持并发的语言（也许Java，也许C#）就可以了。和Bjarne通信的时候我认为他也认同这么个观点，不过他指出了一个重要的地方：即仍然会有大量应用场所不仅需要效率、而且无法容易地并行化，这类场所仍然是C++的用武之地。至于到底有哪些我还得再问问。

[red...@gmail.com]

pongba 写道:

殊途同归？meaning what？归到哪条路上？
 

你 说的问题, 我觉得最大的谬误在于, 你把不同层面的因素放到了一起. 并行带来的性能, 和静态语言的性能, 根本不是一码事. 主要是过程本身是

否可以分解. 如一个可分解的过程, 分为两个不可分解的过程可以放进两个CPU, 但每一个CPU上的效率, 照样是要追求的. 如运行在CPU1上
的一个不可分割的任务C++耗时1ms, 而Ruby耗时2ms, CPU2上的任务, 由于优化, C++和Ruby都是1ms, 但得出结果,
Ruby还是2ms, C++却是1ms. 所以关键还是C++提供的并行化的能力.

你说的这个逻辑的漏洞在于认为性能是绝对的。然而性能是相对的。所有正确的关于优化的文章都会说：除非必要否则不要提早优化，而且还要"测量两次，优化一 次"。关键是：性能一旦达到一定要求，便出现严重的边际效应递减（接着往下优化便开始不值得起来）；否则岂不是所有的应用都要用C++做（越快越好嘛）。 "并发"作为一个强劲的优化手段，在那些可通过并发优化的应用上，会把C++的零惩罚的抽象模型的风头抢掉，于是在这个时候也许就未必需要用C++，而只 需要一门良好支持并发的语言（也许Java，也许C#）就可以了。和Bjarne通信的时候我认为他也认同这么个观点，不过他指出了一个重要的地方：即仍 然会有大量应用场所不仅需要效率、而且无法容易地并行化，这类场所仍然是C++的用武之地。至于到底有哪些我还得再问问。

  pongda 这里说得有道理.

  我实现过几个对性能要求比较高的程序, 主要是在包过滤和服务器这个级别, 对这种应用而言, 最重要的, 是选择大架构, 例如, 在 kernel 做还是在 userspace 做, 处理 mass connection 用什么方案 (这其实都已经开始限制了语言的选择了).

  实现代码中, 对性能要求很高的代码, 其实代码量不是太大, 因此, 即使用抽象能力不足的语言来做也并无问题. 这些代码, 首先要求是尽量减少不连续内存访问, 然后才是指令数的减少, 这和数据结构的关系甚大, 和语言的关系反倒较小, 更甚者, 如果用 OO 设计实现, 又没有避免对象独立分配在不同地址, 反而会做不好事情.

  从这个案例看,  我碰到的个案中:
1. 对性能要求最高的代码, 量并不很大, 而且这部分代码, 对抽象能力要求未必很高. C++ 的抽象能力优点在这里不多, 相比直接手写数据结构代码, 彻底控制, C++ 模板强大的代码生成能力也说不上一定更强.

2. 其他的代码, 对性能的要求不是那么高, 当然希望抽象能力好, 另外最好编程也要简单, bug 隐患要少, 后两者似乎不是 C++ 的长项. 很多项目使用脚本 + C/C++ , 也是因为用脚本语言写高层代码即可, 写得快好调试, 以后的灵活性也够.
   不过, 引入一种新的高层语言, 只是利用高层语言的简单性,不需要高层语言的其他特性的时候, 带来两语言数据交换复杂性会让人犹豫是否值得, 这是常常碰到的情况; 有时候就是因为犹豫, 本来脚本适合的工作, 积累下来, 用 C++ 写, 越堆越多, 多到后来都不想切换了.  这也是 D 语言的一个切入契机.
  
  相信还会有其他案例会类似我的案例.

[Eli]

> 我不认为云风不知道这一点。实际上，从和云风的讨论中，我发现他对设计的认识是非常深刻的。而Linus所言也是对的，只不过前提是在他从事的领域之内。

> 此外，"心智包袱"是说非本质复杂性，而不是C++用于换取一些东西所必须付出的代价（比如分为明显的动静两种语言特性----OO和GP）。D语言就很大程度上消除了这些"心智包袱"；而同样保有了效率和抽象。C++则要等0x，不过C++的优势在于既有代码基。

D语言我不太懂, 但是我请你注意的是为什么我不懂这一事实, 谁在支持D, 谁在推广D, 我用D时找到所有我想要的东西吗? 大量的文档, 社区的
帮助, SourceForge上的源代码? C++相对于其它替代品, 这种优势将是长期的, 而且, 我觉得对于我们来说, 不能忽略这种优势,
并且既然语言带有非本质复杂性可以成为衡量一门语言的标准, 那么这种跟语言本身不挨边的优势, 照样可以作为衡量一门语言的标准. 其实说这个很无意
义, 但是需要提出的是, 和D或者任何其它可能更先进的语言比是没有必要的, 因为我们需要干活.

当然, C也有这种优势, 问题是当我需要C++的特性时, 非要自己去实现吗? 我不太明白的是, 你说"心智包袱"是说非本质复杂性，而不是C+
+用于换取一些东西所必须付出的代价（比如分为明显的动静两种语言特性----OO和GP）", "动静两种语言特性"不是非本质复杂性么? 那么
Linus指的"心智包袱"究竟是什么, 印象里, 他连STL都顺便给骂了(不过是一个库而已啊..); 难道是OO?
vector<shared_ptr<map<int, shard_ptr<Object>>固然很丑, 问题是他似乎并不是说这些, 而是明确的提
到, C++程序员的思维方式造就的程序如何如何垃圾, 可是按你说又不是. 而云风对模板的反感, 也表达的很明确吧? 我觉得在这个问题上对云风也
好Linus也好, 没有什么可维护的. 比如, Linus在该Post里对C#的看法似乎是连C++都不如吧? 而云风却说C#/Java都比C
++强.

这里全都是矛盾, 所以在我这样的第三者看来, 只有一个可能, 要么是意气用事, 要么是我说的, 素质缺陷(该挨骂的话, 因为用错词了), 导致
对一些东西异常反感. 我说的素质缺陷的其实想表达的含义是, 人天生和后天培养的性格中的向性所导致的主观因素. 我想就C++ vs C这种话题和
他们所表达的意见来说, 绝不是刘兄你能方方面面帮所有的人所有的言论圆场的.

> C#和JS这类语言与C++早就已经分道扬镳了，在领地方面几乎是没有竞争性可言，各管各的。

这个不是我的意思, 很多人包括云风都在说, C#/Java能完成什么什么, C++这块已经没了, 未来那块也得没. 然后剩下的让C包办. 不是
吗? 另外C#和JS也不是一类语言, 之所以放到一起, 是说你去做点那些更高级语言的项目, 是说你可以体会一下, 是不是在写JS或者C#的时
候, 解决它们擅长的领域里的问题的时候, 就不盼望拥有C++有而该语言无的那些特性.

> 写了多少代码呢？又涉及到了C++的多少成分呢？一般来说，写个上万行的代码，如果用现代风格写的话，连new/delete都用不上。

代码行数确实不多, 是一个图像处理方面的应用. 不过如你猜测, 我最开始就是用10年前的方法写的, 后来又大部分换为你说的现代风格了(因为写完
了以后, 打算趁机看看C++有什么进展). 不过真正要效率的部分, 还是得直接操作指针.

> 不妨具体说说..

呃.., 具体说? C#所有的特性, C++似乎都能实现吧? 那么多重继承, 模板, 这些C#有吗? 泛型的问题, 每次C++程序员到
C#/Java社区干仗, 都说得很清楚了... 倒是Effective C++类似的书里说的这些乱七八糟的要点, C#完全不必关心, 但是关心
这些问题很费劲吗? 另外我实在不明白, 为什么那么多人说Java/C#比C++提供了更好的抽象能力. 抽象能力是在我们脑海里, 而不是通过砍掉
特性来保证他们被更正确的应用的.

> 语言本身与JIT与否没有直接联系；况且JS这种运行在浏览器里面的小型语言，需要动用JIT吗？

的确没有直接联系, 但是不能这么割裂的看问题似乎. 你可以看看流行的JS界面库中的拖拽功能, 那么点对象, 就卡的跟什么似的, 我想这个问题我
有发言权, 因为我自己重新实现的版本, 比起互联网上任何一个最有名的JS界面库中的拖拽, 效率和功能都高不少; 我唯一一个感慨, 就是如果能再
快点就好了, 因为我不知道那些还在用P3的机器上, 效果到底会如何. 在这里, 我就是需求, 我希望你能承认这一点, 不是空谈用或者不用, 而
是我和很多人产生了这种需求! 以后越来越多的计算会从Server转到Browser, 事情真如你所判断的那样, 一个领域有一个领域的特征从而要
求不同么? 微软的SL 2.0中植入了CLR, 就是这种需求的证明了.


> 殊途同归？meaning what？归到哪条路上？

我这话说的确实有点不经大脑, 现在我也不知道是什么意思了. 估计是都会借鉴其它语言的优势, 导致相似性越来越多吧. C#/VB现在也逐渐变成一
门"复杂"的语言了, 现在已经提供了一定的FP支持, 未来难保不会逐渐的支持真正的模板. 或者更广泛的说, 比如解释型的语言, 为了提高效
率, 逐渐都会采取或部分采取动态编译的方式; 而象C++这样的语言, 不是已经在模仿FP的一些方式, 估计也会逐渐提供运行时类似于反射这样的能
力, 至于未来会提供些什么什么时候提供, 那就应该你给我上课了.

> 你说的这个逻辑的漏洞在于认为性能是绝对的。然而性能是相对的。所有正确的关于优化的文章都会说：除非必要否则不要提早优化，而且还要"测量两次，优化一次"。关键是：性能一旦达到一定要求，便出现严重的边际效应递减（接着往下优化便开始不值得起来）；否则岂不是所有的应用都要用C++做（越快越好嘛）。"并发"作为一个强劲的优化手段，在那些可通过并发优化的应用上，会把C++的零惩罚的抽象模型的风头抢掉，于是在这个时候也许就未必需要用C++，而只需要一门良好支持并发的语言（也许Java，也许C#）就可以了。和Bjarne通信的时候我认为他也认同这么个观点，不过他指出了一个重要的地方：即仍然会有大量应用场所不仅需要效率、而且无法容易地并行化，这类场所仍然是C++的用武之地。至于到底有哪些我还得再问问。

性能在很多领域是绝对的. 不用BS, 我给你提供一个场景, 我这次做的这个图像处理程序, 算法所有的操作都直接操作内存, 在需要处理的图像大到
一定地步, 其速度说实话有点不能接受. 你可以看看Photoshop的一些特效的速度. 是, 我做大面积的高斯模糊或者什么特效, 进度条闪一下
也就算了. 问题是有些特效是通过鼠标拖动来操作的, 并且必须及时反映结果. 双核我可以把图分两部分, 分别处理, 4核分4部分, 这都很好想
像. 你的意思是说, 未来16核了, 假设C#慢16倍, 假设没有并发本身带来的成本, 那么既然我现在的C++程序用户能接受, 那么很显然将来
C#的效率除以16在乘以16, 还是能接受. 我觉得咱们的分歧就在这里, 因为你没有考虑, 未来的软件, 处理的不是几千像素乘以几千像素的图象
了, 很可能每幅照片都是上万乘以上万像素的. 所以不仅数码相机里得用C/C++, 这些图像处理程序也是照旧. 我估计游戏也是一样, 因为玩家的
要求会不断提高.

当然C#不见得真的慢16倍这么多, 但是你可能听说过的, 那些证明C#或Java性能也比较可靠的传闻也不见得是真的. 比如
Quake2.NET, 很多人说这个移植能达到C 85%的速度, 其实它的实现方式根本就是包装式的. 一般C#程序员, 根本无法掌握. 再多的
核, 应该是大幅提高最终用户的使用体验, 而不是为了让程序员能用效率较低但较好用的编程方式去写程序. 性能的要求也是随着时间增长的.

近几年内还存在着其它问题: 比如我一个几百K, 一两M的共享软件, 却要求用户下一个几百M的运行时? 不过这些问题肯定都能解决. 不过作为一个
C#程序员, 我比较不明白的还是: C++比C#到底麻烦了多少, 连你这个过去扛C++大旗的都不看好了? 我觉得只有明显的让我这样的职业C#选
手感觉不好, 才说明从C++跳到另一门语言, 是个必然的选择吧...

[Eli]

> 我实现过几个对性能要求比较高的程序, 主要是在包过滤和服务器这个级别, 对这种应用而言, 最重要的, 是选择大架构, 例如, 在 kernel 做还是在 userspace 做, 处理 mass connection 用什么方案 (这其实都已经开始限制了语言的选择了).
> 实现代码中, 对性能要求很高的代码, 其实代码量不是太大, 因此, 即使用抽象能力不足的语言来做也并无问题. 这些代码, 首先要求是尽量减少不连续内存访问, 然后才是指令数的减少, 这和数据结构的关系甚大, 和语言的关系反倒较小, 更甚者, 如果用 OO 设计实现, 又没有避免对象独立分配在不同地址, 反而会做不好事情.
> 从这个案例看, 我碰到的个案中:
> 1. 对性能要求最高的代码, 量并不很大, 而且这部分代码, 对抽象能力要求未必很高. C++ 的抽象能力优点在这里不多, 相比直接手写数据结构代码, 彻底控制, C++ 模板强大的代码生成能力也说不上一定更强.
> 2. 其他的代码, 对性能的要求不是那么高, 当然希望抽象能力好, 另外最好编程也要简单, bug 隐患要少, 后两者似乎不是 C++ 的长项. 很多项目使用脚本 + C/C++ , 也是因为用脚本语言写高层代码即可, 写得快好调试, 以后的灵活性也够.
> 不过, 引入一种新的高层语言, 只是利用高层语言的简单性,不需要高层语言的其他特性的时候, 带来两语言数据交换复杂性会让人犹豫是否值得, 这是常常碰到的情况; 有时候就是因为犹豫, 本来脚本适合的工作, 积累下来, 用 C++ 写, 越堆越多, 多到后来都不想切换了. 这也是 D 语言的一个切入契机.
>
> 相信还会有其他案例会类似我的案例.

你说的这个确实我也想过, C写好需要效率的部分, C#一包装完事. 根本无需C++. 我这次选用C++, 纯粹是因为我不想让用户的目标客户再装
什么.NET运行库. 不过说实话, 我觉得C++写起来, 就我的感受对比C#, 除了讨厌的头文件让人受不了, 还有智能指针太丑, 自己管理内存
又得防止这防止那, 没有方便又安全的委托机制等等, 有什么地方因为好长时间不写, 就得翻书省的因为细节注意不到造成失误, 就没什么了... 不
过Brooks不早就说过, 这些非本质复杂性的消除, 根本不会对提高编程效率有决定性影响吗?

[red...@gmail.com]

我不知道 Brooks 说过什么话 (我不知道这是哪位).

同样的项目, 例如进行数据处理之后写数据库, 用 python 写, 比 C++ 写能够快
很多完成, 而且功能测试正常之后, 不必再去测试有没有内存泄漏之类的问题.

如果非本质复杂性对效率没有影响, 为什么大家会选用java, 脚本, 而不是 C++
去开发用不着非常高效率的东西 ?
> 不
> 过Brooks不早就说过, 这些非本质复杂性的消除, 根本不会对提高编程效率有决定性影响吗?
>

[xxmplus]

就是写人月神话的那位

--
Any complex technology which doesn't come with documentation must be the best
available.

[red...@gmail.com]

Eli 写道:

我不认为云风不知道这一点。实际上，从和云风的讨论中，我发现他对设计的认识是非常深刻的。而Linus所言也是对的，只不过前提是在他从事的领域之内。
此外，"心智包袱"是说非本质复杂性，而不是C++用于换取一些东西所必须付出的代价（比如分为明显的动静两种语言特性----OO和GP）。D语言就很大程度上消除了这些"心智包袱"；而同样保有了效率和抽象。C++则要等0x，不过C++的优势在于既有代码基。
    

D语言我不太懂, 但是我请你注意的是为什么我不懂这一事实, 谁在支持D, 谁在推广D, 我用D时找到所有我想要的东西吗? 大量的文档, 社区的
帮助, SourceForge上的源代码?

   这个, 我来说说我的看法.

   我觉得, 一个设计得好的语言, 要学懂语言本身, 看基本的手册, 入门书, 简单的范例就应该足够了, 如果搞到需要网上大量资源去讨论语言的基本使用, 那是失败.
   互联网网上的项目, 文档, 社区, 应该是去讨论基于这个语言的种种框架和库, 而不是去讨论种种 workaround, 以及标准库太少而各人重重复复做的类似的库.

   说到C++, 网上的东西, 排除掉这些, 剩下的很多吗? 我觉得比 C 和 Java 都少.

   当然, 如果要开发 Windows GUI 程序, 不想要虚拟机, 要用编译语言, 要界面漂亮, 要好的调试器, 那除了VC ++, 也没啥选择.

 C++相对于其它替代品, 这种优势将是长期的, 而且, 我觉得对于我们来说, 不能忽略这种优势,
  

   C++ 各种大型库不能互相兼容的分裂局面, 将是长期的.

[red...@gmail.com]

Eli 写道:

我不认为云风不知道这一点。实际上，从和云风的讨论中，我发现他对设计的认识是非常深刻的。而Linus所言也是对的，只不过前提是在他从事的领域之内。
此外，"心智包袱"是说非本质复杂性，而不是C++用于换取一些东西所必须付出的代价（比如分为明显的动静两种语言特性----OO和GP）。D语言就很大程度上消除了这些"心智包袱"；而同样保有了效率和抽象。C++则要等0x，不过C++的优势在于既有代码基。
    

D语言我不太懂, 但是我请你注意的是为什么我不懂这一事实, 谁在支持D, 谁在推广D, 我用D时找到所有我想要的东西吗? 大量的文档, 社区的
帮助, SourceForge上的源代码?

   这个, 我来说说我的看法.

   我觉得, 一个设计得好的语言, 要学懂语言本身, 看基本的手册, 入门书, 简单的范例就应该足够了, 如果搞到需要网上大量资源去讨论语言的基本使用, 那是失败.
   互联网网上的项目, 文档, 社区, 应该是去讨论基于这个语言的种种框架和库, 而不是去讨论种种 workaround, 以及标准库太少而各人重重复复做的类似的库.

   说到C++, 网上的东西, 排除掉这些, 剩下的很多吗? 我觉得比 C 和 Java 都少.

   当然, 如果要开发 Windows GUI 程序, 不想要虚拟机, 要用编译语言, 要界面漂亮, 要好的调试器, 那除了VC ++, 也没啥选择.

 C++相对于其它替代品, 这种优势将是长期的, 而且, 我觉得对于我们来说, 不能忽略这种优势,
  

   C++ 各种大型库不能互相兼容的分裂局面, 将是长期的.

[Eli]

我发现没白偷偷摸摸混到这里来.., 确实很多问题我以前没想过. 你们对C++比我熟多, 所以肯定有经验, 无论是好的还是痛苦的. 只是, 我觉
得我不属于刘兄说的那个用啥就被啥框住, 觉得啥好的那种人, 所以既然我不是一个CPPER, 也不觉得连续用了好几年的C#多么好, 所以就想拿我
的感受来抛砖引玉. 因为我实在觉得纳闷, 我一可说的上是C++门外汉的家伙, 觉得C++可以接受, 而天天话题围绕C++打转的刘兄到开始质疑
了.

"如果非本质复杂性对效率没有影响, 为什么大家会选用java, 脚本, 而不是 C++去开发用不着非常高效率的东西 ? "

呃, 有几点, 大公司的支持是其一, Java或者C#, 如果不是他的支持者推的那么厉害, 反正我个人是未必用...., 如果C++/CLI微
软的IDE给一个更好的Web支持, 很多从C++转行搞Web得程序员, 未必选择C#. VB.NET跟VB6其实截然不同, 不照样一大堆人
用? 用的人里有几个真正知道VB.NET比C#方便之处的呢? 我看如果不是Gates的Basic情节, 恐怕今天VB也黄了, 到VBx, VB
又要回归动态语言了.., 跟已经在.NET上发展多时的IronPython相比, 到时候有多少人会用IronPython呢? 所以政治或商业的
力量是巨大的...

脚本, 是因为脚本往往总是专为解决一些问题而设, 同时没有强有力的竞争者吧? 我写脚本主要就是JS, 问题是浏览器不支持C/C++/C#
啊.., 这不微软要在SL里通过CLR支持引入C#, .NET阵营里多少人拍手欢呼呢. 就连前段时间C#->JS的一个小玩意, 都有不少人支持
呢. Google不是也搞用Java写JS的玩意并且不少人支持么? 所以显而易见的是习惯肯定能克服优势的, 虽然大多数程序员(即语言使用者)不
考虑什么非本质复杂性的高深问题, 但我感觉你不能说他们的习惯其实一定是陋习, 也许这就是直觉上对非本质复杂性忽略的表现.

说实话, 我混到这里来, 确实是反而打算研究一下C++了, 不过我对大多数C++的优势(比如又有抽象又有效率)不感兴趣, 因为说实在的, 就像
你说的, 无论什么项目, 它的需求往往就把语言筛选出来了, 如何谨慎的使用选中语言, 那就是好的态度加上学习实践的事. 我在意的就是C#之类没
有的东西, 比如你们说的TMP.., 这并不是为了刘兄在一篇博文中说的, 要掌握那些看起来玄乎的东东来高兴一下, 而是怕错过了这些我没实践过的
东西所体现出来的思想...

[pongba]

On Dec 13, 2007 9:02 AM, Eli <Eli...@gmail.com> wrote:

性能在很多领域是绝对的. 不用BS, 我给你提供一个场景, 我这次做的这个图像处理程序, 算法所有的操作都直接操作内存, 在需要处理的图像大到
一定地步, 其速度说实话有点不能接受. 你可以看看Photoshop的一些特效的速度. 是, 我做大面积的高斯模糊或者什么特效, 进度条闪一下
也就算了. 问题是有些特效是通过鼠标拖动来操作的, 并且必须及时反映结果. 双核我可以把图分两部分, 分别处理, 4核分4部分, 这都很好想
像. 你的意思是说, 未来16核了, 假设C#慢16倍, 假设没有并发本身带来的成本, 那么既然我现在的C++程序用户能接受, 那么很显然将来
C#的效率除以16在乘以16, 还是能接受. 我觉得咱们的分歧就在这里, 因为你没有考虑, 未来的软件, 处理的不是几千像素乘以几千像素的图象
了, 很可能每幅照片都是上万乘以上万像素的. 所以不仅数码相机里得用C/C++, 这些图像处理程序也是照旧. 我估计游戏也是一样, 因为玩家的
要求会不断提高.

当然C#不见得真的慢16倍这么多, 但是你可能听说过的, 那些证明C#或Java性能也比较可靠的传闻也不见得是真的. 比如
Quake2.NET, 很多人说这个移植能达到C 85%的速度, 其实它的实现方式根本就是包装式的. 一般C#程序员, 根本无法掌握. 再多的
核, 应该是大幅提高最终用户的使用体验, 而不是为了让程序员能用效率较低但较好用的编程方式去写程序. 性能的要求也是随着时间增长的.

近几年内还存在着其它问题: 比如我一个几百K, 一两M的共享软件, 却要求用户下一个几百M的运行时? 不过这些问题肯定都能解决. 不过作为一个
C#程序员, 我比较不明白的还是: C++比C#到底麻烦了多少, 连你这个过去扛C++大旗的都不看好了? 我觉得只有明显的让我这样的职业C#选
手感觉不好, 才说明从C++跳到另一门语言, 是个必然的选择吧...

对于图像处理，说句题外话。直接操纵内存这样的优化手法其实是杯水车薪，MS早期win32里面的BitBlt用的是动态编译手法，把一个通用算法的代码根据运行时的具体参数编译出具体的二进制版本然后跳去执行，类似于JIT（在C#下面，有了JIT，这个工作就容易多了）。<Beautiful Code>的第八章：On-the-Fly Code Generation for Image Processing详细介绍了这一技术，并且实验了将他用在C#上的结果——跟C版本的效率相差无几。

我不知道Quake2.NET里面有没有采用这种手法。

[pongba]

On Dec 13, 2007 12:43 PM, Eli <Eli...@gmail.com> wrote:

我发现没白偷偷摸摸混到这里来.., 确实很多问题我以前没想过. 你们对C++比我熟多, 所以肯定有经验, 无论是好的还是痛苦的. 只是, 我觉
得我不属于刘兄说的那个用啥就被啥框住, 觉得啥好的那种人, 所以既然我不是一个CPPER, 也不觉得连续用了好几年的C#多么好, 所以就想拿我
的感受来抛砖引玉. 因为我实在觉得纳闷, 我一可说的上是C++门外汉的家伙, 觉得C++可以接受, 而天天话题围绕C++打转的刘兄到开始质疑

了.

其实我感觉正是因为你以前工作的领域不是C++，所以才能够以超脱的局外人眼光来审视C++。真正把C++当个事情来学的，很容易一头钻进树林子，之间树木不见森林的。这基本也就是我那篇文章想说的。也是我建议多学习其他语言的原因。 

[Eli]

> 对于图像处理，说句题外话。直接操纵内存这样的优化手法其实是杯水车薪，MS早期win32里面的BitBlt用的是动态编译手法，把一个通用算法的代码根据运行时的具体参数编译出具体的二进制版本然后跳去执行，类似于JIT（在C#下面，有了JIT，这个工作就容易多了）。<Beautiful
> Code>的第八章：On-the-Fly Code Generation for Image

> Processing详细介绍了这一技术，并且实验了将他用在C#上的结果----跟C版本的效率相差无几。
>
> 我不知道Quake2.NET里面有没有采用这种手法。

这本书等着你们赶紧出版哪...

你说的这种手法我没试过, 但是排除算法, 对于像素级别的操作来说, C#必须unsafe之后直接操作指针才够快啊(其实我不太愿意提到这点, 因
为这倒更证实了你说的C++的效率优势不见得能维持很久)..., 如果用C#提供的类, 那么一个像素多花一点时间, 那么多像素还是很可观
的... 至于一些细节比如有时需要成块内存的复制, 其实我要用C#写, 肯定是包装memcpy, 而不是来自C++的什么能力, 这又证实了云风
的说法, 所以我也没多提. 不过看来蒙混过关是不可能地 :P

呵呵, 糊弄来糊弄去, 我倒把自己给绕进去了. 其实我的核心观点就是, 我一个C#玩家, 并没有感觉C++不好使, 如你文章所说, 碰见可能有
陷阱的地方, 看书便是. 或者让有经验的C++程序员review一下, 大概跟我说一下我存在的问题, 然后我再自己去查书. 另外一点是, 说实
话, 我自认对设计模式之类的东西, 确实过了崇拜期, 进入了有理解, 通过实践来积攒如何正确使用的时期, 这样我回过头来用C++实现设计, 就
像你文章所说, 是先有设计, 然后才看C++的实现应该是什么样, 哪怕一时实现的丑陋些, 我心里也非常明白自己怎么想的, 为什么不好. 这点可
能还是象你说的, 这和我的重要成长时期用C#而能集中精力解决一些更本质的问题和有时间进行思考有关.

但我只是觉得, 云风他们不能因为这些, 就说C++如何了, 如果C++语言本身没有独特的优势了, 我还回头干嘛? 你的博文还说, TMP是精力
过剩, 但之所以我会注意它, 是因为我用C#没有这样的概念, 我需要的是更多的来自这些编程方式的思想去启发我自己的思考啊, 所以我不赞成你说
的, 一般C++程序员无需接触这些东西. 如果C++没有这些东西, 除了非用它不可的场合(那我就抱着陷阱指南老老实实用呗), 就真的对我这样的
程序员不具有吸引力了.

只是Linus说的, 围绕一个漂亮对象创建, 最后发现蛮不是那么回事的说法, 你对BS那个访谈, 我就想问这个问题, 只是OO流行了这么些年的
一个根本性的问题. 我认为Linus的意思是, 想保持接口稳定, 没门! 确实, 比如IE的那些接口, 1/2/3/4的好几个, COM里这种
现象很常见吧. 以至于我的一个C++前辈, 10年前就跟我说, 接口的实质就是版本控制 -___-. 这个其实才是我一个比较大的疑惑, 接口到
底能不能稳定, 如何稳定?

在这次C++项目之前, 我有一个想法本来打算在C#里实验的, 就是实现一个框架, 借助对委托的重新组合和配置, 彻底抛弃接口和类的传统使用方
式, 毕竟C#里做这事, 比C++里玩函数对象或者在C里玩的函数指针容易的多, 同时具有强类型.. 因为我自身在得到OO帮助的同时, 也确实感
觉到很多时候, 它是通过限制我们做一些事来帮助我们的, 问题是如果象C#中用反射, 用EMIT之类内存里直接构造新类型的方式, 来突破这种限
制, 即通过后门去破坏规则, 损失的东西也很多.

嗯这个比较烦, 我不想造轮子, 即使造轮子, 我也希望多看些不同的方式, 体会一下各种思想, 这才是我混到这里的真正动力.^^

[Eli]

不过要说的是, 我认为至少两种应用, 一个是BS说的那种复杂和计算量大到需要巨型机了, 一个是个人计算机上的多媒体(图片声音视频)应用的核心部
分, 绝对不是Ruby之类甚至在Windows上再多优化些的C#可以赶上C++的, 多核是因为用户体验需要增加, 而不是为了方便程序
员....

关于图片部分, 等你们那本书我拿到手咱们再讨论, 但是就我和以前一个.NET程序员的经验, 算法本身费时不多但是要处理大量点的算法, 有至少象
C#一样有直接操作内存的能力是非常必要的, 微软自己的那个类似于精简版PHOTOSHOP的C#开源项目也是类似的做法... 但写到这, 我突然
想到, 会不会用Managed DirectX有线程的解决办法? 不过就不跨平台了..., 只是似乎跨平台这个理由又有点那个了...

[redsea]

现在的情形和当年已经有差异, 当年 CPU 慢, 现在内存慢, 对 P4, core/2 的 CPU 而言, CPU 快过内存很多, 我想,
如果不改变基本做法, 而只是copy 当年的动态编译生成代码做 bitblt, 现在的收获是恐怕有限.

如果是做bitblt 可能的优化手段, 我想到这些:

1. 显卡的 surface 功能, 能用上是最好的

2. 一定要用 cpu 做, 考虑一下内存的特性, 内存连续读性能好, 随机读性能差, 读写切换还要等待, AMD cpu 由于集成内存访问单
元, 可以重新排读写指令, 减少切换, intel 的 cpu/chipset 好像没有这个能力, 这样, 是不是可以考虑一下使用 sse2
寄存器, 而不是通用寄存器, 这样不但一个指令可以做更多的事情, 而且读写更加批量化(从而连续), 切换更少.
如果动态编译生成代码, 应该生成这种才对.

> 对于图像处理，说句题外话。直接操纵内存这样的优化手法其实是杯水车薪，MS早期win32里面的BitBlt用的是动态编译手法，把一个通用算法的代码根据运-行时的具体参数编译出具体的二进制版本然后跳去执行，类似于JIT（在C#下面，有了JIT，这个工作就容易多了）。<Beautiful

> Code>的第八章：On-the-Fly Code Generation for Image

> Processing详细介绍了这一技术，并且实验了将他用在C#上的结果----跟C版本的效率相差无几。
>
> 我不知道Quake2.NET里面有没有采用这种手法。
>
> --
> 刘未鹏(pongba)|C++的罗浮宫http://blog.csdn.net/pongba
> TopLanguagehttp://groups.google.com/group/pongba- 隐藏被引用文字 -
>

[redsea]

>AMD cpu 由于集成内存访问单元, 可以重新排读写指令
这里的指令不是 CPU 指令, 而是内存操作指令. 内存操作也是需要给总线发 command的.

[Yong Yuan]

On Dec 13, 2007 3:21 AM, pongba <pon...@gmail.com> wrote:

On Dec 13, 2007 9:02 AM, Eli <Eli...@gmail.com> wrote:

性能在很多领域是绝对的. 不用BS, 我给你提供一个场景, 我这次做的这个图像处理程序, 算法所有的操作都直接操作内存, 在需要处理的图像大到
一定地步, 其速度说实话有点不能接受. 你可以看看Photoshop的一些特效的速度. 是, 我做大面积的高斯模糊或者什么特效, 进度条闪一下
也就算了. 问题是有些特效是通过鼠标拖动来操作的, 并且必须及时反映结果. 双核我可以把图分两部分, 分别处理, 4核分4部分, 这都很好想
像. 你的意思是说, 未来16核了, 假设C#慢16倍, 假设没有并发本身带来的成本, 那么既然我现在的C++程序用户能接受, 那么很显然将来
C#的效率除以16在乘以16, 还是能接受. 我觉得咱们的分歧就在这里, 因为你没有考虑, 未来的软件, 处理的不是几千像素乘以几千像素的图象
了, 很可能每幅照片都是上万乘以上万像素的. 所以不仅数码相机里得用C/C++, 这些图像处理程序也是照旧. 我估计游戏也是一样, 因为玩家的
要求会不断提高.

Eli老大太乐观了吧？核多了，并行进程间调度和通讯的开销就大了。Amdahl's Law就是说这个的。http://en.wikipedia.org/wiki/Amdahl's_law，虽说我们不至于只获得线性性能提升，但N核就快N倍也难。而且，SMP渐行渐远叻，NUMA（Non-uniform memory access)来乐。一个MxN核的处理器把它的核分成M个片儿，每个片儿上N个核。每个片儿上的核共享高速本地内存。要读取更多的内存？没问题。到其他片儿那里去拿？代价嗫？网络读取速度。也就是说，多核处理器越来越像并行系统。如何保持内存读取本地化变成大问题了。Java/C#程序员们（惭愧一下，包括我）已经习惯了内存就是一大托东东：heap。至于Heap里怎么玩儿，除了票友和VM hacker没人关心。在NUMA里，heap就不再是统一的一大陀了。发起一条线程时，我们得知道哪片儿核的内存保留最多的程序数据，然后把线程贴过去。JVM/CLR能把这些完全隔离么？现在还难说。

 

当然C#不见得真的慢16倍这么多, 但是你可能听说过的, 那些证明C#或Java性能也比较可靠的传闻也不见得是真的. 比如
Quake2.NET , 很多人说这个移植能达到C 85%的速度, 其实它的实现方式根本就是包装式的. 一般C#程序员, 根本无法掌握. 再多的

核, 应该是大幅提高最终用户的使用体验, 而不是为了让程序员能用效率较低但较好用的编程方式去写程序. 性能的要求也是随着时间增长的.

近几年内还存在着其它问题: 比如我一个几百K, 一两M的共享软件, 却要求用户下一个几百M的运行时? 不过这些问题肯定都能解决. 不过作为一个
C#程序员, 我比较不明白的还是: C++比C#到底麻烦了多少, 连你这个过去扛C++大旗的都不看好了? 我觉得只有明显的让我这样的职业C#选
手感觉不好, 才说明从C++跳到另一门语言, 是个必然的选择吧...

[Jian Wang]

> Eli老大太乐观了吧？核多了，并行进程间调度和通讯的开销就大了。Amdahl's
> Law就是说这个的。http://en.wikipedia.org/wiki/Amdahl's_law，虽说我们不至于只获得线性性能提升，但N核就快N倍也难。而且，SMP渐行渐远叻，NUMA（Non-uniform
> memory
> access)来乐。

PS3就是这样的结构。
又到了stack唱主角的时候。
C++/D可以雄起一阵了。

在 07-12-14，Yong Yuan<y...@cs.toronto.edu> 写道：

[Googol Lee]

但是ps3的开发难度太大了……

在 07-12-13，Jian Wang<oxygen.j...@gmail.com> 写道：

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

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

[redsea]

我很怀疑单核的内存模型以后也会变.

怎么说呢, 现在的 CPU 比内存快太多. 一个 2G 的 CPU, 配一个 400M 的 ddr2 800 内存, 偏偏这个内存还不是每
1HZ 都能够提供数据, 做这个要多少等待周期, 做那个要多少等待周期, 相比 CPU, 这个内存实在太慢.

双通道? 这个玩意只能加快内存连续访问的速度, 对于消除 非连续访问的等待, 读写切换等待, 等待等等毫无帮助, 所以各种评测结果可以看出,
这玩意对游戏之类大量操作内存bitmap 之类的东西帮助比较大, 对编译器, 压缩软件等经常离散访问内存的没有什么帮助. 我见过几个人的
winrar 的速度测试, tulatin P3 1.2G oc 1.4G + SDRAM PC133 oc PC150的压缩速度, 比
P4 3G + ddr400 还要快不少, 主要原因除了 P3频率利用率比P4好之外, 还有一个重要原因是老 SDRAM PC133 的内存连
续访问速度虽然不快, 但是随机访问的延时指标却比 DDR, DDR2 优秀不少.

在这种情况下, 搞内存双通道, 还不如将重新设计内存控制器, 几条内存作为独立的内存通道, 而且让操作系统, 应用程序都知道, 这里有几个独立
的内存 zone, 优化内层循环的时候, 例如根据一个查找表, 扫描另外一块内存, 程序应该将查找表放到一个zone, 被扫描的内存使用另外一
个 zone; bitmap 变换处理的时候, 也应该是 zone1 + zone2 --> zone3 这样使用内存, 效果应该比所谓的双通
道好得多.


但是这样搞, 语言对底层的封装又再次封不住啦, 哈哈.

>
> http://en.wikipedia.org/wiki/Amdahl's_law，虽说我们不至于只获得线性性能提升，但N核就快N倍也难。而且，SMP渐行渐远叻，NUMA（Non-uniform
> memory

> access)来乐。一个MxN核的处理器把它的核分成M个片儿，每个片儿上N个核。每个片儿上的核共享高速本地内存。要读取更多的内存？没问题。到其他片儿那-里去拿？代价嗫？网络读取速度。也就是说，多核处理器越来越像并行系统。如何保持内存读取本地化变成大问题了。Java/C#程序员们（惭愧一下，包括我）已经-习惯了内存就是一大托东东：heap。至于Heap里怎么玩儿，除了票友和VM
> hacker没人关心。在NUMA里，heap就不再是统一的一大陀了。发起一条线程时，我们得知道哪片儿核的内存保留最多的程序数据，然后把线程贴过去。JV-M/CLR能把这些完全隔离么？现在还难说。

[莫华枫]

又要革命了！

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

[redsea]

我为什么怀疑 PC 平台上, 以后的内存模型变, 是因为我已经看到 network processor 上的内存模型已经变了, 我见过内存模型
最复杂的NP 的内存是这样分的: 程序的内存, TCAM 内存, chip 内高速内存, 网络输入的数据好像也有自己专门的内存, 我忘了,
每种内存有各自的带宽, 不会打架.

TCAM 内存是很强大的内存, 例如可以当作字符串的 AA 数组使用, 初始化好之后, 给它一个字符串, 它立刻查出这个字符串登记了没有,
登记时候另外一个数是什么. 用这个内存, 可以省掉大量的CPU , cache 和主内存带宽.

chip 内高速内存, 是比cache 慢一点, 但是比主存快很多的片内内存, 大概有十几M.


BTW: 上文中, 我还说错了, DDR2 800 的频率是 200M. DDR3 1600 的频率也是 200M.

DDR内存比起 SDRAM 来说, 设计主要是考虑了吞吐量, 延迟指标似乎没有被重视. DDR2 的延迟指标比 DDR 也没有进步.

我之前的那个程序, 多访问一个不被cache 的内存单元, 够我的2.5G cpu 多执行600条指令, 在这种情况下, 要优化这个程序, 肯
定是必须对数据结构下手了, OO 不 OO 之类, 早抛开了.

看看 everest 里面的测试报告, 2.66G Core2 Duo E6700 on Abit AB9, DDR2-800 的测试, 内
存延时指标是 69.3ns (这应该是读的延时, 写的延时不好测), 拿 2.66G cpu 的一个core 来说, 每ns 可以执行
2.66 * 3 条简单指令(因为有三个执行单元, 是两个复杂单元一个简单, 还是一个复杂两个简单, 忘了), 这个内存延时值可以执行
69.3 * 2.66 * 3 = 553 条指令, 这还要另外一个core 同时没有争用内存总线才是如此. 这个测试结果比我自己的结果好
些, 估计是买 E6700 的玩家是有钱的玩家, 买的内存高档不少, 延时指标更漂亮一些.



On 12月14日, 上午8时45分, redsea <red...@gmail.com> wrote:
> 我很怀疑单核的内存模型以后也会变.

[Eli]

我是说假设并发没有成本这种最好情况...

我正是来反对核多了效能就能成倍提升, 于是拿高级语言就能随便写程序了的, 而且是站在一个C#而不是C++程序员的角度 :).

[Jian Wang]

TCAM这么牛？长见识了。
应该是内存芯片和控制器组合实现的吧？

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

[Eli]

不是明年Intel也搞内存控制器了吗? 说实话我觉得还不如并行系统干脆就纯并行, 1个控制器带一个CPU带1坨内存一块硬盘一块显卡, 只要加一
个就全都加倍, 就好比把两电脑塞一个机箱里然后并联起来, 最多其中半个电脑还负责整合结果, 或者设计一个专门用来响应结果的控制器, 至于程序快
慢, 就看程序员怎么设计算法好了...

[Eli]

另外我觉得程序员写程序的方法肯定得变. 现在据我观察, C#这样的阵营里没有多少人关心这个. 关键是有多少运算时上下文相关的. 凡是一个不相关
的任务, 都应该委托到一个新的线程实现, 然后有一个线程等待各线程的回调的结果, 收到全部结果后再继续下一个必须顺序执行的片段. 所以多核并不
会加强哪种语言, 而是所有的程序员都应该换换思路了.

[red...@gmail.com]

就不是普通的内存芯片, 而是另外的结构的内存芯片.

早几十年就有类似的内存了, 不过当时的关联内存似乎还不能检索字符串, 可以你
提供一个整数给它, 它立刻给你返回一个以前关联好的值.它的逻辑电路设计, 就
是用内容来做检索而不是用 offset.

想想, 你辛辛苦苦做了一个高速的 字符串-->index map, 号称消耗 2G cpu 20%
的能力可以每秒钟检索 30M Bytes, 别人说, 我花 $10 买个内存, 不用消耗这么
贵的 cpu 的能力, 就可以每秒钟检索 800M, 哈哈, 有何感受.

网络上很多设备, 都必须用硬件来加速, 例如, 可以跟踪 session 的路由器, 对
于每一个包, 要查这个包是否在已管理的session 中, 要根据 ip src addr / src
port / dstr addr dst port 来查, 如果不用关联存储来查的话, 你要怎样构造数
据结构, 才能在短短的几个时钟周期内查出来 ? 我想过这个问题, 想不出来.

Jian Wang 写道:
> TCAM这么牛？长见识了。
> 应该是内存芯片和控制器组合实现的吧？
>

[red...@gmail.com]

Eli 写道:

> 另外我觉得程序员写程序的方法肯定得变. 现在据我观察, C#这样的阵营里没有多少人关心这个. 关键是有多少运算时上下文相关的. 凡是一个不相关
> 的任务, 都应该委托到一个新的线程实现, 然后有一个线程等待各线程的回调的结果, 收到全部结果后再继续下一个必须顺序执行

不相关的任务, 从来就是好处理的.
完全无法分拆的任务, 也就不用动脑筋了.

问题是, 部分相关的任务, 才是让人头痛的.

考虑一个 c++ 编译器, 可以使用多个线程编译同一个编译单元的, 这个任务, 并
不是完全无法分拆的 ---- 例如, 某个函数, 外围的变量定义, 语句已经分析完
毕, 内部的block, 实际上可以并行分析; 文件级别看, 某个文件, 最外层的类,
他们的 api 级别已经完毕的话, 各个函数体的分析, 也是可以并行的; 但是, 并
发的线程之间要共享的东西也不少, 所以要高效地做好类似的工作, 并不是一个简
单的事情.

> 的片段. 所以多核并不
> 会加强哪种语言, 而是所有的程序员都应该换换思路了.
>

[Eli]

你说的是, 嘿嘿, 不过你不觉得一个不简单的事情, 正好是把用功和不用功的程序员划分出来的最好方式么?

另外你说的硬件加速这个我也很感兴趣, 我比较期待的是比较平民化的偏重于不同种类计算的可编程硬件的出现, 什么算法成为瓶颈, 没关系, 根据特征
买一个合适种类的玩意, 把该过程在这个硬件上实现完了.

[abware]

最优秀的技术不一定会最流行，有缺陷的技术往往成为事实上的标准。
C++目前最大的优势就是历史的积累。

On Nov 27, 12:09 pm, pongba <pon...@gmail.com> wrote:
> 重申讨论核心：
>
> 我的观点是C++当然目前还没有消亡；而且在并发普及到一定程度之前也不会消亡。
> 但一旦并发成为效率获得的唯一途径，C++的领土便只剩下需要跟机器接触的那一类程序了。
> 我无法预测这个事情多久会发生，但一旦某种程序员友好的并发编程范式（STM？Message-Passing？）被广泛工业化，这个事情便无可避免地会发生了-。
>
> BTW.
> 这里面一个重要的观点我需要重复一遍：即就算C++以后引入很好的并发编程支持，也无济于事。因为这不是他的唯一优点。另一方面，C++却总有唯一的缺点：就是-为了达到零惩罚而折衷了的语言抽象模型。新生的语言既有并发支持，从而能够在效率上达到要求，又没有妥协了的语言抽象；于是将成为高性能开发的首选。
>
> [这个前景对于热爱C++的人来说是阴暗的，但实际上正是自然选择的深刻反映：C++在特定历史背景下脱颖而出，因为那时候C++设计中作出的折衷换来的是更大-的好处。现在，一旦我们不再需要通过这个折衷来换取这个好处，折衷便立即成了坏处。简而言之，环境发生了变化，在以往具有适应意义的特性不再适合，除了进化之外-，只有淘汰。（不过语言进化始终都受到兼容性的影响，这是所有API设计者的切肤之痛。C++本身无法摆脱旧形骸，但新的语言会站立在C++倒下的地方，正如B-jarne所说，C++内部，有一门更小巧的语言急切地想要破壳而出！）]
>
> On Nov 26, 2007 10:01 PM, pongba <pon...@gmail.com> wrote:
>
>
>
>
>
> > *我觉得这个问题应该这样来提问：
>
> > 1. 目前C++的应用领域是哪些（要精确）。
> > 2. 目前C++所占领的领域，是因为非C++不可，还是因为政治或历史原因？（逐个分析）
> > 3.
> > 这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing...-）），为什么。
> > 4. C++独一无二（不可取代）的优势到底是什么？
>
> > 其实，以上的问题内可以把C++换成任意一门其他语言。
> > *
> > 最后说说我的观点：以往，人们普遍认为C++的独一无二的优势是效率。而C为什么不更好呢？C同样效率且语言模型更简单。但语言模型更简单并不代表用该语言编程-就更简单。OB/OO/GP是已经被实践证明的有效范式（虽然OO的定义似乎从来就没有明确过，但OB至少还是可以谈论的），如果没有first-class支-持，而又要用到的话，就很难搞了。也就是说，当"鱼（first-class的范式支持）我所欲也；熊掌（效率）亦我所欲也"的时候，也就只剩下C++这个选手-了。为此用C++编程的人宁可仍受各种各样的非本质复杂性，因为与刚才那两个需求相比，这些非本质复杂性至少是可以克服的。
>
> > 以上这个论点建立在一个前提之上，及C++的某些特点导致了它的高效。什么特点？接近机器的抽象模型。（OO的实现方式，GP的实现方式）这使得语言在实现高级-编程范式的时候做到了零惩罚（中间层几乎被削减到无）。这个零惩罚当然是有代价的（昂贵的代价），比如GP在C++中的实现就并非是"运行期+非绑定"的（ru-by的是）。
>
> > 而这个前提又建立在另一个前提之上，也就是：传统的程序是通过减少抽象惩罚来最大化执行效率的。这才使得C++这种语言实现抽象惩罚最小的语言在一些领域成为独-一无二的选择。
>
> > 那么，我们来看最后这一个前提到了并发时代还能满足吗？
>
> > 显然，通过减少抽象惩罚而获得的效率提升跟通过提高并发程度获得的效率提升一比就微不足道了。
>
> > 以上论点的前提是：该程序必须要能够并行化到一定程度。如果本质上决定了必须要串行执行或者并行化带来的收效甚微，那就白搭了。
>
> > 于是，要证明C++的优势在并发时代会消失。我们只需证明，目前C++应用领域中的主体软件，是可以通过并行化来提到一个非平凡的效率的，这个非平凡的效率提升-将使得通过减少抽象惩罚来获得的效率提升变得微不足道。
>
> > 例如，传统上，图像处理和游戏被认为是C++的经典领域，但考虑到并发，这个领域还能保留吗？这两个领域可都是能够高度并发的。
>
> > 我觉得这个结论基本就不需要证明了。
>
> > 好，如果这个结论成立。那么随之就带来了一个重要推论：
>
> > 原来C++是为了减少抽象惩罚从而在语言的抽象模型上做了很大的折中（比如前面提到的GP的实现），本来这个折中是个优点，因为它换来了效率。而现在突然换不到-效率了，那就立即变成了大大的缺点。如果同样都能获得效率，难道不是用更自然的ruby更让人舒服吗？
>
> > 回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的
> > 决策是：通过实现零惩罚的抽象（OO、GP），来达到效率+抽象兼得的目的。而这个决策，在当前的背景下，由一个优点，变成了一个缺点，因为它折中了抽
> > 象。如果我们不再需要通过零惩罚的抽象类来获得效率，"零惩罚的抽象"所带来的结果就只是不友好的编程范式。
>
> > 有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。
>
> > 剩下的问题是：
>
> > 那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）
>
> > 也许是有的，我可以列出两点：
>
> > 1. 直接操纵硬件。
> > 2. 静态类型系统。
>
> > 第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用-什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具-有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
>
> > 第二点的优势目前我也不特别肯定。静态类型系统，众所周知，有助于尽早发现问题。动态语言为了"动"起来，其实也折中了静态类型系统的优点，导致了一些批评（比-如ruby的ducktyping需要concept）。但我的看法是，ruby如果能够加上一定的静态类新成分，再加上程序自动验证领域的进展，最终会弥补这-个缺陷。但这方面我也不是很了解，所以留给了解的人评说。
>
> > 总之我得出的结论就是，并发的普及将导致C++的领域最终缩减到需要直接操纵硬件的领域，并且在这个领域还有可能被其他语言取代（因为通过减少抽象惩罚来获得效-率不再必要，使得为了减少抽象惩罚而折中的语言模型成为一个极大的弱点）。这里只有一个漏洞，就是在这些需要直接操纵硬件的底层领域，又有多少是能够通过并发来-获得效率的，如果不能并行化，那还是得借助于C++的零惩罚的语言模型。但无论如何，这样的领域怎么也不会太大了。
>
> > 换句话说，一段时间之后，非C++不可的领域是什么呢？这个领域必须有以下特点：
>
> > 1. 需要直接操纵硬件（C、D、C++）。
> > 2. 需要效率。（C、D、C++）。
> > 3. 无法通过并行化来获得想得到的效率，而只能依赖于语言抽象的零惩罚。（C、C++）
> > 4. 需要用到方便的库。（C++）
>
> > 满足这些条件的应用，有哪些呢？驱动开发，略高于驱动层面上的运行时开发，还有吗？
>
> --
> 刘未鹏(pongba)|C++的罗浮宫http://blog.csdn.net/pongba
> TopLanguagehttp://groups.google.com/group/pongba- Hide quoted text -
>
> - Show quoted text -

[red...@gmail.com]

abware 写道:

最优秀的技术不一定会最流行，有缺陷的技术往往成为事实上的标准。
C++目前最大的优势就是历史的积累。

  

看看这个表, 虽然准确度被一些人质疑, 但是多少还有一些参考意义, 特别是某个语言自身百分比的趋势.
1. C++ 的趋势是显著下降的
2. C++ 其实还不如 C 被关注得多
3. cobol 曾经是数据处理事实上的标准语言, 现在还排名15, 那是因为大量的应用由于风险因素, 不能随便换掉

退步最大的三个语言: C, C++, Perl, 主要的原因应该还是不容易使用吧 ?

如果 C++ 难学难用编译慢的名声继续下去, C++ 历史的积累, 恐怕作用就是和 cobol 的积累一样, 让 C++ 可以在前二十位甚至前十名长期占领一个位置, 但是不会再有人用这个语言开发新项目.

表里面的语言, Java, PHP, Python, C#, Ruby, D 都是一些很上进, 社区也很积极的语言 ---- 嗯, 从 es4 看来, Javascript 也很激进; C, PL/SQL 语言说不上很上进, 但是确实有一大块的领地是占的很稳的;

Position Dec 2007	Position Dec 2006	Delta in Position	Programming Language	Ratings Dec 2007	Delta Dec 2006	Status
1	1		Java	20.049%	+0.14%	A
2	2		C	13.173%	-3.44%	A
3	4		(Visual) Basic	10.219%	+1.31%	A
4	5		PHP	8.393%	-0.14%	A
5	3		C++	7.871%	-2.54%	A
6	7		Python	4.697%	+0.93%	A
7	6		Perl	4.383%	-2.01%	A
8	8		C#	3.994%	+0.82%	A
9	11		Ruby	3.089%	+0.76%	A
10	10		JavaScript	2.733%	+0.17%	A
11	9		Delphi	2.673%	+0.10%	A
12	14		D	1.633%	+0.66%	A
13	13		PL/SQL	1.394%	+0.05%	A
14	12		SAS	1.393%	-0.84%	A
15	18		COBOL	0.894%	+0.29%	A-

[Atry]

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

Eli 写道:

我不认为云风不知道这一点。实际上，从和云风的讨论中，我发现他对设计的认识是非常深刻的。而Linus所言也是对的，只不过前提是在他从事的领域之内。
此外，"心智包袱"是说非本质复杂性，而不是C++用于换取一些东西所必须付出的代价（比如分为明显的动静两种语言特性----OO和GP）。D语言就很大程度上消除了这些"心智包袱"；而同样保有了效率和抽象。C++则要等0x，不过C++的优势在于既有代码基。

    

D语言我不太懂, 但是我请你注意的是为什么我不懂这一事实, 谁在支持D, 谁在推广D, 我用D时找到所有我想要的东西吗? 大量的文档, 社区的
帮助, SourceForge上的源代码?

   这个, 我来说说我的看法.

   我觉得, 一个设计得好的语言, 要学懂语言本身, 看基本的手册, 入门书, 简单的范例就应该足够了, 如果搞到需要网上大量资源去讨论语言的基本使用, 那是失败.
   互联网网上的项目, 文档, 社区, 应该是去讨论基于这个语言的种种框架和库, 而不是去讨论种种 workaround, 以及标准库太少而各人重重复复做的类似的库.

   说到C++, 网上的东西, 排除掉这些, 剩下的很多吗? 我觉得比 C 和 Java 都少.

   当然, 如果要开发 Windows GUI 程序, 不想要虚拟机, 要用编译语言, 要界面漂亮, 要好的调试器, 那除了VC ++, 也没啥选择.

你忘了 Delphi 吧， Delphi 开发 GUI 程序效率比 VC/MFC 高