Show me the programming language where 0x80000000 fits in an 32bit integer.
Perl. For instance.
It would be interesting to know, since it would affect my coming responses quite a lot, if you actually read the answers that we provide. The information that you want to store is +0x80000000, which in effect is 33 bits. You could either do it explicitly by using 33 bits for data storage or you could flag your storage elsewhere with one bit. The difference is to hide implementational details from the user (programmer), with the obvious drawback that the programmer might get the wrong idea how the environment works. So, no, Perl doesn't do it either.
If I need _exactly_ N bits in integers, how do I do this in Pike, without wasting time and memory?
You don't. Luckily you'll never end up in that situation. If you don't believe me then high level languages isn't the thing for you. Pick one with a lower degree of abstraction that feel comfortable with. Your source will be bigger, your development cost measured in time and effort will be bigger but so will your control over details.
/ Martin Nilsson (har bott i google)
Previous text:
2003-02-27 02:58: Subject: Re: 64 bit ints
On Thu, Feb 27, 2003 at 12:00:01AM +0100, Per Hedbor () @ Pike (-) developers forum wrote:
Show me the programming language where 0x80000000 fits in an 32bit integer.
Perl. For instance.
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?
Because I don't want to waste extra 4 bytes.
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.
Really? Why it doesn't in Perl? In C? Why not to make pure N-bits integers instead of dynamically converted and expanded types? If I need _exactly_ N bits in integers, how do I do this in Pike, without wasting time and memory?
Regards, /Al
/ Brevbäraren