[M3devel] rant -- Why has 64 bit integer support been so hard?

[j k]

I know, like, the point of Modula-3 is to not be like C or C++ and to revisit everything in them, but..really?
Windows programming in C and C++ has had this solved reasonable for MANY YEARS.Other folks solved it similarly even longer ago, though I would claim Windows'sapproach has been successfully applied to more code -- that is, all of Windows, and then some.
Windows C/C++ is flawed here, but not in a too terrible way.In particular, Windows C/C++ has too many names for the same types, with variousflimsy rationale, mostly "style" and "history".
All you need is the following:
  signed and unsigned integer types that are exactly 8 bits in size  signed and unsigned integer types that are exactly 16 bits in size  signed and unsigned integer types that are exactly 32 bits in size  signed and unsigned integer types that are exactly 64 bits in size  signed and unsigned integer types that are exactly the size of a pointer
 10 integer types total, named something like:   INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, size_t or UINT_PTR, ptrdiff_t or INT_PTR 
 The types "int" and "long" and unsigned thereof NEVER changed size. Where people were using them for pointer sized things, you would do a simple transform to port to 64 bit:    int => INT => INT_PTR    unsigned => UINT => UINT_PTR     DWORD => DWORD_PTR  
  convert to the upper case types if not there, and append "_PTR" 
 The existing types size_t and ptrdiff_t did change size.  If someone really needed 32 bit types there, you'd have to change your code.
     Windows has more than that for historical and stylistics reasons -- upper case types,   lowercase types, types that "favor" being unsigned int or unsigned long.
 Some of it is C's fault -- the "short" and "long" stuff seems all unnecessary.
  C 9x adds in "fast" and "small" types    types that are the smallest type that is at least a certain size, I think     types that are the fastest type that are at least a certain size, I think     the idea here being that if 64 bit integers are "faster" than 32 bit integers, then "fast32" might be 64 bits
 In reality, I think the 10 types are confusing enough, but necessary, C9x multiplies out   beyond necessity. Yeah, obviously, they seem like maybe you might want them, but   it's just too many times imho. Imho 8, 16, and 32 bit integers must remain efficient   to use on all forseeable processors, since tons of code uses them, and people should not   will not be pushed to widen everything across the board. Yeah, 64K and 4GB limits are   mostly stupid these days and they very often should be widened, but folks can do that   "slowly" on their own, managing compatibilit themselves -- like where binary file i/o is used.
  Why has this been so hard in Modula-3?
  Is it that "Word" is widely used and has been pointer sized?   Or that INTEGER has been widely used and sometimes assumed to be pointer sized? 
  Is it that Sparc64 (?) and 64 bit Alpha have existed for a long time but    weren't done right and there is some legacy we are stuck with??
  Do "subrange" types make it all confusing? 
  Or merely the assignment rules among the non subrange integer types? 
 I have not paid particularly close attention; it just has always surprised me   that it was difficult to work out what to do.
 I guess it is all moot now, the issues have been worked out and the feature is there. Good.
 I am skeptical that the name "LONGINT" is good. I am skeptical that the slightly  abstracted C names "short", "int", "long" are a useful abstraction.  I think you really want the 10 base types I first listed.
 
btw, even the types that are same size as a pointer are overused in C/C++.
You don't need them for as much pointer arithmetic as people use. You can use "char*" for that.
They are useful for array indices though, the result of wcslen, sizeof(), etc.
 
File sizes should always be UINT64..
     - Jay
_________________________________________________________________
Recharge--play some free games. Win cool prizes too!
http://club.live.com/home.aspx?icid=CLUB_wlmailtextlink
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20070811/3c7460fe/attachment-0003.html>