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,38159b1b5557a2e7 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2004-01-27 00:50:01 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!news-hub.siol.net!diablo.netcom.net.uk!netcom.net.uk!194.72.7.126.MISMATCH!news-peer-test!news-peer0-test!btnet-feed5!btnet!carbon.eu.sun.com!new-usenet.uk.sun.com!not-for-mail From: Ole-Hjalmar Kristensen Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor Date: 27 Jan 2004 09:35:26 +0100 Organization: Sun Microsystems Message-ID: References: <400BD4B5.6000307@noplace.com> <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <400FC8E8.2040100@noplace.com> <_JSdna166JuxFo3dRVn-hg@comcast.com> <401115B7.5020205@noplace.com> NNTP-Posting-Host: khepri06.norway.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: new-usenet.uk.sun.com 1075192526 17872 129.159.112.195 (27 Jan 2004 08:35:26 GMT) X-Complaints-To: usenet@new-usenet.uk.sun.com NNTP-Posting-Date: 27 Jan 2004 08:35:26 GMT User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 Xref: archiver1.google.com comp.lang.ada:4887 Date: 2004-01-27T08:35:26+00:00 List-Id: >>>>> "JC" == Jeffrey Carter writes: JC> Warren W. Gay VE3WWG wrote: >> Jeffrey Carter wrote: >> >>> One standard POSIX-Ada binding >> Impossible. Some UNIces provide some API structure members, >> while others don't, or provide something else again. Yes, >> you can dumb it down to a "standard" (or omit non-universal >> functionality), but by doing so you throw away functionality. >> I find that unacceptable. JC> There is a standard POSIX-Ada binding (Florist is an implementation of JC> this standard) to the POSIX standard. If you want something not in JC> this standard, obviously you're going to have to provide it yourself JC> on some platforms. If you're on a platform that doesn't provide some JC> of the functionality, then it's not a POSIX system. In neither case JC> are you dealing with different versions of POSIX. Which does not matter if what you are doing is maintaining a program which is running on multiple platforms and is compiled with multiple compilers. The program has to run even if the platform does not support a standard package like Florist. How many platforms is Florist really available on, btw.? What matters is how do I do this while keeping the code readable and maintainable. One way to combat the combinatorial explosion of platforms * compiler * library is to explicitly test for the features of the environment you really need to know, not assume something because of a particular platform/compiler. This is the approach typically used by projects using the 'configure' tool. I would really like to have some standard configuration tool which could take such parameters as input and produce a version of the system tailored to the environment in which it is to be compiled and run. In absence of this, I have to do the job manually, or use some kind of preprocessing. Btw., such a configuration tool would have to keep the exact same information internally as the condtional compilation rules handled by the preprocessor. The only difference is that with the preprocessor, the programmer can see the rules as part of the program text. JC> -- JC> Jeff Carter JC> "Beyond 100,000 lines of code you JC> should probably be coding in Ada." JC> P. J. Plauger JC> 26 -- C++: The power, elegance and simplicity of a hand grenade.