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-29 10:07:41 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!priapus.visi.com!orange.octanews.net!news.octanews.net!news-out.visi.com!petbe.visi.com!newspeer.monmouth.com!newsfeed.mathworks.com!wn13feed!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: <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: Thu, 29 Jan 2004 12:53:09 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1075398737 198.96.223.163 (Thu, 29 Jan 2004 12:52:17 EST) NNTP-Posting-Date: Thu, 29 Jan 2004 12:52:17 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:5052 Date: 2004-01-29T12:53:09-05:00 List-Id: Ole-Hjalmar Kristensen wrote: > "Warren W. Gay VE3WWG" writes: >>Ole-Hjalmar Kristensen wrote: >>>>>>>>"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.? >> >>Listen, C programmers do this thing every day. "If some feature >>is available, then do it this way, else do 'it' in a more >>inferior way". > > For the past 20 years, I think about 90% of the code I have been writing > is C or C++, so please cool down... I am calmer today ;-) > I think you may have misread my answer. The sentence > "Which does not matter if what you are doing is maintaining..." is answer to > "There is a standard POSIX-Ada binding...". > > To re-state my position: It does not matter that there is a standard POSIX-Ada > binding if I am maintaining a program on a platform where this standard > POSIX binding does not exist. I still have to get my system working, somehow. > The problem does not go away because of this standard binding. Ok, yes. And my original point was that Florist does not cover all of your POSIX-like needs anyway. To get equal footing with C/C++ environments, you need Ada bindings to all of the shared libraries that GNU/Linux provides for example. As you understand, this is where things get necessarily ugly. >>>What matters is how do I do this while keeping the code readable and >>>maintainable. >> >>Of course! I could argue that conditional compilation may >>make it clearer where I'd run into portability problems >>on some platforms, because the different offending code >>is right in front of me (vs sitting somewhere else, >>unexplored). > > I never said conditional compilation was bad. I'll reiterate that readable code is first on my list also. But I would like the choice to forgo that for thin bindings. I don't there there is much justification for it outside of thin bindings. ... > Please observe that I am not arguing against conditional compilation. > Given the state of the art, it may well be the best solution in a number > of circumstances. Which was really my thrust in this thread. If an elegant solution has not emerged, then it is time to look at the "requirments" for such. One of them is suspect ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk