Tuts/Aritcles: Incrementasl C++-to-D conversion?

[H. S. Teoh]

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