Re: Best practices for converting C++ to Ada

["Marc A. Criley" <mcqada@earthlink.net>]

Michael Simpson wrote:
> 
> I'm wondering if there are any published "best practices" that can be
> used when converting a C++ program to Ada.  I'm not looking for an
> automatic code translator (although one that does repetitive "grunt"
> work might be nice), but rather a set of steps that have worked well
> on other projects with respect to project layout, data-types, etc.
> When searching through the archives, I saw messages from Brian Holmes
> at GTE that they had done something like this, but the link is now
> dead.  Was the GTE work ever made public, or is there anything else
> available?

I don't know of any published "best practices", but here's some
thoughts:

First off, does the code _need_ to be converted, or could an interface
wrapper to it be created that the rest of the Ada software could call? 
(This question usually comes up in this forum when one wants to convert
Ada to C++, but it's still applicable the other way around :-)

Assuming that the C++ is reasonably well designed and implemented...

It should consist of two primary types of classes:  problem domain
classes and solution domain classes.

Problem domain classes are those implementing the "things" in the
system.  E.g., missiles, tracks, schedulers, engines, puppies, etc.

Solution domain classes are the helpers used to support the other class'
functionality, such as Strings, data structures, etc.

The problem domain classes should probably carry over into Ada classes,
i.e., a package with tagged type.  (Although any of the C++ classes that
are not parent classes, and unlikely to ever be so, could be implemented
as an Ada package with private type.)

Evaluate what the utility classes are doing.  Are there similar
predefined or freely available packages providing similar functionality,
e.g., Ada.Strings.Unbounded, or the Booch or Ada Structured Library
components?

Are there any classes that more or less appear to just be a collection
of functions that were collected together into a class just so they
weren't all floating around in the global namespace?  A class with
mostly static functions suggests this was done.  A conversion to a
comparable unit would be converting such a class to a package.

Never try to do a line-by-line conversion.

Look at the whole function and what it's doing.  If the function is
huge, there should still be some kind of functional blocking within it. 
What's occuring in those blocks?  (And don't just convert, break it
apart in this situation.)

How do the functions work together?  Would anything be gained by
repartitioning the functionality?  I.e., how much redesign do you want
to do as part of the conversion?

-------------------

If the C++ code is _not_ reasonably well design and implemented, then
there's only one option:

"A program, no matter how complex, should act as a single unit.  The
program should be directed by the logic within rather than by outward
appearances.

"If the program fails in these requirements, it will be in a state of
disorder and confusion.  The only way to correct this is to rewrite the
program."

  -- The Tao of Programming 4.1(4-5)