d不同c文件中导入c

原文
理想方法是让每个头文件都有自己的模块.
这几乎需要DMD合并C预处理器,对吧?因为这是可靠确定包含哪些标头的唯一方法.
最好方法是实现C23的带相同标签的相同类型是一样的,标签兼容规则的一些变体.导入到全局C命名空间表明,不能使用类型定义冲突的两个C标头.理想,使用D中的C应该比使用C中的C更好,并且允许在C模块之间混合兼容类型同时,通过模块系统解决.

ImportC对D来说是个很好的功能.

这就是我在聊天线程中说"用别名"的原因.importc模块本质上是选择性地仅从神奇模块中导入实际声明内容,并提供相同行为,但由于在别处规范名+定义及合并,别名不会导致类型冲突.

实现可能较难,因为你通过导入过程修改了伪模块.很容易出现前向引用错误.可手动测试该概念.以博客中相同示例为例,该示例在dmd主线上使用importC失败:

module __magic_importC;

// 表示所有导入的C定义
struct FILE;
extern(C) int printf(const char*, ...);
extern(C) int fclose(FILE*);
extern(C) void saySomethingToAFile(FILE*);
extern(C) FILE* openAFile();
//...
module b;

// 公共选择性导入
public import magic : FILE, printf, fclose, openAFile;
//...
module b2;

// 再次公共选择性导入
public import magic : FILE, printf, fclose, saySomethingToAFile;

现在成功编译测试程序.

import b;
import b2;

void main() {
    auto fp = openAFile();
    scope(exit) fclose(fp);
    saySomethingToAFile(fp);

    printf("Hello\n");
}

由于选择性导入机制.如果删除导入,你正确获得:
dd(7):错误:未定义的saySomethingToAFile标识符.
该方案兼容C和D声明规则,无大的命名空间惊喜(编译器也应禁止导入神奇的内部实现模块,这样人们就不会直接戳它),并且,这可能是可行的.