并发讨论：C++已经死了吗？（C++的明天会怎样？）
The group you are posting to is a
Usenet group . Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
From:
pongba <pon... @gmail.com> Date: Mon, 26 Nov 2007 22:01:18 +0800
Local: Mon, Nov 26 2007 9:01 am
Subject: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
http://www.codingnow.com >的mailist上，摘抄到目前为止的发言，大家说说：
*Oscar.Ken:*
*孟岩:*
C++中不要谈面向对象，除非你愿意用boost::share_ptr。
COM的想法还是不错的，就是太复杂，有必要自己实现一个简化版。
如果string的内部实现影响了你的工作，那表明你在写系统级程序，在这个级别上，不
*kenneth chia:*
*Shuo Chen:*
*孟岩:*
所以在单机系统里要求告诉执行的任务，比如图形图像处理，实时数据处理，很长时间
但是用C++绝对不要去求奇妙，模仿其他语言的什么高深奇妙的功能，这绝对是个误
*Qutr:*
*邓云:*
*Will Zhang:*
事实上，有许多"高深"的功能C++已经使用了。
我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
*Siney: ... @gmail.com> 写道：
> 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
通过ecx传递好像也只是ms的编译器的做法，而非标准规定，gcc我不清楚，不过即使是想通过寄存器来传递，c也可以申明register吧。
*最后，我觉得这个问题应该这样来提问：
1. 目前C++的应用领域是哪些（要精确）。
其实，以上的问题内可以把C++换成任意一门其他语言。
以上这个论点建立在一个前提之上，及C++的某些特点导致了它的高效。什么特点？接近机器的抽象模型。（OO的实现方式，GP的实现方式）这使得语言在实现高级 编程范式的时候做到了零惩罚（中间层几乎被削减到无）。这个零惩罚当然是有代价的（昂贵的代价），比如GP在C++中的实现就并非是"运行期+非绑定"的（ru by的是）。
而这个前提又建立在另一个前提之上，也就是：传统的程序是通过减少抽象惩罚来最大化执行效率的。这才使得C++这种语言实现抽象惩罚最小的语言在一些领域成为独 一无二的选择。
那么，我们来看最后这一个前提到了并发时代还能满足吗？
显然，通过减少抽象惩罚而获得的效率提升跟通过提高并发程度获得的效率提升一比就微不足道了。
以上论点的前提是：该程序必须要能够并行化到一定程度。如果本质上决定了必须要串行执行或者并行化带来的收效甚微，那就白搭了。
于是，要证明C++的优势在并发时代会消失。我们只需证明，目前C++应用领域中的主体软件，是可以通过并行化来提到一个非平凡的效率的，这个非平凡的效率提升 将使得通过减少抽象惩罚来获得的效率提升变得微不足道。
例如，传统上，图像处理和游戏被认为是C++的经典领域，但考虑到并发，这个领域还能保留吗？这两个领域可都是能够高度并发的。
我觉得这个结论基本就不需要证明了。
好，如果这个结论成立。那么随之就带来了一个重要推论：
原来C++是为了减少抽象惩罚从而在语言的抽象模型上做了很大的折中（比如前面提到的GP的实现），本来这个折中是个优点，因为它换来了效率。而现在突然换不到 效率了，那就立即变成了大大的缺点。如果同样都能获得效率，难道不是用更自然的ruby更让人舒服吗？
回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的
有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。
剩下的问题是：
那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）
也许是有的，我可以列出两点：
1. 直接操纵硬件。
第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用 什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具 有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
第二点的优势目前我也不特别肯定。静态类型系统，众所周知，有助于尽早发现问题。动态语言为了"动"起来，其实也折中了静态类型系统的优点，导致了一些批评（比 如ruby的ducktyping需要concept）。但我的看法是，ruby如果能够加上一定的静态类新成分，再加上程序自动验证领域的进展，最终会弥补这 个缺陷。但这方面我也不是很了解，所以留给了解的人评说。
总之我得出的结论就是，并发的普及将导致C++的领域最终缩减到需要直接操纵硬件的领域，并且在这个领域还有可能被其他语言取代（因为通过减少抽象惩罚来获得效 率不再必要，使得为了减少抽象惩罚而折中的语言模型成为一个极大的弱点）。这里只有一个漏洞，就是在这些需要直接操纵硬件的底层领域，又有多少是能够通过并发来 获得效率的，如果不能并行化，那还是得借助于C++的零惩罚的语言模型。但无论如何，这样的领域怎么也不会太大了。
换句话说，一段时间之后，非C++不可的领域是什么呢？这个领域必须有以下特点：
1. 需要直接操纵硬件（C、D、C++）。
满足这些条件的应用，有哪些呢？驱动开发，略高于驱动层面上的运行时开发，还有吗？
-- http://blog.csdn.net/pongba http://groups.google.com/group/pongba
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
hayate <hayate... @gmail.com> Date: Mon, 26 Nov 2007 22:14:59 +0800
Local: Mon, Nov 26 2007 9:14 am
Subject: Re: [TopLanguage] 并发讨论：C++已经死了吗？（C++的明天会怎样？）
以后的掌上智能设备也许是条路 不光是驱动 上面应该有许多对性能要求高的应用 Java做不到 C又太轮子 或许CPP可以填补
On Nov 26, 2007 10:01 PM, pongba <pon... @gmail.com> wrote:
> 以下讨论正发生在云风的mailist上，摘抄到目前为止的发言，大家说说：
> Oscar.Ken:
> 孟岩:
> C++中不要谈面向对象，除非你愿意用boost::share_ptr。
> COM的想法还是不错的，就是太复杂，有必要自己实现一个简化版。
> 如果string的内部实现影响了你的工作，那表明你在写系统级程序，在这个级别上，不
> kenneth chia:
> Shuo Chen:
> 孟岩:
> 所以在单机系统里要求告诉执行的任务，比如图形图像处理，实时数据处理，很长时间
> 但是用C++绝对不要去求奇妙，模仿其他语言的什么高深奇妙的功能，这绝对是个误
> Qutr:
> 邓云:
> Will Zhang:
> 事实上，有许多"高深"的功能C++已经使用了。
> 我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
> Siney: ... @gmail.com> 写道：
> > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
> 这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
> 最后，我觉得这个问题应该这样来提问：
> 1. 目前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. 直接操纵硬件。
> 第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用 什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具 有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
> 第二点的优势目前我也不特别肯定。静态类型系统，众所周知，有助于尽早发现问题。动态语言为了"动"起来，其实也折中了静态类型系统的优点，导致了一些批评（比 如ruby的ducktyping需要concept）。但我的看法是，ruby如果能够加上一定的静态类新成分，再加上程序自动验证领域的进展，最终会弥补这 个缺陷。但这方面我也不是很了解，所以留给了解的人评说。
> 总之我得出的结论就是，并发的普及将导致C++的领域最终缩减到需要直接操纵硬件的领域，并且在这个领域还有可能被其他语言取代（因为通过减少抽象惩罚来获得效 率不再必要，使得为了减少抽象惩罚而折中的语言模型成为一个极大的弱点）。这里只有一个漏洞，就是在这些需要直接操纵硬件的底层领域，又有多少是能够通过并发来 获得效率的，如果不能并行化，那还是得借助于C++的零惩罚的语言模型。但无论如何，这样的领域怎么也不会太大了。
> 换句话说，一段时间之后，非C++不可的领域是什么呢？这个领域必须有以下特点：
> 1. 需要直接操纵硬件（C、D、C++）。
> 满足这些条件的应用，有哪些呢？驱动开发，略高于驱动层面上的运行时开发，还有吗？
> -- http://blog.csdn.net/pongba
...
read more »
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
hayate <hayate... @gmail.com> Date: Mon, 26 Nov 2007 22:16:06 +0800
Local: Mon, Nov 26 2007 9:16 am
Subject: Re: [TopLanguage] 并发讨论：C++已经死了吗？（C++的明天会怎样？）
还有 一些大型的科学计算 高性能服务器 它们都有抽象的需要
On Nov 26, 2007 10:14 PM, hayate <hayate... @gmail.com> wrote:
> 以后的掌上智能设备也许是条路 不光是驱动 上面应该有许多对性能要求高的应用 Java做不到 C又太轮子 或许CPP可以填补
> On Nov 26, 2007 10:01 PM, pongba <pon... @gmail.com> wrote:
> > Oscar.Ken:
> > 孟岩:
> > C++中不要谈面向对象，除非你愿意用boost::share_ptr。
> > COM的想法还是不错的，就是太复杂，有必要自己实现一个简化版。
> > 如果string的内部实现影响了你的工作，那表明你在写系统级程序，在这个级别上，不
> > kenneth chia:
> > Shuo Chen:
> > 孟岩:
> > 所以在单机系统里要求告诉执行的任务，比如图形图像处理，实时数据处理，很长时间
> > 但是用C++绝对不要去求奇妙，模仿其他语言的什么高深奇妙的功能，这绝对是个误
> > Qutr:
> > 邓云:
> > Will Zhang:
> > 事实上，有许多"高深"的功能C++已经使用了。
> > 我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
> > Siney: ... @gmail.com> 写道：
> > > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
> > 这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
> > 最后，我觉得这个问题应该这样来提问：
> > 1. 目前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. 直接操纵硬件。
> > 第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用 什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具 有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
> > 第二点的优势目前我也不特别肯定。静态类型系统，众所周知，有助于尽早发现问题。动态语言为了"动"起来，其实也折中了静态类型系统的优点，导致了一些批评（比 如ruby的ducktyping需要concept）。但我的看法是，ruby如果能够加上一定的静态类新成分，再加上程序自动验证领域的进展，最终会弥补这 个缺陷。但这方面我也不是很了解，所以留给了解的人评说。
> > 总之我得出的结论就是，并发的普及将导致C++的领域最终缩减到需要直接操纵硬件的领域，并且在这个领域还有可能被其他语言取代（因为通过减少抽象惩罚来获得效 率不再必要，使得为了减少抽象惩罚而折中的语言模型成为一个极大的弱点）。这里只有一个漏洞，就是在这些需要直接操纵硬件的底层领域，又有多少是能够通过并发来 获得效率的，如果不能并行化，那还是得借助于C++的零惩罚的语言模型。但无论如何，这样的领域怎么也不会太大了。
> > 换句话说，一段时间之后，非C++不可的领域是什么呢？这个领域必须有以下特点：
> > 1. 需要直接操纵硬件（C、D、C++）。
...
read more »
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
pongba <pon... @gmail.com> Date: Mon, 26 Nov 2007 22:18:02 +0800
Local: Mon, Nov 26 2007 9:18 am
Subject: Re: [TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
... @gmail.com> wrote:
> 以后的掌上智能设备也许是条路 不光是驱动 上面应该有许多对性能要求高的应用 Java做不到 C又太轮子 或许CPP可以填补
根据我的看法，如果这个性能可以通过并发获得的话，就没有必要用C++了。
> On Nov 26, 2007 10:01 PM, pongba <pon... @gmail.com> wrote:
> > Oscar.Ken:
> > 孟岩:
> > C++中不要谈面向对象，除非你愿意用boost::share_ptr。
> > COM的想法还是不错的，就是太复杂，有必要自己实现一个简化版。
> > 如果string的内部实现影响了你的工作，那表明你在写系统级程序，在这个级别上，不
> > kenneth chia:
> > Shuo Chen:
> > 孟岩:
> > 所以在单机系统里要求告诉执行的任务，比如图形图像处理，实时数据处理，很长时间
> > 但是用C++绝对不要去求奇妙，模仿其他语言的什么高深奇妙的功能，这绝对是个误
> > Qutr:
> > 邓云:
> 我做的是视频编码，这个方向是明显的计算密集性工作，实时性压倒一切。除了汇编语言外，C/C++是唯一能接受的高级语言。而且C/C++对系统资源的使用，如 内存的使用，有非常明显的可控制性。这在对资源要求很严格的情况下C/C++也是优先选择。从这个角度看，视频压缩和图形图像处理，实时系统处理领域里，短期内 还不会有能代替C/C++的语言。
> > Will Zhang:
> > 事实上，有许多"高深"的功能C++已经使用了。
> > 我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
> > Siney: ... @gmail.com> 写道：
> > > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
> > 这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
> > 最后，我觉得这个问题应该这样来提问：
> > 1. 目前C++的应用领域是哪些（要精确）。
> 这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing... ）），为什么。
> > 其实，以上的问题内可以把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. 直接操纵硬件。
> 第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用 什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具 有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
> 第二点的优势目前我也不特别肯定。静态类型系统，众所周知，有助于尽早发现问题。动态语言为了"动"起来，其实也折中了静态类型系统的优点，导致了一些批评（比 如ruby的ducktyping需要concept）。但我的看法是，ruby如果能够加上一定的静态类新成分，再加上程序自动验证领域的进展，最终会弥补这 个缺陷。但这方面我也不是很了解，所以留给了解的人评说。
> 总之我得出的结论就是，并发的普及将导致C++的领域最终缩减到需要直接操纵硬件的领域，并且在这个领域还有可能被其他语言取代（因为通过减少抽象惩罚来获得效 率不再必要，使得为了减少抽象惩罚而折中的语言模型成为一个极大的弱点）。这里只有一个漏洞，就是在这些需要直接操纵硬件的底层领域，又有多少是能够通过并发来 获得效率的，如果不能并行化，那还是得借助于C++的零惩罚的语言模型。但无论如何，这样的领域怎么也不会太大了。
> > 换句话说，一段时间之后，非C++不可的领域是什么呢？这个领域必须有以下特点：
> > 1. 需要直接操纵硬件（C、D、C++）。
...
read more »
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
pongba <pon... @gmail.com> Date: Mon, 26 Nov 2007 22:20:12 +0800
Local: Mon, Nov 26 2007 9:20 am
Subject: Re: [TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
hayate <hayate... @gmail.com> Date: Mon, 26 Nov 2007 22:46:35 +0800
Local: Mon, Nov 26 2007 9:46 am
Subject: Re: [TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
嗯 这个不好说。
如果真像你所说 可以接受有代价的抽象模型 换得更好的性能或者别的 那么不采用c++是自然的
我也不知道这样的应用是什么？应用广不广？
On Nov 26, 2007 10:20 PM, pongba <pon... @gmail.com> wrote:
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
"Googol Lee" <googol... @gmail.com> Date: Mon, 26 Nov 2007 23:00:08 +0800
Local: Mon, Nov 26 2007 10:00 am
Subject: Re: [TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
在并发面前，还是要看0x的工作进展如何吧。如果0x标准广泛接受，那么整个社区都会动起来，包括广泛的跨平台库（不用再考虑pthread和CreateTh read的区别），庞大的使用经验（Effective
Thread？）。像erlang，shhema这种天生并行语言确实是更有优势，但是，资源总是稀缺的，cpu内存资源也一样。而且，这种动态语言在内存管理 上应该不占优势吧，虽然内存越来越便宜，但随便就用个1、2g的应用也越来越多了。
其实，ruby，shema，python在使用的时候一样有自己的经验技巧，尤其是在要求性能的时候。比如python里range和rangex的效率就有 明显差异。C++因为用的人太多，而且经常用在强性能的地方，觉得这个问题被夸大了。
至于C，我觉得C现在相对于C++的最大优势就是编译器实现简单，所以各个平台（包括众多的嵌入式，比如国产青云51系列单片机）都有C编译器，但不一定有C+ +编译器（那种C++
在 07-11-26，pongba<pon... @gmail.com> 写道：
--
新的理论从少数人的主张到一统天下，并不是因为这个理论说服了别人抛弃旧观点，而是因为一代人的逝去。
My blog: http://googollee.blog.163.com
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
pongba <pon... @gmail.com> Date: Mon, 26 Nov 2007 23:32:31 +0800
Local: Mon, Nov 26 2007 10:32 am
Subject: Re: [TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
... @gmail.com> wrote:
> 在并发面前，还是要看0x的工作进展如何吧。如果0x标准广泛接受，那么整个社区都会动起来，包括广泛的跨平台库（不用再考虑pthread和CreateTh read的区别），庞大的使用经验（Effective
> Thread？）。像erlang，shhema这种天生并行语言确实是更有优势，但是，资源总是稀缺的，cpu内存资源也一样。而且，这种动态语言在内存管理 上应该不占优势吧，虽然内存越来越便宜，但随便就用个1、2g的应用也越来越多了。
我的意思是,一旦效率的来源是并发.那么C++的零惩罚抽象模型就不再是优点,而是弱点.因为为了这个零抽象牺牲了抽象模型的能力(如果不是为了效率,temp late和class
inheritance)其实是可以统一起来的,"模板"其实是可以二进制复用的). 以往这个牺牲是值得的,因为他带来了高效率,
而且也只有这个办法能够带来高效率.如今可以通过并发获得更高的效率,那么这招就不需要了.于是这招的影响就只有负面的(受限的抽象模型)了.
> 其实，ruby，shema，python在使用的时候一样有自己的经验技巧，尤其是在要求性能的时候。比如python里range和rangex的效率就有 明显差异。C++因为用的人太多，而且经常用在强性能的地方，觉得这个问题被夸大了。
什么问题被夸大了?
> 至于C，我觉得C现在相对于C++的最大优势就是编译器实现简单，所以各个平台（包括众多的嵌入式，比如国产青云51系列单片机）都有C编译器，但不一定有C+ +编译器（那种C++
我不把C和C++比,我把C++跟一门支持并发并且支持更自然的抽象机制的语言比.
--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba TopLanguage
http://groups.google.com/group/pongba
You must
Sign in before you can post messages.
You do not have the permission required to post.
Date: Tue, 27 Nov 2007 00:00:06 +0800
Local: Mon, Nov 26 2007 11:00 am
Subject: Re: [TopLanguage] 并发讨论：C++已经死了吗？（C++的明天会怎样？）
驱动开发主要还是 C 的, C++ 开发驱动, 主要是给那些不是特别专业开发驱动的
厂商, 使用第三方 easy library 开发的时候, 才用 C++.
> 满足这些条件的应用，有哪些呢？驱动开发，略高于驱动层面上的运行时开发，
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
Kimi Zhang <zhangyafei_k... @163.com> Date: Mon, 26 Nov 2007 10:03:24 -0800 (PST)
Local: Mon, Nov 26 2007 1:03 pm
Subject: Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
C++0x绝对是对语言本身的一针强心剂。我很期待。
就应用领域而言，我所知道的有计算机图形学，部分嵌入式，部分小型操作系统，虚拟机，部分桌面软件。
任何语言都要死，而且C++很可能是我们见证他的死亡，放平心态，见证历史！
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
"寒光" <gmz... @gmail.com> Date: Mon, 26 Nov 2007 16:58:28 -0800 (PST)
Local: Mon, Nov 26 2007 7:58 pm
Subject: Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
我觉得大家讨论了问题的一个方面：
即C++能做到的，别的语言也能做到，为什么要用C++；
但问题的另一面呢，别的语言能做到的，C++也能做到，我为什么要换！
我觉得大家对C++的期望太高了，拔高到了一种近乎仰视的地步
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
"buhongbo" <buhon... @gmail.com> Date: Tue, 27 Nov 2007 09:04:54 +0800
Local: Mon, Nov 26 2007 8:04 pm
Subject: Re: [TopLanguage] 并发讨论：C++已经死了吗？（C++的明天会怎样？）
我有一个很幼稚的问题：为什么一定要C++语言本身来支持并发呢？ 都知道，
unix系统为支持并发提供了许多基本的机制。让操作系统自己提供并发，
然后我们运用C++语言来把这种支持做到我们的应用中，难道不好吗？
我见过一个在Sun V240上运行一个软交换系统平台，它代码90%以上使用的是C++，
我的观点是："并发"不需要做到C++语言本身中,因此C++也不会死。
-------------------------------------------------------------
以下讨论正发生在云风 <http://www.codingnow.com >的mailist上，摘抄到目前为止的发言，大家说说：
*Oscar.Ken:*
*孟岩:*
C++中不要谈面向对象，除非你愿意用boost::share_ptr。
COM的想法还是不错的，就是太复杂，有必要自己实现一个简化版。
如果string的内部实现影响了你的工作，那表明你在写系统级程序，在这个级别上，不
*kenneth chia:*
*Shuo Chen:*
*孟岩:*
所以在单机系统里要求告诉执行的任务，比如图形图像处理，实时数据处理，很长时间
但是用C++绝对不要去求奇妙，模仿其他语言的什么高深奇妙的功能，这绝对是个误
*Qutr:*
*邓云:*
*Will Zhang:*
事实上，有许多"高深"的功能C++已经使用了。
我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
*Siney:
... @gmail.com> 写道：
> 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
通过ecx传递好像也只是ms的编译器的做法，而非标准规定，gcc我不清楚，不过即使是想通过寄存器来传递，c也可以申明register吧。
*最后，我觉得这个问题应该这样来提问：
1. 目前C++的应用领域是哪些（要精确）。
其实，以上的问题内可以把C++换成任意一门其他语言。
以上这个论点建立在一个前提之上，及C++的某些特点导致了它的高效。什么特点？接近机器的抽象模型。（OO的实现方式，GP的实现方式）这使得语言在实现高级 编程范式的时候做到了零惩罚（中间层几乎被削减到无）。这个零惩罚当然是有代价的（昂贵的代价），比如GP在C++中的实现就并非是"运行期+非绑定"的（ru by的是）。
而这个前提又建立在另一个前提之上，也就是：传统的程序是通过减少抽象惩罚来最大化执行效率的。这才使得C++这种语言实现抽象惩罚最小的语言在一些领域成为独 一无二的选择。
那么，我们来看最后这一个前提到了并发时代还能满足吗？
显然，通过减少抽象惩罚而获得的效率提升跟通过提高并发程度获得的效率提升一比就微不足道了。
以上论点的前提是：该程序必须要能够并行化到一定程度。如果本质上决定了必须要串行执行或者并行化带来的收效甚微，那就白搭了。
于是，要证明C++的优势在并发时代会消失。我们只需证明，目前C++应用领域中的主体软件，是可以通过并行化来提到一个非平凡的效率的，这个非平凡的效率提升 将使得通过减少抽象惩罚来获得的效率提升变得微不足道。
例如，传统上，图像处理和游戏被认为是C++的经典领域，但考虑到并发，这个领域还能保留吗？这两个领域可都是能够高度并发的。
我觉得这个结论基本就不需要证明了。
好，如果这个结论成立。那么随之就带来了一个重要推论：
原来C++是为了减少抽象惩罚从而在语言的抽象模型上做了很大的折中（比如前面提到的GP的实现），本来这个折中是个优点，因为它换来了效率。而现在突然换不到 效率了，那就立即变成了大大的缺点。如果同样都能获得效率，难道不是用更自然的ruby更让人舒服吗？
回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的
有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。
剩下的问题是：
那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）
也许是有的，我可以列出两点：
1. 直接操纵硬件。
第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用 什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具 有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
read more »
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
pongba <pon... @gmail.com> Date: Tue, 27 Nov 2007 09:40:56 +0800
Local: Mon, Nov 26 2007 8:40 pm
Subject: Re: [TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
... @gmail.com> wrote:
> 我有一个很幼稚的问题：为什么一定要C++语言本身来支持并发呢？ 都知道，
答案很简单.
1. 为了可移植的代码.
2. 语言必须本身支持基本的并发内存模型,将并发完全建造在库中已经被证明是行不通的.(参考我的一篇blog)
> 我见过一个在Sun V240上运行一个软交换系统平台，它代码90%以上使用的是C++，
> 我的观点是："并发"不需要做到C++语言本身中,因此C++也不会死。
> -------------------------------------------------------------
> 以下讨论正发生在云风 <http://www.codingnow.com >的mailist上，摘抄到目前为止的发言，大家说说：
> *Oscar.Ken:*
> *孟岩:*
> C++中不要谈面向对象，除非你愿意用boost::share_ptr。
> COM的想法还是不错的，就是太复杂，有必要自己实现一个简化版。
> 如果string的内部实现影响了你的工作，那表明你在写系统级程序，在这个级别上，不
> *kenneth chia:*
> *Shuo Chen:*
> *孟岩:*
> 所以在单机系统里要求告诉执行的任务，比如图形图像处理，实时数据处理，很长时间
> 但是用C++绝对不要去求奇妙，模仿其他语言的什么高深奇妙的功能，这绝对是个误
> *Qutr:*
> *邓云:*
> 我做的是视频编码，这个方向是明显的计算密集性工作，实时性压倒一切。除了汇编语言外，C/C++是唯一能接受的高级语言。而且C/C++对系统资源的使用，如 内存的使用，有非常明显的可控制性。这在对资源要求很严格的情况下C/C++也是优先选择。从这个角度看，视频压缩和图形图像处理，实时系统处理领域里，短期内 还不会有能代替C/C++的语言。
> *Will Zhang:*
> 事实上，有许多"高深"的功能C++已经使用了。
> 我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
> *Siney: ... @gmail.com> 写道：
> > 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
> 这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
> *最后，我觉得这个问题应该这样来提问：
> 1. 目前C++的应用领域是哪些（要精确）。
> 这些领域在未来可能被其他语言占领吗？（这里的语言是广义的，并不特指哪一门现有语言，而是指具有一些特性的语言（如gc、dynamic-typing... ）），为什么。
> 其实，以上的问题内可以把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++的设计中作出的一个最重要的
> 有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。
> 剩下的问题是：
> 那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）
> 也许是有的，我可以列出两点：
> 1. 直接操纵硬件。
...
read more »
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
"R.C Wu" <colp... @gmail.com> Date: Tue, 27 Nov 2007 10:45:29 +0800
Local: Mon, Nov 26 2007 9:45 pm
Subject: Re: [TopLanguage] 并发讨论：C++已经死了吗？（C++的明天会怎样？）
----- Original Message -----
From: pongba
To: pongba@googlegroups.com
Sent: Monday, November 26, 2007 10:01 PM
Subject: [TopLanguage] 并发讨论：C++已经死了吗？（C++的明天会怎样？）
以下讨论正发生在云风的mailist上，摘抄到目前为止的发言，大家说说：
Oscar.Ken:
孟岩:
C++中不要谈面向对象，除非你愿意用boost::share_ptr。
COM的想法还是不错的，就是太复杂，有必要自己实现一个简化版。
如果string的内部实现影响了你的工作，那表明你在写系统级程序，在这个级别上，不
kenneth chia:
Shuo Chen:
孟岩:
所以在单机系统里要求告诉执行的任务，比如图形图像处理，实时数据处理，很长时间
但是用C++绝对不要去求奇妙，模仿其他语言的什么高深奇妙的功能，这绝对是个误
Qutr:
邓云:
Will Zhang:
事实上，有许多"高深"的功能C++已经使用了。
我觉得很多东西是这样的，在C++上遇到一些困难，然后用某种奇妙的结构在C++上解决了这个问题，
Siney: ... @gmail.com> 写道：
> 其实，c++的this指针比C的参数传递效率要高。不求别的，单位这个this指针，C++比C要好得多。
这和传递一个structure 指针有什么区别？你是指this是通过ecx来传递而非压栈吗？
最后，我觉得这个问题应该这样来提问：
1. 目前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. 直接操纵硬件。
第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用 什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具 有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
第二点的优势目前我也不特别肯定。静态类型系统，众所周知，有助于尽早发现问题。动态语言为了"动"起来，其实也折中了静态类型系统的优点，导致了一些批评（比 如ruby的ducktyping需要concept）。但我的看法是，ruby如果能够加上一定的静态类新成分，再加上程序自动验证领域的进展，最终会弥补这 个缺陷。但这方面我也不是很了解，所以留给了解的人评说。
总之我得出的结论就是，并发的普及将导致C++的领域最终缩减到需要直接操纵硬件的领域，并且在这个领域还有可能被其他语言取代（因为通过减少抽象惩罚来获得效 率不再必要，使得为了减少抽象惩罚而折中的语言模型成为一个极大的弱点）。这里只有一个漏洞，就是在这些需要直接操纵硬件的底层领域，又有多少是能够通过并发来 获得效率的，如果不能并行化，那还是得借助于C++的零惩罚的语言模型。但无论如何，这样的领域怎么也不会太大了。
换句话说，一段时间之后，非C++不可的领域是什么呢？这个领域必须有以下特点：
1. 需要直接操纵硬件（C、D、C++）。
满足这些条件的应用，有哪些呢？驱动开发，略高于驱动层面上的运行时开发，还有吗？
-- http://blog.csdn.net/pongba
...
read more »
You must
Sign in before you can post messages.
You do not have the permission required to post.
Date: Tue, 27 Nov 2007 11:18:37 +0800
Local: Mon, Nov 26 2007 10:18 pm
Subject: Re: [TopLanguage] 并发讨论：C++已经死了吗？（C++的明天会怎样？）
我觉得 C++ 不会死掉, (甚至 cobol 都没有死啊), 用 C++ 已经写好的, 经典的
程序(很多啊), 也没有多少必要换语言重新写. 但是, 对于新项目, 特别是新公司
/新领域的新项目, C++ 的竞争力肯定在减退.
但是, 硬件的发展 (并发多核, 内存的廉价), 开发成本占整个系统成本的比重的
就拿游戏编程领域来说, 游戏编程号称是很追求效率, 但是服务器端的业务逻辑,
排除掉很低层的应用, 拿稍高层来比较, C 由于有简单的 ABI, 可以作为操作系
C++ 的地位越发尴尬了.
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
pongba <pon... @gmail.com> Date: Tue, 27 Nov 2007 12:09:53 +0800
Local: Mon, Nov 26 2007 11:09 pm
Subject: Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
我的观点是C++当然目前还没有消亡；而且在并发普及到一定程度之前也不会消亡。
BTW.
[这个前景对于热爱C++的人来说是阴暗的，但实际上正是自然选择的深刻反映：C++在特定历史背景下脱颖而出，因为那时候C++设计中作出的折衷换来的是更大 的好处。现在，一旦我们不再需要通过这个折衷来换取这个好处，折衷便立即成了坏处。简而言之，环境发生了变化，在以往具有适应意义的特性不再适合，除了进化之外 ，只有淘汰。（不过语言进化始终都受到兼容性的影响，这是所有API设计者的切肤之痛。C++本身无法摆脱旧形骸，但新的语言会站立在C++倒下的地方，正如B jarne所说，C++内部，有一门更小巧的语言急切地想要破壳而出！）]
On Nov 26, 2007 10:01 PM, pongba <pon... @gmail.com> wrote:
> *我觉得这个问题应该这样来提问：
> 1. 目前C++的应用领域是哪些（要精确）。
> 其实，以上的问题内可以把C++换成任意一门其他语言。
> 以上这个论点建立在一个前提之上，及C++的某些特点导致了它的高效。什么特点？接近机器的抽象模型。（OO的实现方式，GP的实现方式）这使得语言在实现高级 编程范式的时候做到了零惩罚（中间层几乎被削减到无）。这个零惩罚当然是有代价的（昂贵的代价），比如GP在C++中的实现就并非是"运行期+非绑定"的（ru by的是）。
> 而这个前提又建立在另一个前提之上，也就是：传统的程序是通过减少抽象惩罚来最大化执行效率的。这才使得C++这种语言实现抽象惩罚最小的语言在一些领域成为独 一无二的选择。
> 那么，我们来看最后这一个前提到了并发时代还能满足吗？
> 显然，通过减少抽象惩罚而获得的效率提升跟通过提高并发程度获得的效率提升一比就微不足道了。
> 以上论点的前提是：该程序必须要能够并行化到一定程度。如果本质上决定了必须要串行执行或者并行化带来的收效甚微，那就白搭了。
> 于是，要证明C++的优势在并发时代会消失。我们只需证明，目前C++应用领域中的主体软件，是可以通过并行化来提到一个非平凡的效率的，这个非平凡的效率提升 将使得通过减少抽象惩罚来获得的效率提升变得微不足道。
> 例如，传统上，图像处理和游戏被认为是C++的经典领域，但考虑到并发，这个领域还能保留吗？这两个领域可都是能够高度并发的。
> 我觉得这个结论基本就不需要证明了。
> 好，如果这个结论成立。那么随之就带来了一个重要推论：
> 原来C++是为了减少抽象惩罚从而在语言的抽象模型上做了很大的折中（比如前面提到的GP的实现），本来这个折中是个优点，因为它换来了效率。而现在突然换不到 效率了，那就立即变成了大大的缺点。如果同样都能获得效率，难道不是用更自然的ruby更让人舒服吗？
> 回顾C++被提出的历史背景：无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的
> 有人可能会说，那C++也会引入并发模型啊。没错。但问题是，这再也不是C++的唯一优势。如果别人也有并发，C++也有并发，那么为什么非C++不可呢。
> 剩下的问题是：
> 那么，C++还有其它独一无二的优势吗？（这些优势便决定了不远的将来C++的领域）
> 也许是有的，我可以列出两点：
> 1. 直接操纵硬件。
> 第一点使得C++在底层领域仍然是不二之选。为什么不选C？因为C++提供了更好的库（已经不是"因为C++提供了更好的范式了，因为这些底层应用未必要直接用 什么OO）。然而，就算如此，C++的缺点还是存在，那就是为了减少抽象惩罚而折中语言模型。这一点到了并发时代将成为致命的问题，所以既支持指针，并发，又具 有不折中的语言模型的语言（如D）可能会取代之。前提是如果C++不进化的话。
> 第二点的优势目前我也不特别肯定。静态类型系统，众所周知，有助于尽早发现问题。动态语言为了"动"起来，其实也折中了静态类型系统的优点，导致了一些批评（比 如ruby的ducktyping需要concept）。但我的看法是，ruby如果能够加上一定的静态类新成分，再加上程序自动验证领域的进展，最终会弥补这 个缺陷。但这方面我也不是很了解，所以留给了解的人评说。
> 总之我得出的结论就是，并发的普及将导致C++的领域最终缩减到需要直接操纵硬件的领域，并且在这个领域还有可能被其他语言取代（因为通过减少抽象惩罚来获得效 率不再必要，使得为了减少抽象惩罚而折中的语言模型成为一个极大的弱点）。这里只有一个漏洞，就是在这些需要直接操纵硬件的底层领域，又有多少是能够通过并发来 获得效率的，如果不能并行化，那还是得借助于C++的零惩罚的语言模型。但无论如何，这样的领域怎么也不会太大了。
> 换句话说，一段时间之后，非C++不可的领域是什么呢？这个领域必须有以下特点：
> 1. 需要直接操纵硬件（C、D、C++）。
> 满足这些条件的应用，有哪些呢？驱动开发，略高于驱动层面上的运行时开发，还有吗？
--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba TopLanguage
http://groups.google.com/group/pongba
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
"莫华枫" <longshank... @gmail.com> Date: Tue, 27 Nov 2007 12:39:45 +0800
Local: Mon, Nov 26 2007 11:39 pm
Subject: Re: [TopLanguage] 并发讨论：C++已经死了吗？（C++的明天会怎样？）
1. 目前C++的应用领域是哪些（要精确）。
对于我而言，精确很难做到。我的业务领域比较狭窄，而且用周围人的观念来看，这个领域中根本没有c++什么事。但是，我可以提出足够的论据，表明一个在应用业务 开发（如mis）中，在一定的情况下，c++的应用具有绝对的优势。这个观点往往引发口水仗。但是很多事实是无法改变的。多数持相反观点的人往往忽视一些关键性 的问题。他们往往只考虑"做出一个软件"，而不是"做好软件"。这是完全两码事。我的观点很明确：如果贵公司是十来个人、七八条枪，并且只打算零敲碎打地做几个 应用赚点幸苦钱，那么我的论调完全失效。但是，如果一个软件企业有一片完整的业务领域（不是某种单一业务，有时甚至会有好几片），并且需要持续发展的，那么我的 观点在恰当不过。
2. 目前C++所占领的领域，是因为非C++不可，还是因为政治或历史原因？（逐个分析）
3.
这些领域*应当*
4. C++独一无二（不可取代）的优势到底是什么？
c++独一无二的优势自然是其不损失性能和静态特性抽象能力。在09之后，这方面能力更是无人能及。这方面的应用没有被充分地发展，甚至被有意无意地忽视或掩盖 了。这是软件行业的一种损失。很多人没有意识到c++在这方面的优势，及其带来的好处。
至于并发么，我不太清楚问题的所在。只是觉得并发在这里并不是问题的关键。未来提升性能的手段很多，并发是其中之一，这些手段对于各种语言来讲也都是透明的，等 同的。而语言本身的特性是真正"个性"的东西。是决定语言兴亡的基本要素。问题还是人们的认识，人们是否愿意为了获得一些好处而付出另一些代价。多数时候，代价 存在一个阈值，小于阈值的时候，人们很容易地接受，而大于阈值时，无论有多大的好处，都很难接受的。有的人阈值比较高，比如说我。而多数人阈值比较低，倾向于代 价较低的特性，尽管可能在其他方面付出更大的代价。这也就是很多人说C++专家亲和的原因吧。
On Nov 26, 2007 10:01 PM, pongba <pon... @gmail.com> wrote:
...
read more »
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
pongba <pon... @gmail.com> Date: Tue, 27 Nov 2007 13:02:04 +0800
Local: Tues, Nov 27 2007 12:02 am
Subject: Re: [TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
... @gmail.com> wrote:
> 语言和人不一样。人寿命到了，就死了。语言只有在无法满足需要，并且出现替代物的时候才会被逐步替代。
> 1. 目前C++的应用领域是哪些（要精确）。
> 对于我而言，...
那么在两层之间就没有c++的空间吗？很明显，还有很多"中间"型的应用被他们掠去了。比如数据库服务器、数据处理、图形处理、各类基础性的业务服务和组件等等 。这类应用作为各种应用系统承上启下的支柱，规模足够庞大，有严格的性能要求，扩展性、灵活性的要求更高。这些应用要求语言有强大的抽象能力和足够的性能。c性 能占优，但抽象不足，以至难以在成本约束下构建和维护如此复杂的系统。而Java的抽象能力尽管得到提升，非但以损失性能为代价，而且其抽象能力依然无法很好处 理复杂系统（纯oop机制造的孽，使原本复杂的系统更复杂）。
我提出质疑的关键就在这个地方。
在以往，以上这个论述是绝无问题的。然而，在并发普及之后，我猜测这些对性能要求高的应用完全可以通过并发来获得远高于"减少抽象惩罚而榨取出来"的效率。这么 一来，也就是说"减少抽象惩罚"不再成为效率的来源。于是为了减少抽象惩罚而折衷了的语言设计便成了纯粹没好处的缺点了。
> 很多主张回归c的人只看到c++带来的困难，但却忽视了另一个重要的问题，c++代码的各种软件工程统计数据远远优于c，非常接近ada。（我曾经给出过文档） 。这也是很多程序员的局限，只考虑做软件，而不考虑付出的代价。
是的，一来这个代价是可以克服的。二来更关键的是，以前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里面的基本类型和对象类型的分裂，都属此类折衷。
-- http://blog.csdn.net/pongba http://groups.google.com/group/pongba
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
SpitFire <spitfi... @gmail.com> Date: Tue, 27 Nov 2007 14:51:05 +0800
Local: Tues, Nov 27 2007 1:51 am
Subject: Re: [TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
... @gmail.com> 写道：
> On Nov 27, 2007 12:39 PM, 莫华枫 <longshank... @gmail.com> wrote:
> > 语言和人不一样。人寿命到了，就死了。语言只有在无法满足需要，并且出现替代物的时候才会被逐步替代。
> > 1. 目前C++的应用领域是哪些（要精确）。
> > 对于我而言，...
> 那么在两层之间就没有c++的空间吗？很明显，还有很多"中间"型的应用被他们掠去了。比如数据库服务器、数据处理、图形处理、各类基础性的业务服务和组件等等 。这类应用作为各种应用系统承上启下的支柱，规模足够庞大，有严格的性能要求，扩展性、灵活性的要求更高。这些应用要求语言有强大的抽象能力和足够的性能。c性 能占优，但抽象不足，以至难以在成本约束下构建和维护如此复杂的系统。而Java的抽象能力尽管得到提升，非但以损失性能为代价，而且其抽象能力依然无法很好处 理复杂系统（纯oop机制造的孽，使原本复杂的系统更复杂）。
> 我提出质疑的关键就在这个地方。
> 在以往，以上这个论述是绝无问题的。然而，在并发普及之后，我猜测这些对性能要求高的应用完全可以通过并发来获得远高于"减少抽象惩罚而榨取出来"的效率。这么 一来，也就是说"减少抽象惩罚"不再成为效率的来源。于是为了减少抽象惩罚而折衷了的语言设计便成了纯粹没好处的缺点了。
> > 很多主张回归c的人只看到c++带来的困难，但却忽视了另一个重要的问题，c++代码的各种软件工程统计数据远远优于c，非常接近ada。（我曾经给出过文档） 。这也是很多程序员的局限，只考虑做软件，而不考虑付出的代价。
> 是的，一来这个代价是可以克服的。二来更关键的是，以前C++付出折中语言设计从而换取效率的决策是一个好的决策。
> > 可问题是什么代价？学习代价？不错学通c++不是件易事。但是，学习是暂时的，使用是永远的。这几天，我在.net上做软件，
> > ...
> > 4. C++独一无二（不可取代）的优势到底是什么？
> > c++独一无二的优势自然是其不损失性能和静态特性抽象能力。在09之后，这方面能力更是无人能及。
> 实际上，C++为了实现零惩罚的抽象，损害了抽象的自然性。C++中的两种复用机制，一个基于接口的，是动态紧绑定。另一个是基于template的，则是静态 非绑定。而实际上，为什么人们喜欢ruby，就是因为ruby里面的复用机制是动态非绑定的，最自然的。C++的这种区分动静两个世界的做法带来了学习成本，以 往这个成本是必须付出的，因为它带来的好处——效率——远远大于坏处（学习成本）。然而如今（不久的将来），当并发成为效率的来源，我们不再需要利用零惩罚的抽 象来榨取效率；那么可想而知，谁还愿意或者有必要去付出这个非平凡的学习成本呢？
> > 这方面的应用没有被充分地发展，甚至被有意无意地忽视或掩盖了。这是软件行业的一种损失。很多人没有意识到c++在这方面的优势，及其带来的好处。
> > gp所带来的静多态使得我们在软件开发时可以仅仅考虑各种符号的语义，而无须关心具体选择的算法和对象版本。
> > c++的问题是带来这些特性的同时，也带来了大量的"不和谐音"。很多观点都是把c++存在的问题，看作那些特性的问题，加以回避。这种追本求末的认识直接误导 了众多不更世事的芸芸众生。以至于在论坛上，java也在那里同c++叫板比抽象。
> > 至于并发么，我不太清楚问题的所在。只是觉得并发在这里并不是问题的关键。未来提升性能的手段很多，并发是其中之一，
> 除开通过算法提高效率之外。传统上提高效率的办法基本就是减少抽象惩罚来榨取效率。而我的意思是，在并发这个更强大的武器面前，通过减少抽象惩罚来榨取效率的手 法将失去用处。于是就意味着一类语言的生命期结束（包括C#/JAVA/C++），这类语言为了减少抽象惩罚而付出了折衷语言设计的代价。比如C#里面的值类型 和引用类型的分裂，Java里面的基本类型和对象类型的分裂，都属此类折衷。
> -- http://blog.csdn.net/pongba http://groups.google.com/group/pongba
--
SpitFire
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
"莫华枫" <longshank... @gmail.com> Date: Tue, 27 Nov 2007 15:14:58 +0800
Local: Tues, Nov 27 2007 2:14 am
Subject: Re: [TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
On Nov 27, 2007 1:02 PM, pongba <pon... @gmail.com> wrote:
> On Nov 27, 2007 12:39 PM, 莫华枫 <longshank... @gmail.com> wrote:
> > 语言和人不一样。人寿命到了，就死了。语言只有在无法满足需要，并且出现替代物的时候才会被逐步替代。
> > 1. 目前C++的应用领域是哪些（要精确）。
> > 对于我而言，...
> 那么在两层之间就没有c++的空间吗？很明显，还有很多"中间"型的应用被他们掠去了。比如数据库服务器、数据处理、图形处理、各类基础性的业务服务和组件等等 。这类应用作为各种应用系统承上启下的支柱，规模足够庞大，有严格的性能要求，扩展性、灵活性的要求更高。这些应用要求语言有强大的抽象能力和足够的性能。c性 能占优，但抽象不足，以至难以在成本约束下构建和维护如此复杂的系统。而Java的抽象能力尽管得到提升，非但以损失性能为代价，而且其抽象能力依然无法很好处 理复杂系统（纯oop机制造的孽，使原本复杂的系统更复杂）。
> 我提出质疑的关键就在这个地方。
> 在以往，以上这个论述是绝无问题的。然而，在并发普及之后，我猜测这些对性能要求高的应用完全可以通过并发来获得远高于"减少抽象惩罚而榨取出来"的效率。这么 一来，也就是说"减少抽象惩罚"不再成为效率的来源。于是为了减少抽象惩罚而折衷了的语言设计便成了纯粹没好处的缺点了。
> > 很多主张回归c的人只看到c++带来的困难，但却忽视了另一个重要的问题，c++代码的各种软件工程统计数据远远优于c，非常接近ada。（我曾经给出过文档） 。这也是很多程序员的局限，只考虑做软件，而不考虑付出的代价。
> 是的，一来这个代价是可以克服的。二来更关键的是，以前C++付出折中语言设计从而换取效率的决策是一个好的决策。
> > 可问题是什么代价？学习代价？不错学通c++不是件易事。但是，学习是暂时的，使用是永远的。这几天，我在.net上做软件，使用c++/cli，很多方面的算 法都可以做成通用的模板，一劳永逸。在这方面，我至少消减了10%～20%工作量。但是，
> > ...
> > 4. C++独一无二（不可取代）的优势到底是什么？
> > c++独一无二的优势自然是其不损失性能和静态特性抽象能力。在09之后，这方面能力更是无人能及。
> 实际上，C++为了实现零惩罚的抽象，损害了抽象的自然性。C++中的两种复用机制，一个基于接口的，是动态紧绑定。另一个是基于template的，则是静态 非绑定。而实际上，为什么人们喜欢ruby，就是因为ruby里面的复用机制是动态非绑定的，最自然的。C++的这种区分动静两个世界的做法带来了学习成本，以 往这个成本是必须付出的，因为它带来的好处——效率——远远大于坏处（学习成本）。然而如今（不久的将来），当并发成为效率的来源，我们不再需要利用零惩罚的抽 象来榨取效率；那么可想而知，谁还愿意或者有必要去付出这个非平凡的学习成本呢？
> > 这方面的应用没有被充分地发展，甚至被有意无意地忽视或掩盖了。这是软件行业的一种损失。很多人没有意识到c++在这方面的优势，及其带来的好处。
> > gp所带来的静多态使得我们在软件开发时可以仅仅考虑各种符号的语义，而无须关心具体选择的算法和对象版本。
> > c++的问题是带来这些特性的同时，也带来了大量的"不和谐音"。很多观点都是把c++存在的问题，看作那些特性的问题，加以回避。这种追本求末的认识直接误导 了众多不更世事的芸芸众生。以至于在论坛上，java也在那里同c++叫板比抽象。
> > 至于并发么，我不太清楚问题的所在。只是觉得并发在这里并不是问题的关键。未来提升性能的手段很多，并发是其中之一，
> 除开通过算法提高效率之外。传统上提高效率的办法基本就是减少抽象惩罚来榨取效率。而我的意思是，在并发这个更强大的武器面前，通过减少抽象惩罚来榨取效率的手 法将失去用处。于是就意味着一类语言的生命期结束（包括C#/JAVA/C++），这类语言为了减少抽象惩罚而付出了折衷语言设计的代价。比如C#里面的值类型 和引用类型的分裂，Java里面的基本类型和对象类型的分裂，都属此类折衷。
> -- http://blog.csdn.net/pongba http://groups.google.com/group/pongba
--
反者道之动，弱者道之用
m
... @seaskysh.com
longshank
... @gmail.com
http://blog.csdn.net/longshanks/
You must
Sign in before you can post messages.
You do not have the permission required to post.
From:
"王磊" <wanglei830... @gmail.com> Date: Tue, 27 Nov 2007 16:24:15 +0800
Local: Tues, Nov 27 2007 3:24 am
Subject: Re: [TopLanguage] Re: 并发讨论：C++已经死了吗？（C++的明天会怎样？）
别说什么新的语言新的技术如何如何。最简单的道理就是对于商业系统来说，稳定才是第一位。你可以说我用新技术新语言能实现省很多代码，节省很多时间，可是客户不 会同意你重写一个系统，每多写一本程序所引入的bug及新的问题都会呈几何级数的增加，直到崩溃。
只是c++对未来的竞争力却是堪忧。
在07-11-27，莫华枫 <longshank... @gmail.com> 写道：
> 哦，看来是我理解有问题，还有些跑题。
> 刘兄的意思是说下一代语言整个按最强大最完善的抽象设计，然后在尽量在语言特性上考虑性能。剩下的，就依赖各种优化手段处理。最后那些无法弥补的，也可以从并发 上基本得到补偿。这样的话，同c++相比也不会有明显的性能差异。反正抽象第一位，性能地位降低。
> ruby的类型系统形式更加合理，但损失了静态类型的好处。如今，concept浮出水面，使得泛化类型系统由"离散"变为"连续"，于是c++便有机会很好地 处理ducktyping同static
> 如果想要消弭此中问题，看来不敲掉几面墙是不可能的了。关键在于敲掉哪些墙。有些是装饰墙，敲掉无碍，而有些是承重墙，动则伤及根本。c++09不敢动一砖一瓦 ，也只能以涂料粉饰。java、c#声称在c++上改进，实际上敲掉了很多承重墙，摇摇欲坠。而d似乎也没有完全敲对地方。
> On Nov 27, 2007 1:02 PM, pongba < pon... @gmail.com> wrote:
> > On Nov 27, 2007 12:39 PM, 莫华枫 <longshank... @gmail.com> wrote:
> > > 语言和人不一样。人寿命到了，就死了。语言只有在无法满足需要，并且出现替代物的时候才会被逐步替代。
> > > 1. 目前C++的应用领域是哪些（要精确）。
> > > 对于我而言，...
> > 那么在两层之间就没有c++的空间吗？很明显，还有很多"中间"型的应用被他们掠去了。比如数据库服务器、数据处理、图形处理、各类基础性的业务服务和组件等等 。这类应用作为各种应用系统承上启下的支柱，规模足够庞大，有严格的性能要求，扩展性、灵活性的要求更高。这些应用要求语言有强大的抽象能力和足够的性能。c性 能占优，但抽象不足，以至难以在成本约束下构建和维护如此复杂的系统。而Java的抽象能力尽管得到提升，非但以损失性能为代价，而且其抽象能力依然无法很好处 理复杂系统（纯oop机制造的孽，使原本复杂的系统更复杂）。
> > 我提出质疑的关键就在这个地方。
> > 在以往，以上这个论述是绝无问题的。然而，在并发普及之后，我猜测这些对性能要求高的应用完全可以通过并发来获得远高于"减少抽象惩罚而榨取出来"的效率。这么 一来，也就是说"减少抽象惩罚"不再成为效率的来源。于是为了减少抽象惩罚而折衷了的语言设计便成了纯粹没好处的缺点了。
> > > 很多主张回归c的人只看到c++带来的困难，但却忽视了另一个重要的问题，c++代码的各种软件工程统计数据远远优于c，非常接近ada。（我曾经给出过文档） 。这也是很多程序员的局限，只考虑做软件，而不考虑付出的代价。
> > 是的，一来这个代价是可以克服的。二来更关键的是，以前C++付出折中语言设计从而换取效率的决策是一个好的决策。
> > > 可问题是什么代价？学习代价？不错学通c++不是件易事。但是，学习是暂时的，使用是永远的。这几天，我在.net上做软件，
> > > ...
> > > 4. C++独一无二（不可取代）的优势到底是什么？
> > > c++独一无二的优势自然是其不损失性能和静态特性抽象能力。在09之后，这方面能力更是无人能及。
> > 实际上，C++为了实现零惩罚的抽象，损害了抽象的自然性。C++中的两种复用机制，一个基于接口的，是动态紧绑定。另一个是基于template的，则是静态 非绑定。而实际上，为什么人们喜欢ruby，就是因为ruby里面的复用机制是动态非绑定的，最自然的。C++的这种区分动静两个世界的做法带来了学习成本，以 往这
|
