* Re: Source code preprocessing ?
[not found] ` <94k90a$v1n$1@nnrp1.deja.com>
@ 2001-01-26 17:43 ` Xavier HILAIRE
2001-01-26 19:40 ` Ted Dennison
0 siblings, 1 reply; 2+ messages in thread
From: Xavier HILAIRE @ 2001-01-26 17:43 UTC (permalink / raw)
To: Ted Dennison
Ted Dennison wrote:
>
> In article <3A6D87AD.66EE0AF@loria.fr>,
> Xavier HILAIRE <xavier.hilaire@loria.fr> wrote:
>
> > encounter quite a difficult problem : as far as I can remember, there
> > is no way to preprocess source code in Ada, which is quite unpleasant,
> > because my C++ code is cram full of preprocessor directives, that I
> > can't really avoid.
>
> As far as translation goes, most #defines in Ada end up being constants,
> named numbers, or renames. For #ifdefs, I just figure out which stuff is
> being compiled in and use only that. Most cases where its used for
> portability, the equivalent in Ada is already portable. If its a OS
> system call issue, Ada folks isolate that stuff in its own own platform
> dependent package and use the build system to select between packages.
>
> Of course to do all this, you have to first figure out what the C
> preprocessor is really generating. I usually just trace the #defines and
> #includes back to their source, but it can get quite hairy. In extreme
> cases you might try running the C compiler in precompile-only mode and
> taking a look at the output, or writing a little C program to tell you
> what the value of damn thing is. Yuk.
>
> Of course, the unpleasent part is that C and C++ use macros, not that
> Ada doesn't. Think about it this way: in order to tranlate C code, you
> first have to *understand* it, and *that* is where the C preprocessor is
> tripping you up.
>
> Now picture a world full of programmers attempting to work with all that
> code which they can't understand. Yet they are going ahead and putting
> it in operating systems, cars, trains, planes, rockets, etc. Scary
> thought, huh?
>
> --
> T.E.D.
>
> http://www.telepath.com/~dennison/Ted/TED.html
>
> Sent via Deja.com
> http://www.deja.com/
Thank you for your answer. Meantime, I realized the problem of porting my
#ifdefs was readily solved in Ada thanks to genericity. As a single example,
in C++ I have :
#ifdef WANT_ABRITARY_PRECISION
typedef cl_R Rational;
typedef cl_I Integer;
#else
typedef long long double Rational;
typedef long long int Integer;
#endif
where cl_R and cl_I are classes (from the CLN package) providing computations
on arbitrary precision numbers. In my C++ code, I also have to write two
versions for the functions that use the Rational type for example (it does
not make sense to test "Rational foo; if (foo == 0) ..." if Rational is
a float number), so I have to test again #ifdef WANT_ARBITRARY_PRECISION in
the .cc file.
I presume using a generic type in Ada is not enough, because one can never
know if equality between elements makes sense or not, especially the compiler.
But using a generic package *and* a boolean value indicating whether or not
equality on rationals make sense or not should solve it (am I right ?)
By the way, it is true I'll have first to *rethink* the code. Many typedefs
on scalar types will also need to be turned into "classes" (which is not the
case in C and C++). That will be quite a long work...
Best regards,
--
Xavier HILAIRE
----------------------------------------------
LORIA - INRIA Lorraine - The ISA research team
Campus Scientifique, BP 239
F-54506 VANDOEUVRE-LES-NANCY, FRANCE
Phone: +33 3 83 59 20 90
Mailto: xavier.hilaire@loria.fr
----------------------------------------------
^ permalink raw reply [flat|nested] 2+ messages in thread