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,FREEMAIL_FROM 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-30 17:58:58 PST Path: archiver1.google.com!news2.google.com!news.maxwell.syr.edu!elnk-pas-nf1!newsfeed.earthlink.net!pd7cy1no!pd7cy2so!shaw.ca!border1.nntp.ash.giganews.com!border2.nntp.sjc.giganews.com!border1.nntp.sjc.giganews.com!nntp.giganews.com!local1.nntp.sjc.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 30 Jan 2004 19:58:56 -0600 Date: Fri, 30 Jan 2004 20:58:55 -0500 From: "Robert I. Eachus" 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 (Was: why ada is so unpopular ?) References: <49cbf610.0401170627.79c3dfe5@posting.google.com> <400A9B48.3060100@noplace.com> <400BD4B5.6000307@noplace.com> <400BDB7C.40100@noplace.com> <400D2150.6000705@noplace.com> <400E72F9.8060501@noplace.com> <100upo7ln5e3k59@corp.supernews.com> <401118FD.701@noplace.com> <40126B5E.8050205@noplace.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: NNTP-Posting-Host: 24.147.77.160 X-Trace: sv3-8BMhW62lCBFaw9zF8lVGwyi1TkoYgHTr1y8LprYfiglJfomvb9IFlTrPZ3simfc5OBln7+VJmBNyLt4!lHeDinvkKPoxfr/KaT+HZHrnhMVAtWU6070Tye5FEaAxxdzC5eGw9Kk0UYZAgQ== X-Complaints-To: abuse@comcast.net X-DMCA-Complaints-To: dmca@comcast.net X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.1 Xref: archiver1.google.com comp.lang.ada:5133 Date: 2004-01-30T20:58:55-05:00 List-Id: Warren W. Gay VE3WWG wrote: > Ah, but when you are writing code that must interface with > 3rd party software, where at one version it uses a 16-bit > value, and on other versions 32-bits etc., then you must > make your Ada code match _it_. Hmmm. I won't say that this is not a potentially killer problem. Just that the issue has nothing to do with configuration clauses. First let me deal with the different size issue. I have code that interfaces to the two different versions of the subprogram, and code that checks a (local static variable) defining which interface is used. My code is written with an if or case statement and multiple calls: procedure Thick_Binding (I: in out Integer) is begin if OS.Name = Solaris then declare Local: Int_16; begin Local := Int_16(I); C_Routine(Local); exception when Constraint_Error => ... end; elsif OS.Name = Windows then Different_C_Routine(I); end if; end Thick_Binding; The code is all legal Ada except that I have left out the thin C binding part) and the fact that there may be all sorts of trouble if C_Routine is called with a 16-bit value on Windows (or maybe not). As I said, the thin bindings part may compile on the "wrong" system or may not. But I deal with that problem in the thin bindings themselves. Why all the dire words up above? We used to call it "version skew." If your project depends on components and tools from more than three vendors or from the same vendor with different update schedules, you can have the problem that there may never be a consistant set of all three that works together. That is a problem outside the ability of anyone here to fix. All you can do is to choose the components that your project DEPENDs on, and keep that list small. In fact, you can partition the code into two separately compiled and mantained subsystems to mitigate the version skew effects. One thing that almost jumps out at you from this is something that is almost normal practice in the industry. If you have a system that depends on web protocols AND a database, you need to partition the two as well as you can. You may or may not have separate front ends for IE and Netscape/Mozilla, you may use ASPs or generate HTML, etc. But if you want to avoid headaches, the portion of the application that is database dependent (schemas, data integrity, etc.) is separate from the webserving front end. > And what is even worse, you can configure your interface > with the pragma Import(), and it will compile and link > successfully. However, at _run_ time, you'll get undefined > behavior if things don't agree. This is the impedance > mismatch that you get between Ada and C (for example), > and obviously something you try to minimize. Exactly, I use Ada to choose the right version of the interface for the actual system. But more important, as I said above, I try to partition the system as much as possible so that different subsystems/partitions/whatever can be updated separately, with only Ada interfaces maintained as part of the project in common. -- Robert I. Eachus "The war on terror is a different kind of war, waged capture by capture, cell by cell, and victory by victory. Our security is assured by our perseverance and by our sure belief in the success of liberty." -- George W. Bush