At 10:46 AM 12/27/00 -0500, Philip Newton wrote:
>On Mon, 25 Dec 2000, Dan Sugalski wrote:
>
> > For integers, we have two types, platform native, and bigint. No
> guarantees
> > are made as to the size of a native int. bigints can be of any size.
>
>So a native int could be 8 bits big?
Yup, if that's what the platform does. It's up to the port folks for that
platform to decide that.
>I think that's allowed according to
>ANSI. Not very useful, though. What's the point of having a native int if
>nothing is known about it?
Speed. And, generally, something is known about it.
>You can't reliably use it for numbers above
>100, then (or even if "at least 16 bits" is guaranteed, you can't portably
>use it for numbers bigger than 32000-odd). This is assuming that larger
>numbers automatically fail-over to bigint, otherwise, for portability, one
>would probably be better off using bigints all the time.
If you're writing perl code targeted to an 8-bit platform (assuming perl
ever runs on such a beast) you will take special care, I can guarantee it.
And odds are you're not worried about portability either.
When dealing with 'small' platforms (8 and 16 bit systems) you have to keep
the limitations of your system firmly in mind no matter what you're doing.
(Having worked up from 8 bit machines, it's my feeling that you really
can't start ignoring things until you hit 32 bitness) Portability is just
not nearly as much of an issue as speed in these cases.
And, of course, if you *were* managing a port for an 8 or 16 bit machine,
the alternative (32 bit and bigint) means emulating *all* integer ops, not
just some of them. Ick.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
