并发讨论:C++已经死了吗?(C++的明天会怎样?)

191 views
Skip to first unread message

pongba

unread,
Nov 26, 2007, 9:01:18 AM11/26/07
to pon...@googlegroups.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++换成任意一门其他语言。

最后说说我的观点:以往,人们普遍认为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

unread,
Nov 26, 2007, 9:14:59 AM11/26/07
to pon...@googlegroups.com
以后的掌上智能设备也许是条路 不光是驱动 上面应该有许多对性能要求高的应用 Java做不到 C又太轮子 或许CPP可以填补

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

hayate

unread,
Nov 26, 2007, 9:16:06 AM11/26/07
to pon...@googlegroups.com
还有 一些大型的科学计算 高性能服务器 它们都有抽象的需要

pongba

unread,
Nov 26, 2007, 9:18:02 AM11/26/07
to pon...@googlegroups.com
On Nov 26, 2007 10:14 PM, hayate <haya...@gmail.com> wrote:
以后的掌上智能设备也许是条路 不光是驱动 上面应该有许多对性能要求高的应用 Java做不到 C又太轮子 或许CPP可以填补
根据我的看法,如果这个性能可以通过并发获得的话,就没有必要用C++了。

pongba

unread,
Nov 26, 2007, 9:20:12 AM11/26/07
to pon...@googlegroups.com


On Nov 26, 2007 10:16 PM, hayate <haya...@gmail.com> wrote:
还有 一些大型的科学计算 高性能服务器 它们都有抽象的需要

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

hayate

unread,
Nov 26, 2007, 9:46:35 AM11/26/07
to pon...@googlegroups.com
嗯 这个不好说。
如果真像你所说 可以接受有代价的抽象模型 换得更好的性能或者别的 那么不采用c++是自然的
我也不知道这样的应用是什么?应用广不广?

Googol Lee

unread,
Nov 26, 2007, 10:00:08 AM11/26/07
to pon...@googlegroups.com
在并发面前,还是要看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

unread,
Nov 26, 2007, 10:32:31 AM11/26/07
to pon...@googlegroups.com
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

unread,
Nov 26, 2007, 11:00:06 AM11/26/07
to pon...@googlegroups.com
驱动开发主要还是 C 的, C++ 开发驱动, 主要是给那些不是特别专业开发驱动的
厂商, 使用第三方 easy library 开发的时候, 才用 C++.

Kimi Zhang

unread,
Nov 26, 2007, 1:03:24 PM11/26/07
to TopLanguage
C++0x绝对是对语言本身的一针强心剂。我很期待。

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

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

寒光

unread,
Nov 26, 2007, 7:58:28 PM11/26/07
to TopLanguage
我觉得大家讨论了问题的一个方面:
即C++能做到的,别的语言也能做到,为什么要用C++;
但问题的另一面呢,别的语言能做到的,C++也能做到,我为什么要换!

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

buhongbo

unread,
Nov 26, 2007, 8:04:54 PM11/26/07
to pon...@googlegroups.com
我有一个很幼稚的问题:为什么一定要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

unread,
Nov 26, 2007, 8:40:56 PM11/26/07
to pon...@googlegroups.com
On Nov 27, 2007 9:04 AM, buhongbo <buho...@gmail.com> wrote:
我有一个很幼稚的问题:为什么一定要C++语言本身来支持并发呢? 都知道,
unix系统为支持并发提供了许多基本的机制。让操作系统自己提供并发,
然后我们运用C++语言来把这种支持做到我们的应用中,难道不好吗?
答案很简单.
1. 为了可移植的代码.
2. 语言必须本身支持基本的并发内存模型,将并发完全建造在库中已经被证明是行不通的.(参考我的一篇blog)

R.C Wu

unread,
Nov 26, 2007, 9:45:29 PM11/26/07
to pon...@googlegroups.com
用TM来实现并行的话,C/C++还是很有优势的……
回顾C++被提出的历史背景:无并发、CPU处理效率低、需要语言支持first-class的编程范式。我们不难发现C++的设计中作出的一个最重要的决策是:通过实现零惩罚的抽象(OO、GP),来达到效率+抽象兼得的目的。而这个决策,在当前的背景下,由一个优点,变成了一个缺点,因为它折中了抽象。如果我们不再需要通过零惩罚的抽象类来获得效率,"零惩罚的抽象"所带来的结果就只是不友好的编程范式。

red...@gmail.com

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

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

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

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

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

pongba

unread,
Nov 26, 2007, 11:09:53 PM11/26/07
to pon...@googlegroups.com
重申讨论核心:

我的观点是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:

莫华枫

unread,
Nov 26, 2007, 11:39:45 PM11/26/07
to pon...@googlegroups.com
语言和人不一样。人寿命到了,就死了。语言只有在无法满足需要,并且出现替代物的时候才会被逐步替代。

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

unread,
Nov 27, 2007, 12:02:04 AM11/27/07
to pon...@googlegroups.com
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

unread,
Nov 27, 2007, 1:51:05 AM11/27/07
to pon...@googlegroups.com

sutter不是发文是并发是c++新的机会么,近来并发领域是个什么情况
在07-11-27,pongba <pon...@gmail.com> 写道:

莫华枫

unread,
Nov 27, 2007, 2:14:58 AM11/27/07
to pon...@googlegroups.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/

王磊

unread,
Nov 27, 2007, 3:24:15 AM11/27/07
to pon...@googlegroups.com
关于并发什么的不是很明白,可是对于一个语言是不是会消亡,我想对于软件行业来说,接触过项目开发的人多少都会知道这样一个规律,就是只要这段代码还能完成我们对业务的要求,就绝不会推翻重写。即使只有上百行。同理目前大型设备企业中运行的系统用c++写成的还是很大比例的。因此除非这些系统不能满足需求,不然客户就会不断的在原有的系统上继续开发下去。
 
别说什么新的语言新的技术如何如何。最简单的道理就是对于商业系统来说,稳定才是第一位。你可以说我用新技术新语言能实现省很多代码,节省很多时间,可是客户不会同意你重写一个系统,每多写一本程序所引入的bug及新的问题都会呈几何级数的增加,直到崩溃。
 
只是c++对未来的竞争力却是堪忧。

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

pongba

unread,
Nov 27, 2007, 3:27:45 AM11/27/07
to pon...@googlegroups.com
On Nov 27, 2007 4:24 PM, 王磊 <wangle...@gmail.com> wrote:
关于并发什么的不是很明白,可是对于一个语言是不是会消亡,我想对于软件行业来说,接触过项目开发的人多少都会知道这样一个规律,就是只要这段代码还能完成我们对业务的要求,就绝不会推翻重写。即使只有上百行。同理目前大型设备企业中运行的系统用c++写成的还是很大比例的。因此除非这些系统不能满足需求,不然客户就会不断的在原有的系统上继续开发下去。
 

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

redsea(肖海彤)

unread,
Nov 27, 2007, 4:40:08 AM11/27/07
to pon...@googlegroups.com
这就是我前段时间碰到的问题,  我面对自己的一个新领域, 同时也是一个新公司起步阶段, 急着寻找 C++ 的替代品的原因. 一旦公司的积累在这个语言上了, 就不容易改变了, 毕竟我们不是做 MIS 的公司, 改动起来伤筋动骨的.
 
现在决定积累在 C, D, 和 Python 上面.
 
在07-11-27,王磊 <wangle...@gmail.com> 写道:

liang

unread,
Nov 27, 2007, 6:32:09 AM11/27/07
to TopLanguage
我和荣耀老师聊天的时候,他指出一个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

unread,
Nov 27, 2007, 6:59:08 AM11/27/07
to pon...@googlegroups.com
c++把兼容性看的如此重要也是不想失去遗留代码领域的支持,话说,是不是进了标准库的东西就没法剔除了,c++倾向于用库来解决问题而不是语言进化,理由是库方便进化,而兼容性。。。

在 07-11-27,liang<adam...@gmail.com> 写道:

莫华枫

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

Sean Lin

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

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


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

wing fire

unread,
Nov 28, 2007, 10:14:45 PM11/28/07
to pon...@googlegroups.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那种东西,语法上简直有反人类的嫌疑。充其量,也只能算是并行领域的汇编语言。用这些东西,对我来说,基本没有精力去思考和问题本身相关的事情了。并发的大门还没完全打开,现在就下结论为时过早。如果用操作系统来打比方,现在还是设计原子操作,中断门,重入的阶段。离完整的内存管理,进程调度还早着呢。

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

Atry

unread,
Nov 28, 2007, 11:14:38 PM11/28/07
to pon...@googlegroups.com
在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

unread,
Nov 28, 2007, 11:14:50 PM11/28/07
to TopLanguage
我觉得,在C++的使用上,应该以达到程序设计目的为目标。
现在好像更多的是以炫耀为目标。
将C++神圣化,也是各种语言与之争论不断,不停攀比的原因之一。

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

CAXSOFT

unread,
Nov 28, 2007, 11:39:12 PM11/28/07
to pon...@googlegroups.com
同意。
没有见过哪门语言真正的死去,因为总有它的用武之地。

 
在07-11-29,holmescn <holme...@gmail.com> 写道:

cherokee

unread,
Nov 29, 2007, 8:30:42 AM11/29/07
to pon...@googlegroups.com
开了眼了,呵呵。尽管内中技术太半都未曾深入了解,但这样的讨论倒是增长见识的好机会。
这篇博:
http://blog.csdn.net/longshanks/
里边c++相关的资料也颇为过瘾。
only mark.
甚谢甚谢!

Jian Wang

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


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

在 07-11-29,cherokee<tec...@gmail.com> 写道:

pongba

unread,
Nov 29, 2007, 9:17:22 AM11/29/07
to pon...@googlegroups.com


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

unread,
Nov 29, 2007, 9:45:48 AM11/29/07
to pon...@googlegroups.com
> 主要是理性分析,有批评也是理性的批评。
> 理由我已经在第一篇帖子里面陈述得很清楚了,感觉真正看的人很少,因为除了莫兄基本没有人对我的想法提出具体的意见。也许我没有说清楚什么是"通过折衷抽象模型来获得效率"?

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

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

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

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

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

SevenCat

unread,
Nov 29, 2007, 10:35:03 AM11/29/07
to TopLanguage


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

unread,
Nov 29, 2007, 10:40:19 AM11/29/07
to TopLanguage
抛开应用空洞的谈论并行,多核,我认为跟抛开程序空空的谈语言的概念一样。

SevenCat

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

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

莫华枫

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

王磊

unread,
Nov 29, 2007, 7:52:13 PM11/29/07
to pon...@googlegroups.com
一门语言何必遭到这么多的批判评价和指责呢?还是大家对他的关心超过了应有的程度。
任何语言都可以实现的东西我们就把他当作一天路,适合就走,不适合就换。
 
多做做项目,就会知道,没有考虑语言好坏的权利。
 
D语言会是新的霸主?乱世阿~

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

buhongbo

unread,
Nov 29, 2007, 7:58:03 PM11/29/07
to pon...@googlegroups.com
就是,就是。我总觉得莫总和pangba讨论的东西太玄了!有点像历史书上讲的那些士人清谈!

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

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

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