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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,d694b5818a5102b1
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 1994-09-18 09:16:07 PST
Path: 
 bga.com!news.sprintlink.net!redstone.interpath.net!ddsw1!news.kei.com!yeshua.marcam.com!uunet!Germany.EU.net!news.dfn.de!scsing.switch.ch!swidir.switch.ch!epflnews!news
From: weber@lglsun.epfl.ch (Mats Weber)
Newsgroups: comp.lang.ada
Subject: Re: Naive question about system dependencies
Date: 17 Sep 1994 16:23:05 GMT
Organization: Swiss Federal Institute of Technology
Sender: madmats@lglsun.epfl.ch
Message-ID: <35f559$mad@info.epfl.ch>
References: <hholm.110.2E77EA6F@clark.net>  
 <Cw8GK2.M9y@inmet.camb.inmet.com>
NNTP-Posting-Host: sicsts3.epfl.ch
X-Posted-From: InterNews 1.0.1@sicsts3.epfl.ch
X-Authenticated: madmats on POP host lglsun.epfl.ch
Date: 1994-09-17T16:23:05+00:00
List-Id: <comp.lang.ada>

In article <Cw8GK2.M9y@inmet.camb.inmet.com>
stt@spock.camb.inmet.com (Tucker Taft) writes:

> Some people use the C preprocessor (or equivalent) with Ada source
> code.  However, in our environment we have found it is more
> maintainable to avoid using the preprocessor approach, and define
> interfaces to isolate target/host independent code from target/host 
> dependent code, and then have separate bodies to implement
> the interface for each target/host.

> Although this might seem like more work, in the long run
> it vastly simplifies the process of moving to a new target
> or host, and keeps the code much more readable than when
> ifdef's and associated target dependences are littered around the code.

I totally agree. We have been doing this for many Ada components
(common SQL interface for various OS's and DB vendors, common interface
to UNIX Sockets/DECnet, etc.).

In many cases, a single package specification with different bodies
solves the problem. In other cases, the private part of the package
needs to be different in different variants (this means duplication of
the spec in Ada 83, Ada 9X has significant imporvements for handling
such cases).

Using a good file naming convention helps a lot in managing the
different versions. We use something like this:

sql_interface.ads                 (common package spec)
sql_interface-oracle-vms.adb      (body for Oracle under VMS)
sql_interface-sybase-unix.adb     (body for Sybase under UNIX)

Despite the amount of code duplication, I prefer this to a preprocessor
approach.