In article 2480@accucx.cc.ruu.nl, nevries@accucx.cc.ruu.nl (Nico de Vries.) writes:
>In <13251@bwdls58.bnr.ca> woodstock!samchris@mcnc.org (Sam Christie P200) writes:
>
>>...
>>Ideally, given the optional keywords packed and not more than of
>>msb or  lsb.  Where:
>>   packed means don't optimize the structure for access speed.  Pack
>>      together the data into the minimum space.  On some machines,
>>      this may make the compiler output a bit more lengthy in order
>>      to access the data in question.
>>   msb means Most Significant Byte order, "BigEndian" or Motorola
>>      integer format.  I realize that a compiler for a littleEndian
>>      processor would have to jump through hoops to make this work.
>>   lsb means Least Signifigant byte order, "LittleEndian", or Intel
>>      integer format.  Obviously, bigEndian machies will have to
>>      do the work here.
>
>Great IDEA! One of the best I have seen lately. Many problems with file
>formats etc etc could be solved by this.

Sorry.  It won't fly.  It is not sufficient to cope with the variations
in representations between machines.


>I do see some problems however. An int is not the same on any machine. My
>personal suggestion would be different. Add 3 types byte, word and dword
>(perhaps even qword) to solve the problem of the different word sizes.
>I also would like to see an 'exact' modifier which forces an struct or
>class to behave exactly as specified (no allignment etc).
>
>To add it all up I would suggest:
>
>types  byte word dword qword
>modifiers mso lso  (msb might be confused with most sig bit)
>and an exact modifier.
>
>example
>
>exact class EXAM {
>   mso byte bStatus;
>   mso word wLength;
>   ...
>};

Still not sufficient.  To do this properly you would also have to cope
with the fact that while most machines store integers as twos-complement
binary numbers some (eg. Cray) do not.  Some might even use BCD.  Life
is even harder when you try coping with floating-point numbers.

Additional to the technical problems, this is not a concern for most programs.
It is only relevent for programs that must transfer data between machines.  It
is therefore more properly a concern of networking software rather than that of
a general purpose programming language.  Adding support for machine independent
representations to C++ would increase the complexity of the language without
adding any functionality.  C and C++ have enough low level data manipulation
facilities that you can handle representation conversions within the language.
These conversions can be packaged as subroutine libraries.  This is the
approach used in DCE (which uses ASN.1 as a canonical data representation)
and in ONC (which uses XDR for the same purpose).

 Chris Flatters
 cflatter@nrao.edu