From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-06-02 11:16:48
"Cliff Green" <cliffg_at_[hidden]> wrote in message
> 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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk