From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ea6e62e15bb000fc X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-01-26 09:50:09 PST Path: supernews.google.com!sn-xit-02!sn-xit-01!supernews.com!newsfeed.stanford.edu!arclight.uoregon.edu!fr.usenet-edu.net!usenet-edu.net!ciril.fr!loria.fr!not-for-mail From: Xavier HILAIRE Newsgroups: comp.lang.ada Subject: Re: Source code preprocessing ? Date: Fri, 26 Jan 2001 18:43:10 +0100 Organization: LORIA - INRIA Lorraine Message-ID: <3A71B72E.5BC97054@loria.fr> References: <3A6D87AD.66EE0AF@loria.fr> <94k90a$v1n$1@nnrp1.deja.com> NNTP-Posting-Host: hammeville.loria.fr Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.9 i686) X-Accept-Language: en To: Ted Dennison Xref: supernews.google.com comp.lang.ada:4569 Date: 2001-01-26T18:43:10+01:00 List-Id: Ted Dennison wrote: > > In article <3A6D87AD.66EE0AF@loria.fr>, > Xavier HILAIRE 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 ----------------------------------------------