|
Boost : |
From: Beman Dawes (beman_at_[hidden])
Date: 2000-03-12 20:47:33
At 04:06 PM 3/11/00 -0500, Dave Abrahams wrote:
>on 3/11/00 2:59 PM, Greg Colvin at gcolvin_at_[hidden] wrote:
>
>> To add my two cents worth, in 1988 and 1989 I wrote a database
>> library that stored binary data on CD-ROM in big-endian format
>> and loaded it on Intel, VAX, Sun, Apollo, and Macintosh machines.
>> I used the same fetch-byte-and-shift trick that Darin describes
>> with happy results. Ten years later no one has found cause to
>> create platform-specific macros to improve performance.
>
>And I made the identical argument to Beman a while back. He wasn't
entirely
>convinced, as I recall, but I'll let him speak for himself.
No, actually I was convinced, and changed the prototype of the B-tree
container I'm working on accordingly.
But there are several things "fetch-byte-and-shift" might mean, and
I'm not sure which one is being referred to.
Within a portable integer POD, you might use it to describe a
portable way to generate byte ordering, rather than the alternative
platform specific byte copying technique. I thought, perhaps
mistakenly, that was what Greg was talking about.
Then there is the portable integer I/O "fetch-byte-and-shift"
technique which inputs or outputs one byte at a time in the correct
order. That was what you and I were talking about, and it has a
stronger guarantee of data portability than using an intermediate POD
and then bulk reading/writing the POD. But the POD technique appears
to be portable for practical purposes; my clients have used it for 16
years and AFAIK never found a platform it didn't work on. The three
byte (24-bit) integers are surprisingly useful when space is tight.
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk