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-02-02 10:09:15 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 (Was: why ada is so unpopular ?) 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> <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: <99wTb.4905$bp1.159188@news20.bellglobal.com> Date: Mon, 02 Feb 2004 12:55:04 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1075744453 198.96.223.163 (Mon, 02 Feb 2004 12:54:13 EST) NNTP-Posting-Date: Mon, 02 Feb 2004 12:54:13 EST Organization: Bell Sympatico Xref: archiver1.google.com comp.lang.ada:5187 Date: 2004-02-02T12:55:04-05:00 List-Id: Robert I. Eachus wrote: > 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. That statement is rather strong. This kind of thing is handled in the C/C++ world all the time as a configuration item. Now we could argue whether it should or not, but I don't want to beat on that dead horse here. > 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). This does work I suppose, if you add the different pragma Imports to do the mappings between C_Routine and Different_C_Routine to the same C function xyz(). But this type of a solution can explode if the variations to the different versions of OS kernels is added. Linux for example has gone through many revisions, and so IMO, it is much simpler to define pid_t as a particular type, once and for all, once you know what it should be. If you had to code for these variances everywhere a pid_t was involved, it would be much more ugly than the conditional compiled solution. But, that is _opinion_, and I expect that we'll disagree about that. ... > 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. But this was my original point: if this is done successfully in C/C++ every day, then why can we not provide the same capability (albiet in a better way) to compete at this same level? Because of the conditional compilation bias, people want to explain away the need for it. Right now, it is _difficult_ to write Open Sourced projects that compete with C/C++ ones. You might not care about that, but it is close to my heart. So while I am running short of energy for further discussion of this apparently futile idea, it was my hope to spark some good ideas for some solution(s). > In fact, you can partition the code into two separately compiled Partitioning works good for smaller "works". Once the number of variables rise, this becomes impractical. Remember, you are trying to write something that will compile on the most "user hosted platforms" as possible. You cannot dictate the version of their kernel, the version of the other software non-Ada libraries they are using. You might dictate that your project is only supportable with certain version restrictions, but you want to reduce the number of those limitations to the minimum practicable. You will _never_ be able to compile all variations yourself either, nor will you be able to test them yourself. Some source code "alternatives" are safer in the "untested" realm. You cannot every hope to code for all of the possibilities. As ugly as it is, C/C++ has managed to deal with this problem sucessfully. And I am not suggesting for a minute that we copy their approach, but they are doing _something_ right. Anyway, I have said my piece on this subject. I have no energy to flog this dead horse even more. I already know what I have to do ;-) -- Warren W. Gay VE3WWG http://ve3wwg.tk