[M3devel] cm3 regression

[Jay]

Well, something has to give somewhere.
INTEGER could be a "natural" signed integer if you want, however you have to balance the desire for a "natural" integer with any persistant format.
It's not like 32 bit integers are going to be inefficient anywhere, so not changing the more concrete meaning of various code isn't going to really hurt it.
What does hurt is 1) breaking code that really needs to represent the entire address space or 2) breaking code that really needs to maintain binary compatibility with persistant file formats.
You lose either way.
It just seems like the best tradeoff is to provide explicitly sized signed and unsigned types, and pointer sized signed and unsigned.
And then decide what your ranges are and know that 32 bit integers are always efficient and 64 bit integers are always ok or better.
 
Really, 32 bit integers are usually adequate or no less efficient.
Really, it's hard to go wrong for efficiency, 32bit or 64bit integers, and easy to go wrong in terms of compatibility by changing the sizes of types..
 
 - Jay



> To: jayk123 at hotmail.com> CC: m3devel at elegosoft.com> Subject: Re: [M3devel] cm3 regression > Date: Mon, 14 Apr 2008 10:18:14 -0700> From: mika at async.caltech.edu> > Jay writes:> >--_50e47a65-f79d-472b-8eaf-fbcc30b6410e_> >Content-Type: text/plain; charset="iso-8859-1"> >Content-Transfer-Encoding: quoted-printable> >> >new source -> compiling Cstdlib.i3"..\src\C\32BITS\BasicCtypes.i3", line 18=> >: illegal based LONGINT literal, zero used"..\src\C\32BITS\BasicCtypes.i3",=> > line 18: illegal based LONGINT literal, zero used> > long_long =3D [-16_7fffffffffffffffL-1L .. 16_7fffffffffffffffL]=> >;> >=20> >Why isn't this LONGINT? So that NT386 can limp along? And it'd be correct f=> >or the rest, eh?> >I'll try it and see..> >=20> >The underlying system (the compiler) has (U)Int[8,16,32,64]> >They should just be used here imho..> >=20> >Also, what should "long" be on 64bit?> >On Windows it is 32 bits always.> >On 32 bit systems it is 32 bits.> >I think the 64bits directory is going to be forked for AMD64_NT_*.> >The Windows decision imho has successfully been applied to more code and mo=> >re users so therefore is better by practical success, even if the whole iss=> >ue is problematic almost no matter what. Clearly the C and Modula-3 notions=> > of integers are pretty poor..> > I have to re-code my program to use Int64 if I want it to use the> natural INTEGER size on 64 bit machines? No thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080414/4f778653/attachment-0002.html>