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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,febd9e55846c9556 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-03-01 04:48:27 PST Path: archiver1.google.com!news1.google.com!sn-xit-02!sn-xit-06!sn-xit-08!supernews.com!newsfeed.news2me.com!newsfeed2.earthlink.net!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!stamper.news.atl.earthlink.net!harp.news.atl.earthlink.net!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Endianness independance Date: Sat, 1 Mar 2003 07:47:15 -0500 Organization: MindSpring Enterprises Message-ID: References: <5115eb96.0303010248.1b2b8d37@posting.google.com> NNTP-Posting-Host: d1.56.be.7a X-Server-Date: 1 Mar 2003 12:48:26 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Xref: archiver1.google.com comp.lang.ada:34766 Date: 2003-03-01T12:48:26+00:00 List-Id: Well, but if hardware is not standardized, then why would you expect languages to be standardized? (With respect to data representations.) Language X can say "All integers of any kind will be 32-bit, twos-compliment, network byte order....." That's nice for platforms where that is always available and the only integer type available. That means you can't use Language X on a lot of hardware platforms that don't support that type. Or if the hardware has other types available, you can't use those. Where does that get you? And even if you went so far as to thoroughly dictate the exact precise representation of all data within the program - right down to the number of electrons it takes to make a bit equal to one :-) - how is that going to guarantee interoperability? Program X built by manufacturer X running on box X thinks the data going down the wire looks like this.... Program Y built by manufacturer Y running on box Y thinks the data looks like that..... Both have the same kinds of integers and floats and strings, but they're all in a different order. How does the language/compiler solve that? All other things being equal, it would be nice for a language like Ada to have some reassurances about data representations - but that's what representation clauses and data types can do already. You *still* have to define clearly what the communication traffic is going to look like and then make sure your Ada code lines up with that. The fact that Ada does give you rep clauses helps you insure you've got the right representation of data for the communication traffic defined, but it can't guarantee anything. Once the ones and zeros are outside of the language's control, all bets are off. So adding things to the standard isn't really going to help. And that was my original point about how Ada isn't going to eliminate or reduce the chances that some data sent by one program is going to be misinterpreted by another program. It can't check what the other program's understanding of things is. MDC -- ====================================================================== Marin David Condic I work for: http://www.belcan.com/ My project is: http://www.jsf.mil/ Send Replies To: m c o n d i c @ a c m . o r g "Going cold turkey isn't as delicious as it sounds." -- H. Simpson ====================================================================== Amir Yantimirov wrote in message news:5115eb96.0303010248.1b2b8d37@posting.google.com... > > I think this sentence isn't true at least for 5 years already. > Interoperability is so crucial that today where is no excuse for > existance of hardware what don't support common data representation. > > As you pointed in other thread this wasn't a goal when Ada was > created. Contrary, such implicit "genericity" is a common trait of all > older languages. And opposite, a newer languages as Java and C# > exactly specify representation of integer and floating point types. > This is a direct answer to common demand of developers. > > So we lost seductive ability to write single code for various > representation of data, do we? The obvious answer is that genericity > should be explicit only. >