D 、 C++ 、 Java 三种语言的比较

47 views
Skip to first unread message

Atry

unread,
Sep 22, 2007, 3:28:13 AM9/22/07
to pongba


D 2.0 / Tango + MangoC++ 98 / STL + BoostJava 6.0
IDE较差Windows 平台尚可,Linux 平台无好用的 IDE极好
编译速度
函数式编程支持匿名函数STL 有许多基于函数对象的算法,但语言自身不支持匿名函数,而 Boost.Lambda 不很方便。支持匿名类
模板元编程有完善的支持语言本身有支持,但缺少高级语法。用 Boost.MPL 能做到需要的功能,但晦涩冗长。有泛型,但根本没有真正的模板
性能极好极好HotSpot 可以运行时编译,本身生成的机器码运行很快。但缺乏底层直接操作内存的能力。没有办法在栈上构造对象,频繁的动态内存分配可能有损性能。用 JNI 调用本地代码也会带来额外的开销。
垃圾收集
单元测试
语言内置,极其易于使用有一些单元测试框架,但使用不够方便。编译速度慢也使得单元测试更难使用。有 JUnit 、 TestNG ,和 IDE 配合的比较好
容器有,但没有广泛可用的哈希表的标准实现。
XML
文本解析语言内置正则表达式Boost.Xpressive 和 Boost.Spirit ,极其强大的解析框架有正则表达式库
线程和并发有线程、锁和协程(在 Tango 以 Windows 的方式叫作 Fiber),没有线程池和基于消息的定时器 有线程和锁。协程库(Boost.Coroutine)尚未加入 Boost ,而且已经停止开发。线程池和基于消息的定时器可以用Boost.Asio 做到 有线程、锁、线程池和基于消息的定时器,没有协程
同步 IO 流
异步网络 IO有基于 select / epoll 的实现,仅仅只是 C API 的简单包装,使用不很方便。在 Windows 下用的是最糟糕的 select ,非常受限;在 BSD 没有用 kqueue有极好的网络库 Boost.Asio有 nio ,在 Windows 用的是 WSAEventSelect,而没能发挥完成端口的威力

Atry

unread,
Sep 22, 2007, 4:06:28 AM9/22/07
to pongba

分值项目
D 2.0 / Tango + MangoC++ 98 / STL + BoostJava 6.0
11 IDE 4 较差 6
Windows 平台尚可,Linux 平台无好用的 IDE
11 极好
16 编译速度16  0 16
 4 函数式编程 3 支持匿名函数 2
STL 有许多基于函数对象的算法,但语言自身不支持匿名函数,而 Boost.Lambda 不很方便。
 2 支持匿名类
 4 模板元编程 4 有完善的支持 2
语言本身有支持,但缺少高级语法。用 Boost.MPL 能做到需要的功能,但晦涩冗长。
0 有泛型,但根本没有真正的模板
18 性能18 极好18 极好10
HotSpot 可以运行时编译,本身生成的机器码运行很快。但缺乏底层直接操作内存的能力。没有办法在栈上构造对象,频繁的动态内存分配可能有损性能。用 JNI 调用本地代码也会带来额外的开销。
13 垃圾收集10 有不精确的垃圾收集,没有内存整理 0 13 有精确垃圾收集,会自动进行内存整理
9 单元测试
9 语言内置,极其易于使用 4 有一些单元测试框架,但使用不够方便。编译速度慢也使得单元测试更难使用。 7
有 JUnit 、 TestNG ,和 IDE 配合的比较好
6 容器64 有,但没有广泛可用的哈希表的标准实现。6
2 XML2 02
2 文本解析1 语言内置正则表达式2 Boost.Xpressive 和 Boost.Spirit ,极其强大的解析框架1 有正则表达式库
6线程和并发2
有线程、锁和协程(在 Tango 以 Windows 的方式叫作 Fiber),没有线程池和基于消息的定时器
4
有线程和锁。协程库(Boost.Coroutine)尚未加入 Boost ,而且已经停止开发。线程池和基于消息的定时器可以用Boost.Asio 做到
3 有线程、锁、线程池和基于消息的定时器,没有协程
3同步 IO 流333
6异步网络 IO1
有基于 select / epoll 的实现,仅仅只是 C API 的简单包装,使用不很方便。在 Windows 下用的是最糟糕的 select ,非常受限;在 BSD 没有用 kqueue
6 有极好的网络库 Boost.Asio4
有 nio ,在 Windows 用的是 WSAEventSelect,而没能发挥完成端口的威力
100总分79
51
78

我把分值加上去了。C++ 差距这么大的原因是我给垃圾收集和编译速度的权重很大,这两样正好是 C++ 缺的。

Huafeng Mo

unread,
Sep 22, 2007, 4:18:02 AM9/22/07
to pon...@googlegroups.com
Java根本不可能有同D比肩的能力。之所以分数相近,因为语言的抽象能力被弱化了。如果这样的话,D不可能有什么生存的可能性。因为Java和它的差距这么小,却比Java复杂得多,难学得多,Java不就一统天下了吗?
如果定位在高层的应用程序组装,Java的分值肯定会比D和C++都高很多,因为此时易学易用性占的比重很大。但如果定位在系统级开发,Java有能力做系统及开发吗?
另外,最好考虑C++0x,应该面向未来比较,面向过去比较,已经没有太大的意义了。

Atry

unread,
Sep 22, 2007, 4:27:11 AM9/22/07
to pon...@googlegroups.com
你的意思是"函数式编程"和"模板元编程"这两个项目的权重还应该加大?或者还得加上一个"语法糖"的比较项目?如果那样的话,D 肯定可以大胜 Java ;-)
我写这个
的时候比较偏向于实际功能。Java 太成熟了,功能齐全,所以分会比较高。

在07-9-22, Huafeng Mo <longsh...@gmail.com> 写道:

red...@gmail.com

unread,
Sep 22, 2007, 4:31:49 AM9/22/07
to pon...@googlegroups.com
也不是完全不能比, 但是要区分应用的范围,

例如

  驱动程序开发, C/C++ D 可以比比

  高性能服务器(例如 nginx, lighttpd 之类的), C/C++ D Java 可以比比
      (对这种程序而言, 语言带的网络库根本不重要, 都要自己写过)

  高性能应用程序开发(例如 photoshop, or photoshop plugin 之类的)  C++, D, java 可以比比, c 是否参与 ?

  MIS, DSS, ERP, OA 之类的系统, 似乎 C/C++, D 都得出局 ?

另外, 为什么说 C++ 就没有 XML 库呢 ? 只能算 stl & boost 里面有的 ?

 

Huafeng Mo 写道:
Java根本不可能有同D比肩的能力。之所以分数相近,因为语言的抽象能力被弱化了。如果这样的话,D不可能有什么生存的可能 性。因为Java和它的差距这么小,却比Java复杂得多,难学得多,Java不就一统天下了吗?

Huafeng Mo

unread,
Sep 22, 2007, 4:35:05 AM9/22/07
to pon...@googlegroups.com
不,不是这个意思。您漏了一个泛型编程。模板元编程的应用范围不大,多半用在很基础的地方。但泛型编程不一样,它对于一个复杂的大型系统而言,有助于优化整个设计和具体的代码。
我觉得语言的比较应当设定比较的应用范畴。D、C++和Java的比较应该分为两个或更多的领域。至少应该分为应用及编程和系统及编程。如果细分还有更多。在不同的领域中,不同的语言有完全不同的表现。Java根本没有系统及开发的能力。如果说它的得分那么高,怎么向系统开发程序员解释他们一直使用错了语言呢?:-)

Atry

unread,
Sep 22, 2007, 4:43:14 AM9/22/07
to pon...@googlegroups.com
C++、D、Java 都是通用语言。当然,Java 参与不了最底层,但是之上的所有领域。C++、D、Java 都可以比比。

高性能服务器的话,Boost.Asio 绝对可以满足需求的。Java 和 D 的网络库我觉得就有差距了。不过也有用这些网络库做的应用。

高性能应用程序开发......这个被我搞忘了,要是加上 GUI , D 和 C++ 又得输分了。

如果用 C++ 0x 的话,C++ 可以涨很多分。按我上面的表,可以增加二十多分呢。

为什么没有 C ,是因为 C 的比较标准都不一样,如果把 C 放进来,按 C fans 的标准,简单最好。C 最简单, C 满分,其他所有语言 0 分,耶~

我想要比较的话,应该比较一个通用跨平台的标准的语言。而我对 Windows 以外的平台的 .net 不了解,所以没有把 .net 加进来,其实 .net 如果放进来,估计跟 Java 分值差不多,细节可能 .net 有赢的地方,但赢不了很多。

在07-9-22,red...@gmail.com <red...@gmail.com> 写道:

Atry

unread,
Sep 22, 2007, 4:49:22 AM9/22/07
to pon...@googlegroups.com
好吧,那我这个比较应该限制在应用开发的范围。因为只有这个范围是这三种语言的重叠部分。

yq chen

unread,
Sep 22, 2007, 4:51:05 AM9/22/07
to pon...@googlegroups.com
.net赢得多不多是你定的了。如果你把跨平台定为99分,那.net只有一分了。
 
哈哈,开个玩笑。

 
在07-9-22,Atry <pop....@gmail.com> 写道:

red...@gmail.com

unread,
Sep 22, 2007, 4:56:08 AM9/22/07
to pon...@googlegroups.com
Atry 写道:

> C++、D、Java 都是通用语言。当然,Java 参与不了最底层,但是之上的所有领
> 域。C++、D、Java 都可以比比。
>
> 高性能服务器的话,Boost.Asio 绝对可以满足需求的。Java 和 D 的网络库我
> 觉得就有差距了。不过也有用这些网络库做的应用。
>
Asio ? 开销还是有些高, 我看用它开发, 性能顶多就到 apache 级别, 比起顶级
的服务器程序还有一段距离.
至于 java , 我没有怎么用过, 但是听说大连接数的时候, 根本应付不过来.

> 高性能应用程序开发......这个被我搞忘了,要是加上 GUI , D 和 C++ 又得
> 输分了。

不见得分就全部到 Java 那边吧 ? --- 漂亮的 gui 程序, 用 Java 开发的没有几
个呢. 如果拿 eclipse 这个特例来举例,
C++ 的例子就更多了.

>
> 如果用 C++ 0x 的话,C++ 可以涨很多分。按我上面的表,可以增加二十多分呢。

拿没有出来的东西比, 似乎意义不大, 谁就能够说, 过几年, D 没有好的IDE 和
网络库呢? 或者过几年, 这几个语言统统被另外一个打败了呢 ?


>
> 为什么没有 C ,是因为 C 的比较标准都不一样,如果把 C 放进来,按 C fans
> 的标准,简单最好。C 最简单, C 满分,其他所有语言 0 分,耶~
>
> 我想要比较的话,应该比较一个通用跨平台的标准的语言。而我对 Windows 以
> 外的平台的 .net 不了解,所以没有把 .net 加进来,其实 .net 如果放进来,
> 估计跟 Java 分值差不多,细节可能 .net 有赢的地方,但赢不了很多。
>

Windows 以外的平台的 .net ? 指 mono ?
估计和以前 com for unix 的命运差不多, 微软可以拿来宣称我的技术没有绑定
OS, 但是实际用起来, 一方面是追不上规范变化, 另一方面, 大问题不多, 小问题
不断, 没有办法真正用起来.


Atry

unread,
Sep 22, 2007, 4:56:40 AM9/22/07
to pon...@googlegroups.com
之所以只包括了 STL 和 Boost ,是因为 C++ 的编程实在有太多的流派,而且互相之间的基础都是不同的。大多数人都只会在 C++ 的某一种流派下编程,除非他希望同时看到有 10 种字符串和 10 种不同的容器。

在07-9-22,red...@gmail.com <red...@gmail.com> 写道:

Atry

unread,
Sep 22, 2007, 5:02:00 AM9/22/07
to pon...@googlegroups.com
如果用 Boost.Asio 在 Linux 是达到 apache 级别,那是一点也不奇怪的。 apache 在 Linux 本来就很快,利用操作系统的特性也利用得比较充分。
再说,对于最高效的服务器来说,网络连接往往并不是瓶颈。

在07-9-22, red...@gmail.com <red...@gmail.com> 写道:

Atry

unread,
Sep 22, 2007, 5:10:21 AM9/22/07
to pon...@googlegroups.com
GUI C++ 输分是肯定的,即使不限制是 STL + Boost 范围,有 qt , 有 wxWindows ,但用这些跨平台的库能写出什么程序 GUI 比较牛的?更不要说 qt 和 wxWindows 都是自己搞一套跟 STL 不兼容的基础库。相比之下,从 Java 移植过来的 DWT 更有可能做对。

在07-9-22, red...@gmail.com <red...@gmail.com> 写道:

red...@gmail.com

unread,
Sep 22, 2007, 5:11:32 AM9/22/07
to pon...@googlegroups.com
Atry 写道:

> 如果用 Boost.Asio 在 Linux 是达到 apache 级别,那是一点也不奇怪的。
> apache 在 Linux 本来就很快,利用操作系统的特性也利用得比较充分。
> 再说,对于最高效的服务器来说,网络连接往往并不是瓶颈。
>
我说 asio 大概能达到 apache 的速度, 并不是表扬 asio.

实际上, apache 在目前的先进 web server 中, 速度是最慢的了, iis 超过了它
有一段时间了, zeus, lightspeed, lighttpd, nginx 哪个都是比它快好大一截.

Huafeng Mo

unread,
Sep 22, 2007, 5:16:28 AM9/22/07
to pon...@googlegroups.com
GUI并非Java的绝对强项。我找到过一遍文章,里面技术性地比较了Qt和Java/Swing。它的主要结论是:
We have compared the two development platforms Java/AWT/Swing and C++/Qt
regarding their suitability for efficiently developing high-performance, userfriendly
applications with graphical user interfaces. While the Java-based platform
only manages to achieve comparable programmer efficiency to that of the C++/Qt
platform it is clearly inferior when it comes to runtime and memory efficiency.
C++ also benefits from better tools than those available for Java.
对于大型的"中层"系统,比如数据库服务器、应用服务器、数据处理(数据仓库等)等等,通常都有复杂的结构和庞大的规模,同时对性能要求非常高。这些方面都是Java的"缺门",抽象能力和性能。
C++0x可以单列出来,作为参考,同C++98一起比较。
不管怎么样,gp是很重要的特性。不比较这方面,Java的数据肯定很"好看"。这对D和C++都不公平,不然D引入木板干什么?

Atry

unread,
Sep 22, 2007, 5:23:31 AM9/22/07
to pon...@googlegroups.com
可是我不知道什么是 GP ,就好像我也不知道什么是 OO 一样。

在07-9-22,Huafeng Mo <longsh...@gmail.com> 写道:
GUI并非Java的绝对强项。我找到过一遍文章,里面技术性地比较了Qt和Java/Swing。它的主要结论是:

Huafeng Mo

unread,
Sep 22, 2007, 5:28:48 AM9/22/07
to pon...@googlegroups.com
嗯,这比较难办。容我想想。

red...@gmail.com

unread,
Sep 22, 2007, 5:40:30 AM9/22/07
to pon...@googlegroups.com
这问题确实很难.

我只是知道, C++ 里面如果没有了继承, 我会不高兴; 如果没有了 template, 我
会更加不高兴.

Atry 写道:

Huafeng Mo

unread,
Sep 22, 2007, 5:52:51 AM9/22/07
to pon...@googlegroups.com
或许可以这样笼统地说:能够实现stl的语言,便具备了基本的GP能力。D不畏艰难地引入模板和模板特化,便是为了这种能力。

Jian Wang

unread,
Sep 22, 2007, 6:29:55 AM9/22/07
to pon...@googlegroups.com
GUI按照实际使用情况来看,应该是c++远高于JAVA。JAVA除了eclipse外也没什么像样的GUI程序了。而Eclipse之所以显得特别强,关键还在于JAVA的metadata强。这个和GUI没什么关系。

GUI的重点在图形图像处理,CAD/CAM,Office,以及游戏。基本上都是C++的天下。

在07-9-22, Huafeng Mo <longsh...@gmail.com> 写道:
GUI并非Java的绝对强项。我找到过一遍文章,里面技术性地比较了Qt和Java/Swing。它的主要结论是:

yq chen

unread,
Sep 22, 2007, 6:56:30 AM9/22/07
to pon...@googlegroups.com
java中是有GUI,但是AWT和SWING也敢叫GUI?笑死人了。SWT是好,但是总被sun打压,只不过用的人多了,成了事实上的标准,就像MFC、QT等等,不能算是语言级别的。这一点上由于C/C++社区的GUI库百花齐放而且性能明显超出一大截而获胜。

在07-9-22,Jian Wang <oxygen.j...@gmail.com> 写道:
在07-9-22,red...@gmail.com < red...@gmail.com> 写道:
Java根本不可能有同D比肩的能力。之所以分数相近,因为语言的抽象能力被弱化了。如果这样的话,D不可能有什么生存的可能性。因为Java和它的差距这么小,却比Java复杂得多,难学得多,Java不就一统天下了吗?

Atry

unread,
Sep 22, 2007, 7:11:46 AM9/22/07
to pon...@googlegroups.com
Swing 怎么了??Swing 很好用啊。

在07-9-22,yq chen <mephist...@gmail.com> 写道:

pongba

unread,
Sep 22, 2007, 7:25:29 AM9/22/07
to pon...@googlegroups.com
其实C++的GUI一直都是一个隐痛。前一阵子还跟孟岩聊到这个问题的。

在各个GUI库发展起来的时候,C++里面一直都没有一个event/handler设施,结果导致不同的GUI库使用不同的机制,每种都是一个workaround而不是直接的solution。由于这个是GUI库的核心机制,所以这个缺陷很大程度上影响了C++ GUI库的易用性。

后来boost.function/boost.signal出现了,不过这已经是近几年的事情了,MFC/wxWindows/Qt已经在市场上走得很远了,遗留代码也有不知道多少行了,所以更改这么底层的机制又不可能了,向后兼容永远是进化的绊脚石。非常可惜的。
--
刘未鹏(pongba)|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

yq chen

unread,
Sep 22, 2007, 7:33:56 AM9/22/07
to pon...@googlegroups.com
好用归好用,而且是官方的GUI,本该没得话讲。但我觉得很丑,在Windows上不想Windows的程序,到了linux不象linux的程序,看起来不舒服。

在07-9-22,Atry <pop....@gmail.com> 写道:

Huafeng Mo

unread,
Sep 22, 2007, 7:49:20 AM9/22/07
to pon...@googlegroups.com
我用过很长时间的mfc,感觉就像...,怎么说呢,没穿衣服在街上走。:-)
就是说,用mfc的时候,就像在用win32api,当时还觉得很牛(win32api都无比熟悉,真牛)。现在看看,有点反胃。
看着C++库的历史,感觉就是C++还是在少儿时代。尽管前后经历了30多年,真正发挥C++优势的用法,直到近五年才为人们所认识,而且还不是大部分人。换句话说,C++的发展实际上过于超前,远远超出了当时人们的理解能力(我的一个同事说的好:gp?现在大部分人连oop还没搞清楚呢!)。当人们醒悟过来之后,很多历史遗留问题已经形成,C++的应用也受到很大的限制。
这让我想起了电视里看到的一个故事:一个财主要搬家到山上去,他雇了些脚夫搬东西。到了中午,吃完饭,那些脚夫不管财主怎么催,死也不肯走。好容易,下午2点多才开始继续搬。到了目的地,财主问脚夫,为什么不走。脚夫说:那时候我们的魂还在后面呢?:-)

yq chen

unread,
Sep 22, 2007, 7:52:40 AM9/22/07
to pon...@googlegroups.com
失之东隅收之桑榆,未为晚已。我认为与其要兼容已有的GUI库,不如自己搞一套全新的东东,责令编译器厂商去实现。只要好用,用户是会接受的。
 
而对于编译器厂商(比如微软)来说,实现这个GUI易如反掌,它们都有现成的东西,只是做适当的封装、适配。不考虑商业因素再加上各厂商的竞争,他们会很乐意去做。
 
我觉得新的GUI,不能向MFC、QT和wxWidget看齐,而是要向HTML、CSS看齐,采用类似的API。个人认为HTML和CSS是非常好的GUI库,微软的WPF就在象这个方向靠拢,Mozilla也是采用这个做他们的东东的。
 
作为本地应用程序,我希望C++的标准GUI库(如果有的话)能够展现native的外观,而作为Web应用程序,它们能作为服务器控件自动生成HTML标签、CSS渲染和javascript逻辑,并且将事件处理代码生成相应的服务器逻辑。
 
有这个效果,不相信程序员不会使用。


 
在07-9-22,pongba <pon...@gmail.com> 写道:

oldrev

unread,
Sep 22, 2007, 8:19:08 AM9/22/07
to pon...@googlegroups.com

又来了.....

oldrev <oldrev(at)gmail(dot)com>
Regards

>>> 引用的文字:
On Saturday 22 September 2007 15:28:13 Atry wrote:
> D 2.0 / Tango + MangoC++ 98 / STL + BoostJava 6.0 IDE较差Windows 平台尚可,Linux
> 平台无好用的 IDE极好 编译速度快慢快 函数式编程支持匿名函数STL 有许多基于函数对象的算法,但语言自身不支持匿名函数,而
> Boost.Lambda不很方便。
> 支持匿名类 模板元编程有完善的支持语言本身有支持,但缺少高级语法。用 Boost.MPL 能做到需要的功能,但晦涩冗长。有泛型,但根本没有真正的模板
> 性能极好极好HotSpot


> 可以运行时编译,本身生成的机器码运行很快。但缺乏底层直接操作内存的能力。没有办法在栈上构造对象,频繁的动态内存分配可能有损性能。用 JNI
> 调用本地代码也会带来额外的开销。

> 垃圾收集有无有 单元测试
> 语言内置,极其易于使用有一些单元测试框架,但使用不够方便。编译速度慢也使得单元测试更难使用。有 JUnit 、 TestNG ,和 IDE
> 配合的比较好 容器有有,但没有广泛可用的哈希表的标准实现。有 XML有无有 文本解析语言内置正则表达式Boost.Xpressive 和
> Boost.Spirit,极其强大的解析框架
> 有正则表达式库 线程和并发有线程、锁和协程(在 Tango 以 Windows 的方式叫作 Fiber),没有线程池和基于消息的定时器


> 有线程和锁。协程库(Boost.Coroutine)尚未加入 Boost ,而且已经停止开发。线程池和基于消息的定时器可以用Boost.Asio 做到

> 有线程、锁、线程池和基于消息的定时器,没有协程 同步 IO 流有有有 异步网络 IO有基于 select / epoll 的实现,仅仅只是 C API
> 的简单包装,使用不很方便。在 Windows 下用的是最糟糕的 select ,非常受限;在 BSD 没有用 kqueue有极好的网络库
> Boost.Asio有 nio ,在 Windows 用的是 WSAEventSelect,而没能发挥完成端口的威力
>
>

red...@gmail.com

unread,
Sep 22, 2007, 8:29:44 AM9/22/07
to pon...@googlegroups.com
yq chen 写道:

> 失之东隅收之桑榆,未为晚已。我认为与其要兼容已有的GUI库,不如自己搞一


> 套全新的东东,责令编译器厂商去实现。只要好用,用户是会接受的。
> 而对于编译器厂商(比如微软)来说,实现这个GUI易如反掌,它们都有现成的
> 东西,只是做适当的封装、适配。不考虑商业因素再加上各厂商的竞争,他们会
> 很乐意去做。

这个在 GUI 这个领域, 已经不存在这个可能性了, C++ 在这个领域对厂家没有足
够的号召力, MS 这个大玩家又主推自己的 .net 平台, 他推 C# 的干劲比
C++/CLI 大, 推 C++的干劲应该就很小了.

现在 GUI 的几个大平台, 如果不算 Java, 只算 Native 的, 应该是 Windows,
Mac, GNome, KDE, 比起早十多年, 其实平台的数目应该算是减少了, 但是要推
C++ 统一编程平台的难度, 只怕还更大了.

Atry

unread,
Sep 22, 2007, 8:45:56 AM9/22/07
to pon...@googlegroups.com
我觉得 GUI 这个东西,想要跨平台的话,基于 OpenGL 自己画恐怕比包装各种不同的平台还要容易些。 

在07-9-22,red...@gmail.com < red...@gmail.com> 写道:

Atry

unread,
Sep 22, 2007, 8:46:19 AM9/22/07
to pon...@googlegroups.com
就比如 Swing

在07-9-22,Atry <pop....@gmail.com> 写道:

redsea

unread,
Sep 22, 2007, 10:53:11 AM9/22/07
to TopLanguage
Java, C# 可以认为是从 C++ 的 OO 部分简化优化加上大型完善的类库发展起来的, 可以认为都取得了成功, 占有了不小的市场.

D 则试图将 C++ 的 GP 部分也包含进来, 然后简化优化而来, 但没有大厂商支持, (因此可见的时间内, 难有大型类库), 不知道能够
走得怎么样.

Huafeng Mo

unread,
Sep 22, 2007, 7:00:54 PM9/22/07
to pon...@googlegroups.com
D的这条路我觉得有些策略问题。首先它定位不明确,如果说是系统编程,那么还要区分底层的系统编程(os核心、驱动程序等等),还是中间层的系统编程(数据库服务器、应用服务器等等)。对于底层,oop和gp都很难让人接受,明确的业务、相对直白的数据处理,和苛刻的运行时要求,也无需oop和gp来搅局。很多底层开发人员是不买帐的。
这样,只有中层系统编程,和C++一样。但是,这就使D同C++处于竞争关系。但是,D策略的另一个重要问题,可能使D处于不利的地位。D的宣传和推广,几乎都是以抨击C/C++开始的,这就使它站在了C/C++的对立面上。尽管说的基本上都是事实,但如此激烈的言辞,很容易造成反作用(你从C/C++那里学去了那么多东西,人家幸苦开拓,你坐享其成,还要忘恩负义!)。而同时在易用性方面的宣传,很容易引起Java的敌对(Java对什么都有些敌对。其实Java的宣传让我反感,D倒没有)。这样,D成了四处树敌的"坏小子"。
倒是Bjarne很聪明,利用兼容C来安抚C程序员,然后利用人们的喜新心理,一点一点地推广自己的语言。

杨新鑫

unread,
Sep 22, 2007, 9:41:30 PM9/22/07
to pon...@googlegroups.com
C++ 0x会不会引入Module?引入后是不是解决了编译慢等问题?但与C的兼容怎么办?

red...@gmail.com

unread,
Sep 22, 2007, 9:53:23 PM9/22/07
to pon...@googlegroups.com
Huafeng Mo 写道:
> D的这条路我觉得有些策略问题。首先它定位不明确,如果说是系统编程,那么

> 还要区分底层的系统编程(os核心、驱动程序等等),还是中间层的系统编程
> (数据库服务器、应用服务器等等)。对于底层,oop和gp都很难让人接受,明
> 确的业务、相对直白的数据处理,和苛刻的运行时要求,也无需oop和gp来搅
> 局。很多底层开发人员是不买帐的。
底层开发, OOP 可能较多的人不买账, 但是 GP 如果注意一点, 不要造成模板膨
胀, 还是不错的. 反而 exception(时空) 和 rtti(空间) 在这个级别的开销不可小视.


> 这样,只有中层系统编程,和C++一样。但是,这就使D同C++处于竞争关系。但
> 是,D策略的另一个重要问题,可能使D处于不利的地位。D的宣传和推广,几乎
> 都是以抨击C/C++开始的,这就使它站在了C/C++的对立面上。尽管说的基本上都
> 是事实,但如此激烈的言辞,很容易造成反作用(你从C/C++那里学去了那么多
> 东西,人家幸苦开拓,你坐享其成,还要忘恩负义!)。而同时在易用性方面

D 的早期市场, 或许就是针对很多对C++ 了解较深, 但是不太满意的人呢 ?

营销领域里面有说, 大众总是保守的, 新东西一出来的时候, 目标不会是大众, 而
是针对 "技术狂热者"(只要求技术有意思), "梦想者"(易于理性接受新技术, 希望
新技术能够带来新机会或者降低成本的人).

> 的宣传,很容易引起Java的敌对(Java对什么都有些敌对。其实Java的宣传让我

oldrev

unread,
Sep 22, 2007, 10:04:37 PM9/22/07
to pon...@googlegroups.com

想想 Bill Gates 关于 640k 的名言,软件的设计不要太考虑性能,而要着眼未来。MS Research 不是已经用 C#开发了一个实验OS了么,
虽然与硬件直接交互的地方使用了 C++ 和 asm,但是主要的地方都是 C# 写的,据说性能还不错。


oldrev <oldrev(at)gmail(dot)com>
Regards

>>> 引用的文字:

杨新鑫

unread,
Sep 22, 2007, 10:18:20 PM9/22/07
to pon...@googlegroups.com
性能不错吗?我怎么记得好像是失败了呢...

在07-9-23,oldrev <old...@gmail.com> 写道:

pongba

unread,
Sep 23, 2007, 12:52:07 AM9/23/07
to pon...@googlegroups.com
C++09不会,赶不及了。但随后的TR会引入。201x年吧。

On 9/23/07, 杨新鑫 <sean...@gmail.com> wrote:
C++ 0x会不会引入Module?引入后是不是解决了编译慢等问题?但与C的兼容怎么办?


Huafeng Mo

unread,
Sep 23, 2007, 4:11:46 AM9/23/07
to pon...@googlegroups.com
我草草看了一下module的提案,(瞧我这英语水平,嗨,谁让我60分整过的四级呢。后悔啊:-()。
渴望的感觉油然而生。:-)
初步看来,module至少解决了三大问题:
1、恶心的.h文件。
2、提高编译速度。
3、实现统一的ABI。
最后这一点极端重要,只有统一了ABI,才能彻底解决C++的编译器移植问题。而且,也促使C++可以同其他语言更好的交互和协作。未来不会再有一种语言独大了。未来是协作的世界,只有通力协作,高低搭配才能各展其长。goole的C++/Python组合就很成功。

red...@gmail.com

unread,
Sep 23, 2007, 4:15:33 AM9/23/07
to pon...@googlegroups.com
那到时 C++ 是否还支持 #ifdef 和 #define ?

只要 C++ 还支持 #ifdef, #define, 那么 module 里面就不能保存语法分析之后
的结果, 只能保存词法编译之后的结果, 这样, 编译速度就不可能提高多少.

Huafeng Mo 写道:
> 我草草看了一下module的提案,(瞧我这英语水平,嗨,谁让我60分整过的四级

Huafeng Mo

unread,
Sep 23, 2007, 4:15:36 AM9/23/07
to pon...@googlegroups.com
底层开发, OOP 可能较多的人不买账, 但是 GP 如果注意一点, 不要造成模板膨
胀, 还是不错的. 反而 exception(时空) 和 rtti(空间) 在这个级别的开销不可小视.
====================
不知道底层的人是否会接受gp。现在很多人对与gp的认识就像中世纪欧洲人对太阳系的认识一样。
==================

营销领域里面有说, 大众总是保守的, 新东西一出来的时候, 目标不会是大众, 而
是针对 "技术狂热者"(只要求技术有意思), "梦想者"(易于理性接受新技术, 希望
新技术能够带来新机会或者降低成本的人).
=================================
说的也是,希望业界早些开窍。

Huafeng Mo

unread,
Sep 23, 2007, 4:17:20 AM9/23/07
to pon...@googlegroups.com
痛恨我的英语水平,实在看得太囫囵了。哪位知道来说说吧。

On 9/23/07, red...@gmail.com <red...@gmail.com > wrote:

杨新鑫

unread,
Sep 23, 2007, 8:25:31 AM9/23/07
to pon...@googlegroups.com
pongba改天不写篇介绍一下?虽然得等到201x了...

在07-9-23,Huafeng Mo <longsh...@gmail.com> 写道:

yq chen

unread,
Sep 23, 2007, 9:00:27 AM9/23/07
to pon...@googlegroups.com
标准委员会到底十月份能不能把0x的草案搞定啊,马上不是就到十月了吗?难道要跳票?

在07-9-23,杨新鑫 <sean...@gmail.com> 写道:

Huafeng Mo

unread,
Sep 23, 2007, 8:16:54 PM9/23/07
to pon...@googlegroups.com
这个文档包含了两个候选的时间表,打算在kona讨论:http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2417.pdf
大概可以了解一下他们的计划

杨新鑫

unread,
Sep 23, 2007, 11:01:21 PM9/23/07
to pon...@googlegroups.com
我在教育网,没法下C++的paper,有的介绍下或给我发一个。。

在07-9-24,Huafeng Mo <longsh...@gmail.com> 写道:
Reply all
Reply to author
Forward
0 new messages