3 ms·
Scope guards seem like a really good idea. Has there been any effort to write a C to -betterC transpiler just like there has for Rust (e.g. C2Rust [0], Corrode
by dataking 7y ago
Scope guards seem like a really good idea. Has there been any effort to write a C to -betterC transpiler just like there has for Rust (e.g. C2Rust [0], Corrode [1])?
[0] https://www.github.com/immunant/c2rust https://www.github.com/immunant/c2rust
[1] https://www.github.com/jameysharp/corrode https://www.github.com/jameysharp/corrode
- mhh__ 7y agoYes. D's design is based around the idea that semantically valid C will compile in D (apart from crud like function pointer syntax etc.) but there are tools to convert C to D (As used in the dmd compiler backend (which dates back to the 80s I believe, but is now in a tasty form of spaghetti D)
- earenndil 7y ago> D's design is based around the idea that semantically valid C will compile in D AFAIK it's that code which compiles in both c and d should have the same behaviour; not that c code should necessarily compile in d. Examples of c that don't work in d are trivial. > there are tools to convert C to D (As used in the dmd compiler backend (which dates back to the 80s I believe, but is now in a tasty form of spaghetti D) Dmd's backend was ported by hand. What tools are those? I know there are tools to convert header files, but I don't know of any that actually convert code.
- mhh__ 7y agoSemantically valid as in valid D, not valid C. > Dmd's backend was ported by hand I stand corrected then. Visual D has one cpp2d built in, which I assumed was used
- nicwilson 7y ago> Dmd's backend was ported by hand. Not quite, the c++ source was massaged to be free of weird corner cases of the grammar and preprocessor (e.g. enforcing no spaces between '#' and the preprocessor keyword) and then a tool called magicport was used to convert the frontend in one shot. The backend was mostly converted by "hand" (i.e. grep after some more massaging). There are several tools to translate headers though dstep[1] and dpp[2] come to mind [1]: https://github.com/jacob-carlborg/dstep https://github.com/jacob-carlborg/dstep [2]: https://github.com/atilaneves/dpp https://github.com/atilaneves/dpp
- WalterBright 7y agoMagicport was used to convert the front end. The back end was done by hand, one file at a time (and passing the test suite after each file). Most of the conversion was "replace -> with ." and then fixing whatever the compiler complained about.
- WalterBright 7y ago> the dmd compiler backend (which dates back to the 80s I believe, You'd be right! > but is now in a tasty form of spaghetti D) Haha. It's still as awful as the C code it was manually converted to D from. I've been slowly improving it bit by bit.
- mhh__ 7y agoCould you write(apologies if I'm missing something) some documentation on how the backend is organised and the overall motion through it? I've often looked at it but been almost totally unable to grok how any thing actually works beyond the abstract of what the optimisations say on tin. Could a step forward be to start afresh and then call into the old backend stages but ultimately rewrite them in more bearable code where possible? Might be a compile time trade-off there, to an extent.
- WalterBright 7y agoIf you're really into it, the most straightforward way is to simply scan the code files one by one.