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

[Atry]

	D 2.0 / Tango + Mango	C++ 98 / STL + Boost	Java 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]

分值

项目

D 2.0 / Tango + Mango

C++ 98 / STL + Boost

Java 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	容器	6	有	4	有，但没有广泛可用的哈希表的标准实现。	6	有
2	XML	2	有	0	无	2	有
2	文本解析	1	语言内置正则表达式	2	Boost.Xpressive 和 Boost.Spirit ，极其强大的解析框架	1	有正则表达式库
6	线程和并发	2

有线程、锁和协程（在 Tango 以 Windows 的方式叫作 Fiber），没有线程池和基于消息的定时器

4

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

3	有线程、锁、线程池和基于消息的定时器，没有协程
3	同步 IO 流	3	有	3	有	3	有
6	异步网络 IO	1

有基于 select / epoll 的实现，仅仅只是 C API 的简单包装，使用不很方便。在 Windows 下用的是最糟糕的 select ，非常受限；在 BSD 没有用 kqueue

6

有极好的网络库 Boost.Asio

4

有 nio ，在 Windows 用的是 WSAEventSelect，而没能发挥完成端口的威力

100	总分	79		51		78

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

[Huafeng Mo]

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

[Atry]

你的意思是"函数式编程"和"模板元编程"这两个项目的权重还应该加大？或者还得加上一个"语法糖"的比较项目？如果那样的话，D 肯定可以大胜 Java ;-)
我写这个的时候比较偏向于实际功能。Java 太成熟了，功能齐全，所以分会比较高。

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

[red...@gmail.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]

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

[Atry]

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]

好吧，那我这个比较应该限制在应用开发的范围。因为只有这个范围是这三种语言的重叠部分。

[yq chen]

.net赢得多不多是你定的了。如果你把跨平台定为99分，那.net只有一分了。

 

哈哈，开个玩笑。

 

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

[red...@gmail.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]

之所以只包括了 STL 和 Boost ，是因为 C++ 的编程实在有太多的流派，而且互相之间的基础都是不同的。大多数人都只会在 C++ 的某一种流派下编程，除非他希望同时看到有 10 种字符串和 10 种不同的容器。

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

[Atry]

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

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

[Atry]

GUI C++ 输分是肯定的，即使不限制是 STL + Boost 范围，有 qt ， 有 wxWindows ，但用这些跨平台的库能写出什么程序 GUI 比较牛的？更不要说 qt 和 wxWindows 都是自己搞一套跟 STL 不兼容的基础库。相比之下，从 Java 移植过来的 DWT 更有可能做对。

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

[red...@gmail.com]

Atry 写道:

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

我说 asio 大概能达到 apache 的速度, 并不是表扬 asio.

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

[Huafeng Mo]

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]

可是我不知道什么是 GP ，就好像我也不知道什么是 OO 一样。

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

GUI并非Java的绝对强项。我找到过一遍文章，里面技术性地比较了Qt和Java/Swing。它的主要结论是：

[Huafeng Mo]

嗯，这比较难办。容我想想。

[red...@gmail.com]

这问题确实很难.

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

Atry 写道:

[Huafeng Mo]

或许可以这样笼统地说：能够实现stl的语言，便具备了基本的GP能力。D不畏艰难地引入模板和模板特化，便是为了这种能力。

[Jian Wang]

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]

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]

Swing 怎么了?？Swing 很好用啊。

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

[pongba]

其实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]

好用归好用，而且是官方的GUI，本该没得话讲。但我觉得很丑，在Windows上不想Windows的程序，到了linux不象linux的程序，看起来不舒服。

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

[Huafeng Mo]

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

[yq chen]

失之东隅收之桑榆，未为晚已。我认为与其要兼容已有的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]

又来了.....

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]

yq chen 写道:

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

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

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

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

[Atry]

我觉得 GUI 这个东西，想要跨平台的话，基于 OpenGL 自己画恐怕比包装各种不同的平台还要容易些。 

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

[Atry]

就比如 Swing

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

[redsea]

Java, C# 可以认为是从 C++ 的 OO 部分简化优化加上大型完善的类库发展起来的, 可以认为都取得了成功, 占有了不小的市场.

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

[Huafeng Mo]

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程序员，然后利用人们的喜新心理，一点一点地推广自己的语言。

[杨新鑫]

C++ 0x会不会引入Module?引入后是不是解决了编译慢等问题?但与C的兼容怎么办?

[red...@gmail.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的宣传让我