d作者:d中导入C编程

作者:d作者.

用ImportC来伟大的编程

D专门设计为易于对接C
●零成本,●兼容类型,●熟悉语法,●兼容语义
使C代码可从D访问
●只需转换C.h文件为D
●很容易
●时间短
●应不难
但,我们打了个叉叉.

我们可能错误:
●预处理器宏混淆了代码
●#includes可爆炸到10,000行或更多
●需要C和D的能力
●无可靠方法来验证是否正确翻译
●乏味
继续…
●不能写自己的系统.h文件
●可移植性问题
-C长可是D整或D长
-符可有符号或无符号.
-位域
–对齐
●.h文件不断变化

解决方案

●提供了系统C.h文件的子集,仔细翻译成D
●Diemos项目是在其中共享翻译.h文件工作的众包存储库.
–但对专有C代码,这不工作

经验表明

它不够好,是重要障碍
输入.h到.d翻译器
写了三个:
-WalterBright的htod(就是我)
-JacobCarlborg的DStep
-AtilaNeves的dpp
大大改善了,
但是:
●总有个"但是"
●很难安装构建系统
●创建额外文件
●翻译位域等很难
●摩擦

如何最简单,最明显,最完美的从如stdio.h中获取所有声明呢?

导入 stdio;

看到它,就无法忽略它.这就是期望的用户体验.
它必须能工作

如何让它明显发挥作用呢?

整合真实有效的C编译器至D编译器!
之前想过,但这是疯子才会提出的愚蠢想法.
但,也许我们不应该这么着急下结论.C是一种简单语言.我写了个C编译器.大概可在周末拿出一个,对吧?因此

构思出ImportC来了!

(喜剧音乐)

第一个大问题

●预处理器
-预处理器元编程
-D无文本宏类似的
-预处理有很多开关
-无法可靠处理野外的疯狂C宏
●该问题困扰了我们多年

●但有个解决方案摆在面前

放弃预处理器!

●ImportC只处理预处理过文件
●全部放在一个文件中
●C预处理器已按独立程序存在
–不必担心正确性
●D只关心宏
–Dpp表明,可按特殊方式处理
–但现在我们不关心它

下个问题:

需要一个C
●词法分析器
●解析器
●分析语义
●生成代码
D编译器布局:Lexer=>Parser=>Semantic=>Backend
带ImportC:词法=>解析器,C解析器(两路)=>语义=>后端
必须调整词法分析器和语义,但可工作.

规则

●C11是基础
●无隐式声明函数
●无警告
●不检查printf
●不修复C
●最小C扩展
●无编译器开关
–它应"工作"

词法差异

●不同关键字

-Signed,unsigned,register,inline,typedef,
_Static_assert,restrict,volatile,_Alignas,_Alignof,_Atomic
,_Bool,_Complex,_Imaginary,_Noreturn,
_Thread_local

●数字字面
●#pragma

C解析不复杂:

●相同的旧递归下降
●需要任意前看
●不能用符号表来消除解析歧义
-C设计时未分开解析与语义,但我们会!

歧义语法

(A)(B)
转换还是调用函数?不知道A是函数还是类型时,无法确定.
转换构造为特殊AST节点,然后按语义趟重写为转换式或调用函数AST.

一大简化

●C无模块.它只是预处理后,完全独立的一个大文件!
D中不存在一些结构
● ->
● _Generic
● (type-name){initializer-list}
●给它们加新AST节点,并加语义例程并重写为D的AST节点

位域

●解析时,无法确定它们
-所以,给他们造AST节点
-代码生成器,可处理位域
●未文档
●但,效果很好
-考虑加它到D

旧式函数声明

int foo(a,b)
int a;
双 d;
{
    ...
}

非常不同的静态初化器

●给它们加特殊AST节点
-同样解析过程中,无法确定形状
●在语义趟,翻译为D的静态初化器

#pragma pack

●非标准
●未文档
●凑合
●无论如何,必须实现它,太多现有代码用它了.

int
#pragma pack(8)
x
#pragma pack()
;

标签名称空间

struct S{...};
整 S;

用两个并行表消耗太多时间和空间,因此对标签名用单独的哈希表.

优点(增强功能?)

int x=square(2);
int square(int i){
    return i*i;
}

前向引用和编译时执行函数

问题

●无C测试套件
-不太喜欢我的旧C测试套件
●Const,在D语义中是可传递的
-对C语义,很难改类型系统
-T*常 p;在C中,为可变的常指针,在ImportC中是const的const指针,令人惊讶的是,这并未造成D与C接口的麻烦,似乎D语义是人们使用const的自然方式.

其他用途

●作为快速C编译器
●D编译器"试用"C库
●需要点C代码来对接时较方便
●插件及匹配C和D模块时较方便

结论

●更易对接C
●不再翻译.h文件
●不受.h文件变化的影响
●现在可作为测试版使用
参考文献:
文档