为何 D 语言要无缘无故的用上新语法和新关键字

[Atry]

今天在看 D 语言，感觉很兴奋。很多 C++ 很不爽的地方 D 语言都解决了。

但我就是不明白为什么 D 语言无缘无故要用一些新语法和新关键字。本来模板的 <> 已经用习惯了，他非要用 !()。还有类型转换我觉得 cast() 的语法也是一种倒退，哪里有 reinterpret_cast<> 看起来清晰？还有基本类型，wchar_t 改成 wchar，新增 byte 的类型，这两点我都觉得很好，可是原本用得好好的 unsigned int ， unsigned long ，他为什么一定要跟 C# 学，用 uint ulong 这样的关键字？

不过总的来说感觉 D 语言会很有前途， boost 里面大半的库用了大量的奇技淫巧来解决的问题，他用语言本身解决了。还有 C++ 大量的混乱的地方，他都解决了。比如说 C++ 的 private 和 public 根本是个摆设。还是只能用 C 的办法，用头文件来暴露接口，区分出实现。但是 D 的 private 和 public 的语义就不一样。语言规范就规定 private 在同一个模块内部无效。嘿嘿，其实这个 private 更类似于 C 的 static 关键字。

[Atry]

D 语言虽然语法和 C 不兼容，但是二进制兼容 C ，这就使得任何 C 库只要改造头文件就可以直接在 D 里面使用。所以应该说任何可以用 C 的项目，用 D 来实现在这方面额外的代价都不大。

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

[Atry]

D 的定位是"更好的 C++ "，我想，大部分对 C++ 又爱又恨的人看到 D 都会欣喜若狂吧。

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

[Atry]

我现在的心情就是欣喜若狂 ;-)

[oldrev]

Welcome to the light side!

在 2007-09-15六的 19:08 +0800，Atry写道：

[lijie]

关键字是多了些，这些完全可以用alias或typedef来做，不过提供了也没什么不对的，为什么不能跟C#学而一定要学C++？

至于cast，D本来就只有static_cast和dynamic_cast，并没有const_cast和reinterpret_cast的功能，前面2种又很容易区分，所以没必要写成2个关键字。

二进制兼容方面，我测试过一些库都可以很好地工作，只有一些小细节上会让我觉得C库的一些缺不爽，主要0结尾的字符串，这种是会带来效率损失的地方，特别是做一些协议解析比如HTTP，总要把字符串复制一下添个\0上去，还不说取一下字符串长度就要扫描整个串。D这种方式就很好，很多地方都不需要拷贝字符串，因为数组就是由一个长度和一个指针组成的，它的slice操作也是非常高效的。现有的大部分C库都接受\0结尾的字符串，有些库做得好一些，把指针和长度分开传递，用D调用起来就非常舒服了。

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

[red...@gmail.com]

其他我不知道, 模板语法改动如下.

cast 的改变我不清楚, 但是现有的 cast 的语义和C++ 的几个cast 未必很对应. const 的处理, D2.0 还在热烈争论中, 加上 invariant 的处理, const_cast 肯定不会和原来一样了.

D 的早期社区里面一大堆人都是原来 C++ 用得很好的人, 很多东西他们应该也不是随便决定的.

BTW:
1. unsigned int 这个玩意, 用 C++ 的年代我觉得已经觉得敲得太烦, 会typedef 成 uint
2. 用 C++ 的时候, 我基本上会用 int32 uint64 之类的名称, 不用int 和 long long 之类的, D将整数类型改成固定长度也正合我意.

Argument Syntax

The first thing that comes to mind is the use of < > to enclose parameter lists and argument lists. < > has a couple serious problem, however. They are ambiguous with operators <, >, and >>. This means that expressions like:

a<b,c>d;

and:

a<b<c>>d;

are syntactically ambiguous, both to the compiler and the programmer. If you run across a<b,c>d; in unfamiliar code, you've got to slog through an arbitrarily large amount of declarations and .h files to figure out if it is a template or not. How much effort has been expended by programmers, compiler writers, and language standard writers to deal with this?

There's got to be a better way. D solves it by noticing that ! is not used as a binary operator, so replacing:

a<b,c>

with:

a!(b,c)

is syntactically unambiguous. This makes it easy to parse, easy to generate reasonable error messages for, and makes it easy for someone inspecting the code to determine that yes, a must be a template.

Atry 写道:

[Atry]

>> 的问题其实很容易避免，加一个空格就可以了。对程序员的额外开销也不大。但是看程序的时候，<> 的确要比满屏幕的()看得清楚。这里有谁看 LISP 不晕的。
其实归根到底，还是因为ascii里面的括号种类太少了，<>又是大于号又是括号，还是中文编程爽，Unicode 里面括号种类多了去了，可以用《》、˂˃、ˋˊ、˂˃、ˋˊ、˓˒、ʿʾ、<<>>、""、''、‴‷。

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

[pongba]

哈哈，中文编程爽 ;-)
我也认为用!是利大于弊。那个argument有点小题大做了。

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

[pongba]

说错了，是弊大于利。

[oldrev]

实际上需要显式实例化模板的时候很少，大部分都能自动推导，因此不用担心代码
里很多的 !()

在 2007-09-15六的 20:00 +0800，Atry写道：
> >> 的问题其实很容易避免，加一个空格就可以了。对程序员的额外开销也不

> > 但我就是不明白为什么 D 语言无缘无故要用一些新语法和新关键
> > 字。本来模板的 <> 已经用习惯了，他非要用 !()。还有类型转换我
> > 觉得 cast() 的语法也是一种倒退，哪里有 reinterpret_cast<> 看

> > 起来清晰？还有基本类型，wchar_t 改成 wchar，新增 byte 的类
> > 型，这两点我都觉得很好，可是原本用得好好的 unsigned int ，

> > unsigned long ，他为什么一定要跟 C# 学，用 uint ulong 这样的

> > 关键字？
> >
> > 不过总的来说感觉 D 语言会很有前途， boost 里面大半的库用了大
> > 量的奇技淫巧来解决的问题，他用语言本身解决了。还有 C++ 大量

> > 的混乱的地方，他都解决了。比如说 C++ 的 private 和 public 根

> > 本是个摆设。还是只能用 C 的办法，用头文件来暴露接口，区分出

[Atry]

还有一个区别就是虚函数， D 和 Java 一样，所有的函数都是虚函数。就是不知道这样对于内联优化会不会有负面影响。

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

[oldrev]

看文档不仔细，

This may sound inefficient, but since the D compiler knows all of the
class hierarchy when generating code, all functions that are not
overridden can be optimized to be non-virtual.

virtual 还是 non-virtual 是由编译器决定的，而不是所有函数都是 virtual

在 2007-09-15六的 20:15 +0800，Atry写道：

> 还有一个区别就是虚函数， D 和 Java 一样，所有的函数都是虚函数。就是不
> 知道这样对于内联优化会不会有负面影响。
>
> 在07-9-15，Atry <pop....@gmail.com> 写道：
> 今天在看 D 语言，感觉很兴奋。很多 C++ 很不爽的地方 D 语言都解
> 决了。
>
> 但我就是不明白为什么 D 语言无缘无故要用一些新语法和新关键字。
> 本来模板的 <> 已经用习惯了，他非要用 !()。还有类型转换我觉得
> cast() 的语法也是一种倒退，哪里有 reinterpret_cast<> 看起来清
> 晰？还有基本类型，wchar_t 改成 wchar，新增 byte 的类型，这两点
> 我都觉得很好，可是原本用得好好的 unsigned int ， unsigned
> long ，他为什么一定要跟 C# 学，用 uint ulong 这样的关键字？
>

> 不过总的来说感觉 D 语言会很有前途， boost 里面大半的库用了大量
> 的奇技淫巧来解决的问题，他用语言本身解决了。还有 C++ 大量的混

[Atry]

还有就是我感慨啊，虽然 D 拥有了这么多高级语言的特性，但仍然直接和内存打交道。当然，最重要的高级特性还是垃圾收集。等到 C++ 0x 加入垃圾收集以后，D 和 C++ 就会非常相似。当然， D 的优势就是简单，语法还是要比 C++ 简单一点。到那时， D 和 C++ 的关系就会类似现在的 Java 和 C# 了。嘿嘿。

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

[Atry]

我猜 D 应该不允许像 C++ 那样重载虚私有成员函数吧。如果那样的话，编译器倒是可以很容易判断私有函数是不是 non-virtual 的。C++ 允许重载虚私有成员函数让人很寒，虽然几乎没人把在 C++ 中把一个私有函数弄成虚函数的。

在07-9-15，oldrev < old...@gmail.com> 写道：

[Atry]

D 的文档也很有气势，开篇就是对 C 和 C++ 的批判，把我心中之痒一条一条的挑出来批判，先说 C 或者 C++ 是怎么样，然后把 D 的解决方案拿出来，震得我全身发抖。

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

[red...@gmail.com]

D文档里面都有说, private 函数同时也是 final 的, 这样就不必要是虚的了. 同
时也意味着不能重载 private 函数.
Atry 写道:

[red...@gmail.com]

但是有一点是 C++ 拍马也赶不上的: 编译速度, 对我来说, 优点巨大.

我以前写过一个C++ 程序, 用了 ACE, 我自己写的代码量并不大, 在P4 1.6G, 1G
ram 的机器上, 需要编译 5 分钟以上才能编译出来, 调试的时候, 即使发现了错
误, 都不想停下来修改重新编译, 想一次性多找一些错误出来.

我的一个朋友的游戏开发公司里面, 他们的游戏客户端, 2.4G 的机器上, rebuild
要近半个小时, 加上.h 组织得不理想, .h 文件的耦合度很高, 很多地方的改动都
会造成整体需要编译, 那个麻烦啊. 你做做这个项目, 就会知道, 偷偷在自己的
.cpp 里面加一个 extern 函数和变量声明这么恶心的事情, 为什么会有人去做了.
也可以让人理解, 为什么 com 这么讨厌的技术, 也有人用于单个程序内部的开发了.

用D的话好啊, 我的 P3 800 的机器里面, 开64M 内存的 vmware 编译我的服务器
程序, 也就几秒钟, 在另外一台2.5G 的机器的vmware 里面, 那就是立刻出结果.
所以现在没有 D IDE, 我用 unittest + log 来调试程序, 也没有觉得什么不好
的, 反而比原来效率还高了.

这个编译速度还不需要去 "精心" 组织 .h 的 ifdef 和 include.

Atry 写道:
> 还有就是我感慨啊，虽然 D 拥有了这么多高级语言的特性，但仍然直接和内存

[longshanksmo]

D的gc是强制的？还是可选的？

On Sep 15, 8:21 pm, Atry <pop.a...@gmail.com> wrote:
> 还有就是我感慨啊，虽然 D 拥有了这么多高级语言的特性，但仍然直接和内存打交道。当然，最重要的高级特性还是垃圾收集。等到 C++ 0x
> 加入垃圾收集以后，D 和 C++ 就会非常相似。当然， D 的优势就是简单，语法还是要比 C++ 简单一点。到那时， D 和 C++
> 的关系就会类似现在的 Java 和 C# 了。嘿嘿。
>

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

[red...@gmail.com]

弊大于利 ? 我并不觉得. 留下一个陷阱在这里算什么事呢 ?

D 语言并不是仅仅是完善 C++, 为了C++ 程序员的习惯, 连陷阱都留下.

其他语言的优点他也会吸收, 例如方便的 slice, 是学 python, synchronized 学 java, 据说还学习了 ruby 的一些, 这个我就不知道了, closesure 学了谁 ? foreach 是vb 最早用?  算学vb 吧. tango 的text format, 还学习了 C# 的format, 等等. 

作为一个后出来的语言, 没有必要只是从某一个语言中学习, 将自己定位成为 xxx 的后裔, 即使有问题的地方也保留, 而是应该采纳众家所长, 有机组合才好.



pongba 写道:

[red...@gmail.com]

1. 所有动态申请的对象, 可以用 delete 强制释放
这样, 你可以象 c++ 一样写程序, 偶尔忘了释放, gc 给你擦屁股

2. gc 你也可以 disable
这样就没有额外开销了, 但是也没有人给你擦屁股了

3. tango 将来 gc 会是在 compile time 选择不同实现的

4. class 可以自行定义 new, delete, 想怎么折腾, 就怎么折腾.

longshanksmo 写道:

[Atry]

怎么说呢，C++如果头文件全都用纯虚函数和 C 风格函数，没有额外依赖项，还是有办法编译很快的。编码规范啊编码规范。

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

[Atry]

不好意思，不是"编译很快"，而是"稍微快一点"，至少勉强编译得动。

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

[Atry]

反正至少，目前我用 D 写程序，我目前还想不出我会用 delete 的理由。如果我需要自己控制生命周期，我就在栈上分配内存了。而既然用了 new ，我就不想 delete 了。

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

[redsea]

在你的 .cpp 里面, 你用不用 STL or boost? 用了就会慢下来几倍十倍, 用不用 ACE 这种框架型的库 (用一个类就会扯进很
多类), 用了速度就会慢十倍百倍.

当然如果都不用这些, 还是编译得动的, 比纯 C 的编译慢个几倍吧, 几 大概是 3 ~~10 的样子.

linux kernel 如果用 C++ 写, 别的不说, 光是这个编译时间, 呵呵, 就算 x10 吧. 我这里编译一个vmware用的
linux kernel, 2.5G 的单core cpu 用 5 分钟编译, 变成要 50 分钟, 那我调整内核参数的实验, 就会让我抓狂
了.

On 9月15日, 下午9时10分, Atry <pop.a...@gmail.com> wrote:
> 不好意思，不是"编译很快"，而是"稍微快一点"，至少勉强编译得动。
>

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

[lijie]

有时候析构函数可能也做了许多工作，及时使用delete也有好处的，可以让GC在执行析构时的时间短一些。这个时间可是要停止所有线程，而delete不会停止线程，这在多CPU上表现可能更为明显。

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

[oldrev]

D 的设计目标之一就是容易解析，这与 C++ 先有语言再实现编译器有本质区别，
所以 D 程序就算是大量使用模板编译速度也很快。

现在已经有高人再用D实现D编译器了：
http://code.google.com/p/dil/

在 2007-09-15六的 21:10 +0800，Atry写道：

[red...@gmail.com]

我觉得 D 的析构应该和 Java 一样, 不能做太多的事情, 如果要做太多的事情,
应该要设计一个函数, 例如叫做 close, 显式调用它.

原因:

1. D 的析构函数不能调用子对象的析构函数, 因为子对象可能已经先析构完了

2. D 的析构函数不能保证被调用 !!!
这个很重要, 为什么呢?
由于目前无论是 phobos, 还是 tango 的gc, 都是保守 gc, 不是精确 gc, 这
样, 有可能有一些已经无法访问的对象, 但不会被释放.
这个的影响真是很大的.
但是如果做一个精确 gc 的话, 每个栈框架都需要知道是哪个函数的栈框架,
每个内存块都需要知道是哪个类型, 每个 class, struct 的成员的类型是什么都
必须记录下来, union 的值, 当前是哪个也必须保存下来. 做 gc 的时候, 首先
查一个内存是什么类型,然后看看这个类型哪几个位置需要进行检查, 这样, 涉及
到大量 rtti 信息的查找, 效率比较成问题.

既然析构函数不能保证被调用, 那么昂贵的资源, 例如数据库链接, 文件句柄之
类的东西, 还是必须即时释放, 但是就不要放到析构函数中了.

Java 类的 finalized 函数也不保证会被调用. .net 似乎可以保证 ?

或许以后有人会实现一个精确 gc, 但是这需要 d 编译器保存所有 rtti 信息,
目前并未如此.

lijie 写道:
> 有时候析构函数可能也做了许多工作，及时使用delete也有好处的，可以让GC在
> 执行析构时的时间短一些。这个时间可是要停止所有线程，而delete不会停止线
> 程，这在多CPU上表现可能更为明显。
>

[redsea]

D 的gc 是保守gc, 可能会有对象不能释放这点可能会让人相当失望 :(
没有办法, 这是一个 trade off.

好在, 也可以回到 c++ 的方案, 取消 gc, 显式 new, delete.

C++ 的 gc 肯定也会面临同样的问题, 保守但是快速, 还是精确, 但是慢速.

[oldrev]

处理非内存资源，我是如下实现的：

1. 定义一个 IDisposable 接口，所有持有非内存资源的类都必须实现此接口。
interface IDisposable
{
void close();
}

2. 约定 close 方法可以多次调用并不会抛出异常。

3. 持有非内存资源的类的 dtor 里应该调用 close() 方法。

客户程序使用 scope(exit) 显式调用 close，如果忘了，系统进行gc的时候会自
动擦屁股的，但是代价比较高，因为非内存资源通常都比较昂贵。

在 2007-09-15六的 21:30 +0800，red...@gmail.com写道：

[red...@gmail.com]

我也是类似这么做, 但是没有用 interface.
interface 是为了什么目的呢 ?

oldrev 写道:

[oldrev]

我感觉用接口的灵活性会更大一些，当然你也可以使用类似：

abstract class Dispose
{
abstract void close();

~this() {
close();
}
}

的鸡肋，更加方便，但是 D 是单继承，这可能会限制了子类。

貌似 .Net 和 Java 都是用接口

在 2007-09-15六的 21:52 +0800，red...@gmail.com写道：

[longshanksmo]

作为定位在系统编程的语言，所有函数都虚化，使用者是否买账？
不是还有很多人抱怨C++性能差么？

On Sep 15, 8:15 pm, Atry <pop.a...@gmail.com> wrote:
> 还有一个区别就是虚函数， D 和 Java 一样，所有的函数都是虚函数。就是不知道这样对于内联优化会不会有负面影响。
>

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

[longshanksmo]

没看到后面的回复。
但是如果让编译器选择是否虚函数，很多人又会觉得编译器背着他们做坏事，毕竟很多人连stl的容器都不放心。

[red...@gmail.com]

D 的做法, 应该是, 缺省可以被 override, 而不是不能控制. 一个函数, 不想是
虚函数, 定义的时候, 写成
写成 final , 就可以了.

longshanksmo 写道:
> 没看到后面的回复。
> 但是如果让编译器选择是否虚函数，很多人又会觉得编译器背着他们做坏事，毕竟很多人连stl的容器都不放心。
>

[longshanksmo]

也就是说把C++的做法颠倒过来了

[Atry]

其实就是和 Java 做法一样，连关键字都一样。

在07-9-16，longshanksmo <m...@seaskysh.com> 写道：

[pongba]

那个编译时间花花的都花在扫描该死的头文件里面了。intel做过一个研究，#include模型带来的不必要编译花销占很大比重的，多少我忘了，该死就是记不住数字。

C++0x的TC1应该会加入module，vandervood正在努力，哈哈。。等待吧。或许2013年之前就有戏了~

http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba

[pongba]

嗯嗯，实际上目前的编码标准提倡的就是把虚函数设成私有的。叫非虚接口模式（NVI）。见C++ Coding Standard或Exceptional C++ Style

--
刘未鹏(pongba)|C++的罗浮宫

[Atry]

那个应该是 protected 的 虚函数吧， C++ 的streambuf里面那种，public non-virtual + protected virtual。
私有虚函数还是太违背直觉了。
另外，我对 C++ 的 streambuf 设计很有意见。简直就是把简单问题复杂化。

在07-9-16， pongba <pon...@gmail.com> 写道：

[oldrev]

一看见 C++ 的 iostream 这些我就想骂，这叫什么玩意？不知道是哪个有自虐倾
向的人设计的，简直是变态！既不直观又不高效。

private virtual C++ 是有的，参考：
http://blog.csdn.net/fatalerror99/archive/2005/11/08/525615.aspx

在 2007-09-16日的 13:46 +0800，Atry写道：

[red...@gmail.com]

Atry 写道:

> 另外，我对 C++ 的 streambuf 设计很有意见。简直就是把简单问题复杂化。

我对 IOStream 整个设计意见都很大, 内部架构过度设计, memstream性能极低,
给最终用户的使用接口麻烦不人性化.
我是不用这个破玩意的, 用 printf 或者需要类型安全, 自定义转换的时候, 用我
自己的 outputbuf 先输出到内存中.

[Jian Wang]

没错没错，曾经做过一个VC6上读取utf-8，utf-16的功能。麻烦的要死，而且性能极差。最后还是废掉了，用C风格的函数一会儿就搞定了。

 

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

[Atry]

delegate 的语法也是学 C# 的， with 应该是学 JavaScript 的。

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

[longshanksmo]

唉，标准委员会的人多半是史前动物，连Bjarne也承认iostream上花的时间太多了，应该去搞gui

On Sep 16, 1:57 pm, oldrev <old...@gmail.com> wrote:
> 一看见 C++ 的 iostream 这些我就想骂，这叫什么玩意？不知道是哪个有自虐倾
> 向的人设计的，简直是变态！既不直观又不高效。
>
> private virtual C++ 是有的，参考：http://blog.csdn.net/fatalerror99/archive/2005/11/08/525615.aspx
>
> 在 2007-09-16日的 13:46 +0800，Atry写道：
>
> > 那个应该是 protected 的 虚函数吧， C++ 的streambuf里面那种，public
> > non-virtual + protected virtual。
> > 私有虚函数还是太违背直觉了。
> > 另外，我对 C++ 的 streambuf 设计很有意见。简直就是把简单问题复杂化。
>
> > 在07-9-16，pongba <pon...@gmail.com> 写道：
> > 嗯嗯，实际上目前的编码标准提倡的就是把虚函数设成私有的。叫非虚
> > 接口模式（NVI）。见C++ Coding Standard或Exceptional C++ Style
>

> > On 9/15/07, Atry <pop.a...@gmail.com> wrote:
> > 我猜 D 应该不允许像 C++ 那样重载虚私有成员函数吧。如果
> > 那样的话，编译器倒是可以很容易判断私有函数是不是
> > non-virtual 的。C++ 允许重载虚私有成员函数让人很寒，虽
> > 然几乎没人把在 C++ 中把一个私有函数弄成虚函数的。
>
> > 在07-9-15，oldrev <old...@gmail.com> 写道：
> > 看文档不仔细，
>
> > This may sound inefficient, but since the D
> > compiler knows all of the
> > class hierarchy when generating code, all
> > functions that are not
> > overridden can be optimized to be non-virtual.
>
> > virtual 还是 non-virtual 是由编译器决定的，而
> > 不是所有函数都是 virtual
>
> > 在 2007-09-15六的 20:15 +0800，Atry写道：
> > > 还有一个区别就是虚函数， D 和 Java 一样，所
> > 有的函数都是虚函数。就是不
> > > 知道这样对于内联优化会不会有负面影响。
>

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

[李一楠]

真难熬啊。我建议把版本控制工具进化为编译服务器，带所有文件的预编译体的数据库的那种，还要尽量全装入内存里...... 

---

网 易 Yeah.net 免 费 邮 箱 全 新 改 版，珍 藏 帐 号 开 放，快 来 抢 注 >>

[red...@gmail.com]

C++ 的预编译帮助不是很大, 因为宏, ifdef 之类的存在, 不能将 .h 直接分析成
语法树保存, 只能保存 lex
分析的结果.

在以前 C++ 编译器比 C 编译器慢得还不是特别多的时候, 节省词法分析时间的收
获还算不不错; 但是 C++ 编
译器更慢之后, 这部分的收获就显得更小了.

李一楠 写道:
> 真难熬啊。我建议把版本控制工具进化为编译服务器，带所有文件的预编译体的
> 数据库的那种，还要尽量全装入内存里......

[SevenCat]

说D语言是一次C＋＋的分裂也可以。