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-28 15:35:54 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!newshosting.com!nx02.iad01.newshosting.com!news-feed01.roc.ny.frontiernet.net!nntp.frontiernet.net!tdsnet-transit!newspeer.tds.net!sn-xit-02!sn-xit-01!sn-xit-06!sn-post-01!supernews.com!corp.supernews.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Standard Ada Preprocessor Date: Wed, 28 Jan 2004 17:35:00 -0600 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <101ghqq1bpk3m6e@corp.supernews.com> 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> <101bjm54k3rn8f0@corp.supernews.com> X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Complaints-To: abuse@supernews.com Xref: archiver1.google.com comp.lang.ada:5020 Date: 2004-01-28T17:35:00-06:00 List-Id: "Warren W. Gay VE3WWG" wrote in message news:a%ARb.52241$Kg6.386478@news20.bellglobal.com... > Randy Brukardt wrote: ... > > What is the point of having that functionality? Any code depending on it is > > by definition not portable. > > Performance! > > Some platforms for instance support asynchronous I/O. > Some with bugs, others not at all. If you are writing > servers, that BTW are very performance sensitive, then > if you can determine that asynch I/O works properly > (and well) on a given platform, then you're going to > use it! Anything less is inferior. Truly high-performance applications are by definition, not portable. The parts that aren't high-performance might be sharable, but again, this is a larger granularity than conditional compilation would be good for. Taking your example, you need to use tasks to make asynch. I/O work. If you don't have asynch. I/O, you probably don't want the tasks, either (because they have a substantial overhead in most cases), especially as the I/O may very well block all of the tasks. So large parts of the code will need to be different. ... > > What Claw does for features that aren't available on the current target is > > to raise Not_Supported_Error (which hopefully the caller can do something > > useful with, such as fall back to something that is supported). > > That will really help performance. Let's add some unnecessary > exceptions! Different problem. We're trying to get the code to run unmodified on as many targets as possible. Having it being self-adapting is very valuable in that aim. (Hopefully, even the binarys can run on most targets unmodified.) Randy.