Why?
Show me the programming language where 0x80000000 fits in an 32bit integer.
Please note that adding unsigned integers as a type requires you to add a signed bit to the data, or simply use it as the sign bit, thus getting 33bit integers. Why not go for 64bit integers while you're at it?
In C and assembly it's possible to have signed and unsigned integers and not use more than 32bits because there is really no difference betwen them there, the programmer has to know if it's signed or unsigned, the compiler can also keep track of them and warn the programmer, because C is a statically typed language.
Pike is not. Thus, adding a new type for unsigned integers is not only pointless, it defeats the purpose (speeding things up) rather nicely, and will with 99.999% probability slow things down even more than the bignum conversions.
/ Per Hedbor ()
Previous text:
2003-02-26 23:51: Subject: Re: 64 bit ints
On Wed, Feb 26, 2003 at 11:30:05PM +0100, Martin Nilsson (har bott i google) @ Pike (-) developers forum wrote:
At least, I expect that 0x80000000 will fit in 32 bits and it still will be an integer. This is logical, isn't? :)
No, it isn't.
Why?
I'd say that three of these are essential. One of these are needed to build Pike. One of these are considered so important it is statically loaded into Pike during startup.
Is Pike written in C or in Pike? :) I just can't believe that the language compiler can't be used without anything else. The core functionality (language and basic types) should work without anything else. Or do I miss anything? The only explanation that I can foresee is "we, the developers, used to build Pike this way" :)
Regards, /Al
/ Brevbäraren