[Python-Dev] Re: Re: Int FutureWarnings and other 2.4 TODOs (original) (raw)
Andrew Koenig ark-mlist at att.net
Thu Dec 4 09:36:40 EST 2003
- Previous message: [Python-Dev] Re: Re: Int FutureWarnings and other 2.4 TODOs
- Next message: [Python-Dev] Re: Re: Int FutureWarnings and other 2.4 TODOs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At the risk of lapsing completely into pattern vocabulary ... an AbstractFactory would create Ints and bind them to a subsequently hidden implementation. When the int involved was tiny (-1 to 256?) this AbstractFactory would use one of the pre-allocated, shared (see FlyWeight) implementations. Outside of this range distinct Short, Long or DamnHuge implementations would be created.
Or, since we're talking implementation, we could use the following hack, which I borrowed from Standard ML of New Jersey:
There is just one type, namely int.
An int is a 31-bit integer, INCLUDING sign. One extra bit indicates whether the integer is really a number or, alternatively, a pointer to the rest of the representation.
Now, you may object that implementing this strategy in C will require lots of shifting and masking. I would have thought so, too. However, every C implementation of which I am aware puts all but the most trivial data structures on boundaries of two or more bytes. This fact frees the LOW-order bit of the integer to indicate whether it is a pointer.
So here's the strategy: If the low-order bit of an integer is off, it's really a pointer to the rest of the implementation. If the low-order bit is on, then it represents an integral value that can be obtained by doing a one-bit arithmetic right shift.
Yes, it's sleazy. But I imagine it would be much faster than using inheritance.
- Previous message: [Python-Dev] Re: Re: Int FutureWarnings and other 2.4 TODOs
- Next message: [Python-Dev] Re: Re: Int FutureWarnings and other 2.4 TODOs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]