On Thu, Feb 22, 2018 at 10:43:24AM +0200, ketmar via Digitalmars-d-learn wrote: > Nick Sabalausky (Abscissa) wrote: > > > Are there any tutorials or articles out there for "getting started > > with converting a C++ codebase to D one module at a time?" Or at the > > very least: tips, tricks, lessions learned, from those who have come > > before. > > from my experience (various codebases up to middle size, mostly C, > some C++): fsck the "one module at a time" idea! even in D modules are > interwined, and in C and C++ they're even more so. besides, converting > tests is tedious, it is much funnier to have something working.
I'm in the middle of the process of converting an old C++ project right now (it's so old that most of it dates back to C++98, and needs to be compiled with options to suppress C++11 deprecations and errors). I started out with the idea of incremental conversion, and managed to get as far as converting main() to D via shims to transition between the D/C++ boundary. The straw that broke the camel's back, though: C++ exceptions that need to percolate all the way to the top-level. I know people have mentioned Calypso, etc., but I'm mainly using dmd right now, and I really don't like the idea of putting a bunch of effort into using a different toolchain just to be able to incrementally migrate a lousy C++ project. So I'm starting to agree with ketmar: just jump into D cold turkey and convert the whole dang thing in one go. Actually, what I ended up doing right now is no longer converting, but rewriting individual modules in D. It's more effort, but I'm aiming for more idiomatic D code, and also the whole reason I started out on this task is because I want to refactor the code to fix some fundamental design flaws, but I really do not want to work with C++ anymore. So it doesn't make sense to me to struggle with making C++ code compile in D, only to immediately afterwards rewrite it anyway. Why not rewrite it right now, using the C++ code as a reference rather than a direct source. [...] > tip: try to not rewrite code in any way until it works. i know how > tempting it to replace "just this tiny thing, it is so ugly, and in D > we have a nice idiom!" NEVAR. this is by far the most important thing > to remember (at least for me), so i'll repeat it again: no code > modifications until it works! So I'm taking the wrong approach, perhaps. :-D But basically, I'm starting out with the leaf node modules and rewriting it in D, complete with unittests and what-not, to ensure it's semantically correct. Perhaps when I get to the main code I may have to compromise on my rewrite approach, because it will be too big to rewrite in one go. But we'll see. One thing that's *really* helping is D's built-in unittests. With this approach, I can actually just comment out the C++ code, then gradually uncomment individual functions one at a time, translate to D, then add unittests to make sure it works correctly. This is extremely helpful because I don't need to have a working main() to test individual translated functions -- that wouldn't work because too many things depend on too many other things, so requiring a functional main() means rewriting the entire codebase before you get something that's testable. There's just too much room for human error there. Being able to translate C++ functions one at a time and have unittests to ensure I didn't introduce any bugs, is a HUGE help. It helps build confidence that I'm actually making progress (instead of writing a huge amount of code that ultimately doesn't work!). [...] > otherwise, sweat and blood, and patience. +1. Yep, it's a lot of work. But I'm chugging away at it. Can't wait till the thing is finally running in D, and I can kill off the old C++ sources forever. Just too much unmaintainable ugliness there that I'd rather not remember. T -- "I'm not childish; I'm just in touch with the child within!" - RL
