Re: Source code preprocessing ?

Re: Source code preprocessing ?

[Xavier HILAIRE]

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
----------------------------------------------

Re: Source code preprocessing ?

[Ted Dennison]

In article <3A71B72E.5BC97054@loria.fr>,
  Xavier HILAIRE <xavier.hilaire@loria.fr> wrote:

> 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

You are talking about passing the actual type of Rational into a generic
as an instantiation parameter, right?

I don't think that really solves your problem, so much as it moves it
around a little. You still have to have some code somewhere that
instantiates that type with "cl_R" or "long long double" depending on
some condition. Sure, you could put that in a source file with a version
for each platform (to be chosen by the build system). But then what have
you gained over just doing that for the type without using the generic?

> 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 ?)

First off, in Ada "=" (and ":=") exists for every type (excepting those
defined as "limited"). This includes records and arrays. Ada is a *real*
language, not some toy like C. :-)

Secondly, in a generic this issue is typically handled by one of the
following methods:

If the actual type to be supplied is unknown in composition, but can be
a record or scalar (or private type), then the formal parameter should
be defined as "private". This means that the generic can assume that "="
is available (among other things).

If the actual type to be supplied could be a "limited" type (for which
"=" is *not* available), then the formal should be defined as "limited
private". This means that the "=" function will not be available
(assignment won't be available either).

If "=" must be available, but the user might want to use a custom
equality (for instance, you might want to dereference a pointer in the
object and compare the contents rather than the pointers), then a formal
parameter for the "=" function for that type may be added to the
generic's formal parameters. The instantiating code can supply any
function with the same parameter profile as the actual and it will be
used for "=" within the generic.

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com
http://www.deja.com/