|Posted by H. S. Teoh|
in reply to Walter Bright
Posted in reply to Walter Bright
On Sun, May 15, 2022 at 10:21:18AM -0700, Walter Bright via Digitalmars-d wrote:
> On 5/15/2022 4:55 AM, H. S. Teoh wrote:
> > There is, of course, the option of rewriting said C library in D.
> In my experience, it is not an option to rewrite working C code into D.
> Note that I have successfully converted small and medium C code projects to D. I've done other translations of programs from one language to another.
I've converted a medium-sized C++ project into D. (Not a library, though, which would entail different mechanics because there'd be external code that uses it, so API compatibility becomes an issue.)
> 1. if you don't have a test suite for the program, a successful conversion becomes an order of magnitude harder
> 2. converting a program all at once does not work. It must be done incrementally, one function at a time
On the contrary, with the C++ project that I converted, I found it too onerous to convert one function at a time. I started off that way, but quickly found it too painful because of tight coupling in the original code -- converting a single function sometimes actually requires converting 15 functions because they are all interdependent and/or use share the same data structures.
In theory I could've done it, I suppose. But I eventually threw in the towel, and decided to leap into D cold-turkey. Strictly speaking it was more a complete rewrite in D from ground up than converting, using the C++ code more like an external reference for comparing behaviour than actually converting the code itself. Fortunately, I had a largish website that provided plenty of actual use cases for the program, so even though it wasn't technically a test suite it did serve as a check for whether I failed to match the old C++ behaviour, as well as a progress meter of how far the D code has progressed.
Now the entire project is in D, and I'm mighty proud of it. It's much more maintainable than the original C++ codebase, and thanks to D's modern features it's much easier to implement new features without constantly getting bogged down by the amount of babysitting that C++ demands.
> 3. even so, when faced with a large, complex project, there's just no business case for doing a conversion
> Even just converting the .h files to D can be a major, rather unpleasant undertaking. We've put a lot of time into converting the various system .h files into D for druntime. There's always a risk of a mistake, and we've made them and the result is bizarre crashes because of ABI mismatches. Hand-checking them is error-prone, tedious and very boring work.
Yes, automatic conversion is the way to go. Even when I'm "hand-copying" C prototypes into D, I always use cut-n-paste + edit afterwards, rather than typing it out from scratch, because the latter is so much more error-prone. My latest project, which uses libxcb heavily, has a sed script for doing 90% of the work recasting C types into D -- routine stuff like uint8_t -> ubyte, etc.. Routine work is the most dangerous in terms of likelihood of human error, because humans are bad at doing repetitive things accurately. After the first 5 times your brain just zones out and defers to muscle memory, and mistakes creep in that you're not even conscious of.
Береги платье снову, а здоровье смолоду.