Re: Ada -> C or C++ translator

["Robert I. Eachus" <rieachus@attbi.com>]

pontius@btv.mbi.com.invalid wrote:


> Picture an area where C/C++ are the normal and supported tools, and
> indeed there is an aversion to "weird" stuff like Ada. Even within a
> company or area things like this can vary from one department to
> another.
> 
> So at the moment, while I may prefer to do some development in Ada, I
> am being told to "just use normal stuff that someone else can pick up
> from you, instead of something weird that will make us write it over."
> Keep in mind that software development is also not our main job, rather
> something that sometimes needs to be done so we can do our main job.
> 
> So I'd like to develop in Ada, and be prepared as needed to move the
> code to C/C++, or perhaps Java, if it needs to be given to someone
> else. Since there is no support, and hence no budget for this idea, I
> need to use free tools. Interface to existing C/C++ libraries is also
> necessary. (former easy, latter may need workarounds)
> 
> So far since the code hasn't been terribly performance sensitive, I've
> been using scripting languages so far. I may be able to keep it there,
> but I don't know.


There was a project many years ago that had us all laughing when we 
found out what was going on.  You could probably use the same technique...

The project manager and all of his team wanted to use Ada, but alas 
upper management would not let them.  The code had to be in C so it 
would be portable.  What did they do?  Well they defined a number of C 
macros, then wrote all their code in (a subset of) Ada.  Add an emacs 
macro which added the #defines and changed withs into includes, and they 
were all set.  The project code was all written in Ada, but the check-in 
process compiled the C code as well, and the CM suite also checked 
overnight that the C and Ada versions produced identical output on the 
regression suite.

Sounds like a lot of work, but it took less than a week to get the first 
version of the toolset up and running.  In fact it took some of the 
programmers longer to understand that if the Ada compile failed, there 
really was a bug in their code.  The biggest complaints of course were 
about things that were valid in K&R C and some current C compilers "let 
you get away with."  For example, returning -1 from a function defined 
to return a pointer...

In general the programming team felt that the "up front" cost through 
unit test balanced out.  Getting clean initial clean compiles from both 
Ada and C took longer, but that was more than cancelled out by the 
strong typing benefits when interfaces needed to be modified.

Of course, integration and test was scheduled for 8 months, and took 
three weeks. ;-)

I know it sounds hard, but once they got started, the #defines were easy:

#define begin {
#define end } \/\/
(Did I get that right?  It has been so long since I did "clever" things 
in cpp.  The intent of course is to make everything following the end 
keyword a comment.)

And of course, there were areas of Ada that they had no intention of 
using such as tasking and exceptions, so those were not supported by the 
translation too.