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