ctod: a tool that translates C code to D

Steven Schveighoffer schveiguy at gmail.com
Thu Oct 13 19:43:25 UTC 2022


On 10/13/22 3:18 PM, Dennis wrote:

> The output is supposed to be a good starting point for manual 
> translation: tedious syntax changes are done for you, but you're left 
> with the task of translating (non-trivial) macros, fixing errors because 
> of D's stricter type system, and other misc things ctod doesn't 
> translate properly yet (see also [issues on 
> GitHub](https://github.com/dkorpel/ctod/issues) 🙂).

I want to say, this has been incredibly useful to me! I spent many hours 
translating one file in raylib, which was about 6000 lines (it's still 
not completely finished, but only because I'm not currently supporting 
WASM). Dealing with all the rote tedious issues was the biggest pain.

There are tens of thousands of lines of code left to translate, and most 
of them reside in header-only libraries that raylib sniped from other 
projects (seen in the "external" directory). In a few hours time, with 
ctod, I've already translated 3 of these files, and the result means 
less requirements for C building.

My original plan was to just leave the internal stuff as C since it's 
only used internally for raylib (e.g. audio file reading, compression, 
etc.). I was going to actually ship binary libraries of the internal C 
stuff for various architectures so you could just use dub.

But now with this tool, I think we have a shot of making a complete 
port, so no external tools or dependencies are needed!

> With the rise of ImportC the use cases for this tool decrease, but in 
> case you still find yourself translating C to D, I hope this is of use 
> to you!

I want to say something about this. ImportC is great if you want to use 
an existing library. But it still means you are using a C library. e.g. 
raylib uses null-terminated strings for all text processing. It uses 
malloc/free for memory management (and it is actually pretty full of 
buffer overflow possibilities, as a typical C project might be). Not to 
mention the lack of overloads...

With ImportC I might be able to just use raylib with it's current C API. 
But with ctod, I can build upon raylib to make a D library that is even 
more fun and intuitive to use.

Thanks Dennis!

-Steve


More information about the Digitalmars-d-announce mailing list