Re: [boost] Endian library - request for comments

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-02 11:16:48

"Cliff Green" <cliffg_at_[hidden]> wrote in message 
news:web-41870932_at_bk2.webmaillogin.com...
> I've dealt with (and written) endian utilities for many
> years, since almost my full career has involved writing
> software for heterogeneous distributed systems. I
> definitely think Boost needs a library to ease and
> simplify byte endian issues.
>
> But I'm curious as to the rationale for these endian
> integer types - I've always written utilities to transform
> native (or user-defined) types into a serializable binary
> format - including the option for big-endian,
> little-endian (or in one project, for "receiver makes
> right" endianness). I've never had a need for code that
> performs operations on endian types, other than as
> "placeholders" for performing I/O with them (whether over
> a network, or disk I/O). Are there application use cases
> where the application never transforms into / out of
> native / UDT's, and always uses these (endian) types
> instead?

Sure. The usual application for me is a record (or page) oriented disk file. 
The app works with a record, but often only touches a portion of that 
record. The rest remains unchanged. Doing a byte-reversing copy of the 
entire record into a buffer would kill performance.

Perhaps the best-known example of this is a page in a B-Tree. While the app 
using the B-tree may possible work with native or UDT types, the B-tree 
structural information on the page always uses the endian types. There is no 
reason to ever convert out of the endian types.

> Specifically, I've written (templatized generic) utilities
> that take integers and append them to a character (byte)
> buffer in a specified endian format (and the converse
> transformation). (Non-integral types are also supported,
> with lots of caveats and warnings - floating point type
> swapping is full of pitfalls, and any endian / byte
> swapping on a UDT has the expected restrictions - POD
> single element, no pointers or references, etc.) I would
> expect these types of utilities to be used in some form of
> serialization design (e.g. with Boost.Serialization).

Yes, but those are a somewhat different set of needs.

> Anyway, I'm just trying to expand my awareness of various
> endian related designs.

Yes, they are lots of fun. In industrial database applications there is also 
a lot of money riding on getting endianess right. You have to be able to 
build files in one environment, and sell them to folks in other environments 
without the buyers ever realizing you aren't building with their favorite 
platform.

--Beman