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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,fa07350fd81f7563 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,fa07350fd81f7563 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,80e8e0df8032d89e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-11-01 20:20:50 PST Path: nntp.gmd.de!xlink.net!howland.reston.ans.net!spool.mu.edu!darwin.sura.net!gwu.edu!gwu.edu!not-for-mail From: mfeldman@seas.gwu.edu (Michael Feldman) Newsgroups: comp.lang.ada,comp.lang.c++,comp.object Subject: Re: Is C/C++ the future? Date: 1 Nov 1994 21:16:39 -0500 Organization: George Washington University Message-ID: <396sq7$5j0@felix.seas.gwu.edu> References: <1994Oct25.234705.26530@sei.cmu.edu> <85DF1879046@annwfn.com> <1994Nov1.131914.14904@sei.cmu.edu> NNTP-Posting-Host: 128.164.9.3 Xref: nntp.gmd.de comp.lang.ada:16395 comp.lang.c++:76977 comp.object:16911 Date: 1994-11-01T21:16:39-05:00 List-Id: In article <1994Nov1.131914.14904@sei.cmu.edu>, Richard Riehle wrote: [snip] > Even though Ada 9X provides some relief in this area, the continued progress > in new hardware designs will necessitate retaining the capability for > interfacing high-level code to low-level code in some applications. Part of the "relief" provided in Ada 9X is the annexes, which can be thought of as optional, extendible, parts of the standard. The annexes do not introduce syntax, only packages, types, pragmas, etc. See below. >>Should the language include platform independent ways of doing most of >>those 'platform-specific' things? It would seem to follow the Ada >>philosophy of maximal safety; after all, if pieces of configuration >>control are required to be part of the linker, why not define an 'Ada >>windows' interface (for example) and then require compilers for >>platforms with window support to map their functionality onto the >>interface? This is a nice idea, and is certainly a reasonable sort of thing to put in a future annex. However, your example turns out to be a rather difficult case, because "windows" is an area with much diversity, and reaching consensus on a common interface that would nicely map to (say) Mac, Windows, OS/2 PM, and X, without resulting in a too-low common denominator, would be very hard. If you think it would be feasible, how 'bout if you take a crack at specifying it. > In principle, I agree. Much of this lies at the feet of the compiler > vendors, who have chosen not to go beyond simple validation with some > of their products. And validation requires nothing more than the bare > essentials of the language. I provides no guarantee that the compiler > will be useful for real work. Well, in this case we can lay at the vendors' feet that they never got together on a quasi-standard X binding. There are, unfortunately, _several_ X bindings, mostly vendor-specific. Mike Feldman ------------------------------------------------------------------------ Michael B. Feldman - chair, SIGAda Education Working Group Professor, Dept. of Electrical Engineering and Computer Science The George Washington University - Washington, DC 20052 USA 202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet) ------------------------------------------------------------------------ Ada on the World-Wide Web: http://lglwww.epfl.ch/Ada/ ------------------------------------------------------------------------ "Non illegitimi carborundum." (Don't let the bastards grind you down.) ------------------------------------------------------------------------