d的ctod工具

在​​ImportC​​​之前,翻译​​glfw-d​​​和​​libsoundio-d​​​来帮助翻译的工具.
​​​1库​​​,​​2库​​​.
用​​​树解析器​​​帮助解析包括​​预处理器指令​​​的​​.c​​​或​​.h​​​文件,然后在​​需要​​​时,用大致等效的​​D模式​​​替换​​C语法​​模式.

示例:

#include <stdio.h>

#define TAU 6.283185307179586476925

int main(void) {
char buf[32];
sprintf(buf, "tau = %f\n", TAU);
注意, 该行不是C语法
return 0;
}

输出:

module main;
@nogc nothrow:
extern(C): __gshared:

public import core.stdc.stdio;

enum TAU = 6.283185307179586476925;

int main() {
char[32] buf;
sprintf(buf.ptr, "tau = %f\n", TAU);
注意, 该行不是C语法
return 0;
}

你需要翻译(非平凡的)宏,由于D更严格的类型系统而修复错误,及其他杂项​​ctod​​​尚未正确翻译
​​​问题​​​.
随着​​​ImportC​​​的兴起,该工具的用例减少了,但是如果仍然发现​​自己​​​转换C为​​D​​,我希望这对你有用!

我想说,这对我来说非常有用!我花了很多时间翻译​​raylib​​​中的一个大约有​​6000​​​行的文件(它还没有完全完成,只是因为我目前不支持​​WASM​​​).处理所有​​死记硬背​​​的乏味问题是最大的痛苦.
有​​​数万行​​​代码需要翻译,其中大部分在​​raylib​​​从其他项目中截取的​​仅头文件​​​库中(在"外部"目录中可见).在几个小时的时间里,我已用​​ctod​​​翻译了其中的3个文件,结果表明对​​C语言​​构建的要求更少.

​​最初​​​计划是保留内部内容为​​C​​​,因为它仅在内部用于​​raylib​​​(如​​音频文件读取,压缩​​​等).我打算为​​各种架构​​​提供内部C内容的​​二进制库​​​,这样你就可用​​dub​​​.
但是现在有了该工具,我想有机会制作完整的​​​移植​​​,所以不需要​​外部工具或依赖项​​!

如果你想使用现有库,​​ImportC​​​非常好.但这仍然表明你正在使用C库.如,​​raylib​​​的所有​​文本处理​​​都使用以​​空字符​​​结尾串.它使用​​malloc/free​​​内存管理(它充满了​​缓冲区溢出​​​的可能性,就像典型的C项目可能一样).更不用说缺乏重载等.
使用​​​ImportC​​​,也许可使用​​raylib​​​与当前的​​CAPI​​​一起.但是使用​​ctod​​​,我可在​​raylib​​​的基础上创建使用起来更加​​有趣和直观​​​的​​D库​​​.
谢谢​​​丹尼斯​​!