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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,355f90547d1b4b5
X-Google-Attributes: gid103376,public
From: Samuel Mize <smize@imagin.net>
Subject: Re: PRECOMPILATION
Date: 1999/02/18
Message-ID: <7ahor8$otv@news1.newsguy.com>#1/1
X-Deja-AN: 445815103
References: <918556681.260459@dedale.pandemonium.fr>
 <36C0B5D4.DEF83A66@averstar.com>
Organization: ImagiNet Communications, Ltd.
User-Agent: tin/pre-1.4-981002 ("Phobia") (UNIX) (AIX/3-2)
Newsgroups: comp.lang.ada
Date: 1999-02-18T00:00:00+00:00
List-Id: <comp.lang.ada>

Tucker Taft <stt@averstar.com> wrote:
> =:-) Vincent wrote:
>> 
>> Are there precompilation instructions in Ada95,
>> like in C (#ifdef,...etc) ? In other words, how can
>> I set compilation conditions ?
...
> However, we have had good experience with making the
> unit of variation be the whole source file.

Of course, this may affect your design. You'll have to provide
some higher-level package that interacts with the system, instead
of just embedding code to do low-level system things throughout
your program.

This is disquieting to someone with a C-style design mindset, but
is expected by an Ada-style mindset.  I'm not denigrating EITHER
mindset.  I do point out that C people write large, involved,
nested #ifdef structures instead without a second thought because
that's "normal" to them.  The Ada approach seems like "a lot of
bother" -- they see the "extra" work in Ada, but don't observe
how much it reduces the coding burden in other areas.

If you prefer, you can maintain the platform-specific packages in
a "pre-Ada" form, with conditional compilation commands, and use
a preprocessor to generate your platform-specific versions.  IIRC,
Rational has a fairly nice implementation of this.

A couple of points that may help people with C-style preprocessor
experience:

C-experienced people probably expect platform-specific issues to be
shot through the whole program, like cancer.  For instance, if a
system call's parameter can be 64-bit or 32-bit depending on the
platform, you may have #ifdefs around every call to it, and every
declaration of a variable to use as a parameter for it.

So they fear the spectre of having to maintain parallel files for
a huge number of units, and getting their logic out of synch.

This is greatly reduced by using Ada's strong typing and separate
compilation capabilities.  Once you've set up a fairly small
platform interface, all the rest of the source code is invariant.
But it takes a bit of experience to really believe that.

Also, a C-experienced developer feels he can look at just one
file and make sure that each element has an alternative defined
for each platform.

It seems so simple in theory...

Of course, if there are dependencies between elements, you wind up
with nested #ifdefs, and elements which exist in some configurations
but not in others.  You wind up with nightmares where, for instance,
a function should have been declared to return long_int on platform
X, but X didn't get into the #ifdef, so the compiler assumes it
returns an integer, and everything links and runs.  Badly.

Again, Ada largely takes care of this concern.  If you missed an
element that you need in one of your platform-specific files, the
program won't compile.  It's actually easier to maintain most
cross-platform dependencies in Ada, once you adapt your design to
the Ada mindset.

Best,
Sam Mize

-- 
Samuel Mize -- smize@imagin.net (home email) -- Team Ada
Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam