Re: Endianness independance

["Marin David Condic" <mcondic.auntie.spam@acm.org>]

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 <amir@iae.nsk.su> 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.
>