And, to be honest, I hate automatic bignum2int and vice versa conversion - because there is _no control_ over it.
That's clearly as falsified a statement as saying that you have _no control_ over the sign bit.
The excuse like "nobody really needs it" is not good enough, it remembers me "The 640K ought to be enough for everybody" and a lot of really useless (to majority) code in current Pike's core modules
"Nobody really needs it" is many times a good and true statement, but I don't think it has been used before in this thread, has it? The uselessness of several components in the core modules is because there are essentially only core modules at the moment, but you already know this so I wonder why you use an analogy you know is broken. As to how big part of the modules that are useless probably depends on your scope of vision and ability as programmer. I have used most of the modules, so by definition they are not useless to me.
/ Martin Nilsson (har bott i google)
Previous text:
2003-02-26 21:18: Subject: Re: 64 bit ints
On Wed, Feb 26, 2003 at 09:05:03PM +0100, David Hedbor @ Pike developers forum wrote:
Most likely gain speed. On 32 bit computers operations on 32 bit integers is faster than of 64 bit ones, but 64 bit ones are faster than bignum.
Exactly. Bignums are too slow in case when maximum that is needed fits in 64 bits. And, to be honest, I hate automatic bignum2int and vice versa conversion - because there is _no control_ over it.
I still cannot understand why 0x80000000 is converted to bignum while it fits in 32 bits. Well, I know the official explanation, but it seems unlogical.
Unsigned ints would be nice as well, BTW :) I can explain why and where, if someone is interested.
NB: The excuse like "nobody really needs it" is not good enough, it remembers me "The 640K ought to be enough for everybody" and a lot of really useless (to majority) code in current Pike's core modules :)
Regards, /Al
/ Brevbäraren