下一代完美语言: D语言(300分)

功能是多了
 
刚看了支持的特性,多得一踏糊涂。。。按这形式下去。比C++不知道要复杂多少。。。
 
功能太多了
 
什么是 D 语言?
D 是一种通用的系统和应用编程语言。它是比 C++ 更高级的语言,同时还保持了生成高效代码以及直接访问操作系统API和硬件的能力。D 很适合于编写从中等规模到那些由团队合作完成、数百万行代码规模的各种程序。D 易于学习,为编程者提供了很多便利,并且适用各种野心勃勃的编译器优化技术。
D 不是脚本语言,也不是一种解释型语言。它不需要虚拟机、宗教、或者高于一切的哲学。它是给实际的编程者使用的实际的语言,它帮助编程者快速、可靠的完成易于维护、易于理解的代码。

D 是数十年来实现多种语言编译器的经验的积累,是用那些语言构造大型工程的尝试的积累。D 从那些语言(主要是 C++ )那里获得了灵感,并将 使用经验和现实世界中的实用性来驯服它。

为什么是 D ?
确实,为什么?有谁需要另一种编程语言?
自从 C 语言被发明以来,软件工业走过了一段很长的路。许多新的概念被加入了 C++ 中,但同时维护了同 C 的向后兼容性,包括兼容了原始设计中的所有的弱点。有很多修正这些弱点的尝试,但是兼容性是最大的困扰。同时,C 和 C++ 都在不断引入新的特性。这些新特性必须被小心的加入到现有的结构中,以免重写旧的代码。最终的结果十分复杂—— C 标准将近 500 页,C++ 标准大概有 750 页!C++ 实现起来既困难又代价高昂,造成的结果就是各种实现之间都有差别,因此很难写出完全可以移植的 C++ 代码。

C++ 程序员倾向于使用语言中的孤岛来编程,也就是说,他们倾向于十分精通语言中的某个特性而避免使用其他特性。尽管代码通常在编译器之间是可移植的,但在程序员之间移植就不那么容易了。C++ 的一个长处是它支持很多根本上不同的编程风格——但从长远来看,互相重复和互相冲突的风格会给开发带来妨碍。

C++ 在标准库而不是语言核心中实现了可改变大小的数组和字符串拼接等。不在语言核心中实现这些功能造成了几种不太理想的结果。

是否能把 C++ 的能力释放、重新设计并重铸到一门简单、正交并实用的语言中呢? 这种语言是否能做到易于正确实现,并使编译器有能力有效地生成高度优化的代码呢?

现代编译器技术已经取得了很大的进步,有些原来用作原始编译技术的补充的语言特性已经可以被忽略了(一个这样的例子是 C 语言中的‘register’关键字,一个更为微妙的例子是 C 中的宏预处理程序)。我们可以依赖现代编译器的优化技术而不是使用语言特性(如同原始的编译器所做的那样)来获得可以接受的代码质量。


D的主要目标
通过加入已经被证明的能够提高生产力的特性、调整语言特性以避免常见但耗费精力的bug的出现,至少减少软件开发成本10%。
是代码易于在编译器之间、在机器之间、在操作系统之间移植。
支持多种编程范式,也就是至少支持命令式、结构化、面向对象和范型编程范式。
对于熟悉 C 或者 C++ 的人来说,学习曲线要短。
提供必要的低级访问能力。
要使 D 的编译器从根本上易于实现(相对于 C++ 来说)。
要同本机的 C 语言应用程序二进制接口相兼容。
语法要做到上下文无关。
对编写国际化的应用程序提供便利的支持。
同时支持契约式编程和单元测试方法论。
能够构建轻量级的、独立的程序。
从C/C++保留而来的特征
粗看上去 D 就像 C 和 C++ 。这样一来学习以及将代码移植到 D 就很容易。从 C/C++ 转向 D 应该很自然。程序员不必从头学起。
使用 D 并不意味着程序员会如 Java 或者 Smalltalk 那样被严格的限制在某一个运行时 vm (虚拟机)上。D 没有虚拟机,编译器直接生成可连接的目标文件。D 如同 C 那样被直接连接到操作系统。通常那些你熟悉的工具如 make 同样适用于 D 的开发。

D 将很大程度上保留 C/C++ 的 观感 。它将使用相同的代数语法,绝大多数的相同表达式和语句形式,以及总体的结构。
D 程序既可以采用 C 风格的 函数和数据 范式,也可以采用 C++ 风格的 面向对象 范式,或者它们两者的混合。
编译/链接/调试 的开发模型将会被继承下来,但是把 D 编译成为字节码然后解释执行也不会有任何问题。
异常处理 越来越多的使用经验显示,异常处理是比 C 传统的“出错代码/全局errno变量”模型更为高级的错误处理模型。
运行时类型识别 C++ 部分地实现了这个功能,而 D 更进一步。对运行时类型识别的完全支持将使垃圾收集运行的更好,会使调试器的功能更强,会使对自动持久化的支持更好等等。
D 维持了同 C 调用惯例 的兼容。这样就能够使 D 程序直接访问操作系统的 API 。程序员有关现有 API 和编程范例的知识和经验可以继续在使用 D 时使用而只需付出很少的努力。
运算符重载 D 支持对运算符的重载,这样就可以用用户定义的类型扩展由基本类型构成的类型系统。
模板 模板是实现范型编程的一种手段。其他的手段包括使用宏或者采用协变数据类型。使用宏已经过时了。协变类型很直接,但是低效且缺少类型检查。C++ 模板的问题是它们太复杂,同语言的语法不和谐,还有各种各样的类型转换和重载规则,等等。D 提供了一种简单得多的使用模板的方法。
RAII(资源获得即初始化) RAII 技术是编写可靠软件的重要方法之一。
Down and dirty 编程 D 将保留 down-and-dirty 编程的能力,而不用采用别的语言编写的外部模块。在进行系统编程时,有时需要将一种指针转换成另一种指针,或者使用汇编语言。D 的目标不是避免 down and dirty 编程,而是减少在进行普通程序设计时对它们的需要。
废弃的特征
对 C 的源码级兼容性。保留对 C 的源码级兼容的扩展已经有了(C++ 和 Objective-C)。在这方面的进一步工作受制于大量的遗留代码,已经很难对这些代码进行什么重大的改进了。
对 C++ 的链接兼容性。C++ 的运行时对象模型太复杂了——如果要较好的支持它,基本上就是要求 D 编译器变成一个完整的 C++ 编译器了。
C 预处理程序。宏处理是一种扩展语言的简单方法,它可以给语言加入某些语言本不支持的(对于符号调试器不可见的)特征。条件编译、使用 #include 分层的文本、宏、符号连接等,本质上构成了两种难以区分两种语言的融合体,而不是一种语言。更糟的是(或许是最好的),C 预处理程序是一种十分原始的宏语言。是停下来的时候了,看看预处理程序是用来做什么的,并将这些功能直接设计到语言内部。
多重继承。它是一种拥有饱受争议的价值的复杂特征。它很难用一种高效的方式实现,而且在编译器实现它时很容易出现各种 bug 。几乎所有的 MI 的功能都能够通过使用单根继承加接口和聚集的方式实现。而那些只有 MI 才能支持的功能并不能弥补它带来的副作用。
名字空间。当链接独立开发的代码时,可能会发生名字的冲突,名字空间就是解决这个问题的一种尝试。模块的概念更简单并且工作得更好。
标记名字空间。这是 C 的一个糟糕的特征,结构的标记名称位于一个同其它符号不同的符号表中。C++ 试图合并标记名字空间和正常的名字空间,但同时还要维持对遗留 C 代码的向后兼容性。造成的结果是不可打印。
前向声明。C 编译器在语义上只知道什么东西实在词法上位于当前状态之前的。C++ 进行了一点点扩展,类中的成员可以依赖于它之后声明的类成员。D 更进一步,得到了一个合情合理的结论,前向声明根本就没有存在的必要。函数可以按照一种自然的顺序定义,不用再像 C 那样为了避免前向声明而采用常用的从里到外的顺序定义。
包含文件。造成编译器运行缓慢的原因之一是编译每个编译单元时都需要重新解析数量巨大的头文件。包含文件的工作应该采用导入到符号表中的方式来完成。
在堆栈上创建对象实例。在 D 中,所有的类都通过引用来访问。这样就不需要复制构造函数、赋值运算符、复杂的析构语义以及同异常处理中的堆栈展开的相互作用。内存资源由垃圾收集程序负责释放,其他资源通过使用 D 的 RAII 特征释放。
三字节码和双字节码。Unicode 是未来。
预处理程序。现代语言不应该需要文本处理,它们应该只需要符号处理。
非虚成员函数。在 C++ 中,由累得设计者决定一个函数是否应该是虚函数。在子类中重写一个函数而忘记在父类中将其更新为虚函数是一个常见的(并且非常难以发现的)编码错误。将所有成员函数设置为虚函数,并由编译器来判断函数是否被重写、并由此将没有被重写的函数转换为非虚函数的做法更为可靠。
任意长度的位字段。位字段是一种复杂、低效并且很少用到的特征。
支持16位计算机。D 从不考虑混合使用远/近指针和其它所有用于声称好的16位代码的机制。D 语言的设计假设目标机器至少拥有32位的平坦内存空间。D 将能够被毫无困难的移植到64位架构上。
对编译遍数的互相依赖。在 C++ 中,需要一个符号表和各种的预处理程序命令才能成功的解析一个源文件。这样就使预解析 C++ 源码变得不可能,并且使编写代码分析程序和语法制导的编辑器的过程十分难以正确实现。
编译器的复杂性。通过降低实现的复杂度,这就更有可能出现多个正确的实现。
‘.’和‘->’之间的区别。这种区别其实很没有必要。‘.’运算符完全可以起到‘->’所起的指针解引用的作用。
D 适合于?
经常使用 lint 或者类似的代码分析工具以期在编译之前减少 bug 的程序员。
将编译器的警告级别调到最高的人和那些告诉编译器把警告作为错误的人。
不得不依靠编程风格规范来避免常见的 C bug 的编程部门经理们。
认定 C++ 面向对象编程所允诺的功能由于 C++ 太复杂而不能达到的人。
沉溺于 C++ 强大的表达力但是被显式内存管理和查找指针 bug 折磨得精疲力尽的人。
需要内建的测试和验证机制的项目。
开发百万行规模的程序的团队。
认为语言应当提供足够的特征以避免显式处理指针的程序员。
编写数值运算程序的程序员。D 拥有众多直接支持数值计算的特征,例如直接提供了复数类型和拥有确定行为的 NaN 和无穷大。(这些都被加进了最新的 C99 标准,但是没有加进 C++ 中。)
D 的词法分析程序和解析程序完全互相独立,并且独立于语义分析程序。这意味着易于编写简单的工具来很好地处理 D 源码而不用编写一个完整的编译器。这还意味着源码可以以记号的形式传递个某个需要它的程序。
D 不适合于?
现实一点说,没人会把上百万行的 C 或 C++ 程序用 D 重新写一遍,因为 D 不直接兼容 C/C++ 源代码,D 并不适合于遗留程序。(但是,D 对遗留的 C API 提供了很好的支持。)
非常小的程序——脚本或解释性语言如 Python、DMDScript 或者 Perl 更适合于这种情况。
作为第一门程序设计语言—— Basic 或者 Java 更适合于初学者。对于中级到高级的程序员来说,D 是他们优秀的第二门语言。
语言纯粹主义者。D 是一门实用的语言,它的每个特征都是为这个目的服务的,D 并没有想成为一门“完美”的语言。例如,D 拥有可以基本上避免在日常任务中使用指针的结构和语义。但是 D 仍然支持指针,因为有时我们需要打破这条规则。类似地,D 保留了类型转换,因为有时我们需要重写类型系统。

--------------------------------------------------------------------------------

D 的主要特征
本节列出了一些更有趣的 D 的特征。
面向对象编程

D 的面向对象天性来自于类。采用的继承模型时单根继承加接口。Object 类为与继承体系的最顶端,所以所有的类都实现了一个通用的功能集合。类通过引用的方式实例化,所以不需要用于在异常后进行清理工作的复杂代码。
运算符重载
类可以通过重载现有的运算符扩展类型系统来支持新类型。例如创建一个 bignumber class ,然后重载 +、-、* 和 / 运算符,这样大数类就可以使用普通的代数运算语法了。
生产力
模块
源文件同模块是一一对应的。D 不再“包含”带有声明的文件的文本,而是“导入”该模块。不用担心多次导入一个模块,也不用再把头文件用 #ifndef/#endif 或者 #pragma once 包起来了。
声明 vs 定义
C++ 的函数和类通常需要声明两次——声明位于 .h 头文件中,定义位于 .c 源文件中。这个过程易于出错而且冗长繁琐。显然,应该只需要程序员编写一次,而由编译器提取出声明信息并将它导入到符号表中。这正是 D 所做的。
示例:

class ABC
{
int func() { return 7
}
static int z = 7;
}
int q;

不再需要单独定义成员函数、静态成员、外部声明之类的,也不需要像这样烦人的语法:
int ABC::func() { return 7
}
int ABC::z = 7;
extern int q;

注记:当然,在 C++ 中,琐碎的函数如 { return 7
} 也可以直接写在声明处,但是复杂的函数就不行了(uframer:虽然从语法上说依然是可以的,但会违反 C++ 接口和实现分离的原则。)。另外,如果有前向引用的话,就必须保证已经声明了被引用的那个函数一个原型。下面的代码在 C++ 中是不合法的:
class Foo
{
int foo(Bar *c) { return c->bar
}
};

class Bar
{
public:
int bar() { return 3
}
};

但是等价的 D 代码就可以正常工作:
class Foo
{
int foo(Bar c) { return c.bar
}
}

class Bar
{
int bar() { return 3
}
}

D 函数是否被在线化取决于优化程序的设置。
未完待续...
 
预见高人了,活到老学到老,什么时候是个头阿
 
小弟第一次听说D语言,学习……
 
要是解析方式多好
 
[:D]小学就开始学习E语言了..
 
那Z语言不是最先进的啊
 
大家没事就顶吧
 
我顶!妈的 什么时候 是个头啊!我们这帮人 天天跟着别人的 屁股跑,好累的哦
 
怎么看都像c#
 
怎么看前两句象JAVA啊
 
梦寐以求的语言,有中文社团吗?
 
感觉跟c#没啥两样。
 
一大堆的语言:C/C++、VB、C#、JAVA、PB、DELPHI,又来一个D,我们真的成了电脑民工。
 
我顶~~
是谁开发了这个语言? 开源的? 还是一个国外的公司?
 
任何受语法约束的语言都是注定不可能完美的。看看现在的“动态语言”就知道下一代语
言应该干什么了。


Return To Matrix...
 

Similar threads

D
回复
0
查看
1K
DelphiTeacher的专栏
D
S
回复
0
查看
3K
SUNSTONE的Delphi笔记
S
S
回复
0
查看
2K
SUNSTONE的Delphi笔记
S
I
回复
0
查看
638
import
I
D
回复
0
查看
1K
DelphiTeacher的专栏
D
顶部