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-26 14:19:06 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!wn11feed!worldnet.att.net!207.35.177.252!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor References: <400A9B48.3060100@noplace.com> <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> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: Date: Mon, 26 Jan 2004 17:04:45 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1075154634 198.96.223.163 (Mon, 26 Jan 2004 17:03:54 EST) NNTP-Posting-Date: Mon, 26 Jan 2004 17:03:54 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:4841 Date: 2004-01-26T17:04:45-05:00 List-Id: Jeffrey Carter wrote: > Warren W. Gay VE3WWG wrote: > >> Matrix 10 POSIX environments x 10 versions of the same, x 4 >> different versions of a curses library. That leaves you with >> 400 different custom (possibly groups of) packages to work >> with. Real slick indeed. :( > > 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. > and one application-specific screen > control package leaves me with 4 different package bodies to deal with, > each of which contains code specific to one curses library. Ah, but you cannot assume that the binding for PDcurses, is going to be the same for all different POSIX platforms! Going from POSIX, to X Windows, to Win32, will change the interfaces again. It is not this simple, as the level of support changes depending upon the platform, and version of the same (in some cases). Try it in an open sourced project (as I have), and you'll be a little wiser for it. > If you want to handle those package bodies as one big file that you > preprocess to get the desired version for a platform, go ahead. The > payoff was in creating the application-specific package. > > The point should always be "what does the application require?", not > "what does the platform/environment provide?" When you code "bindings" you have to consider both. Sometimes you can push the application requirments into the thick binding, developing some distance from the thin one. But at some level, you will _still_ have to look at OS and C library level "requirements". Develop some Open Sourced code in without gnatprep, and we'll see how portable it is ;-) > Once you've done that you > can always hide the differences behind an application-specific interface. There is hiding to be sure. But down at the C and OS level, things get rather ugly when trying to be "portable". The fault of this is not so much Ada, but trying to interface to a predominantly non-Ada world. >> Think "conditional compilation". I see the "how" as an >> implementation detail, that need _not_ track the C/C++ >> experience. > > This thread is about a standard preprocessor (see the subject). But as > someone who has done this kind of thing without a preprocessor and > prefer the results, I'm convinced that what's needed is a portable way > to tell the compiler to use the package body from the Win32 directory, > or from the UNIX directory, or from the VMS directory. That functionality would help. But there is still a need for more than that. -- Warren W. Gay VE3WWG http://ve3wwg.tk