Re: [boost] Endian library - request for comments

From: me22 (me22.ca_at_[hidden])
Date: 2006-06-02 15:21:19

On 6/2/06, Beman Dawes <bdawes_at_[hidden]> wrote:
> "Cliff Green" <cliffg_at_[hidden]> wrote in message
> > But I'm curious as to the rationale [...]
> 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.
>
Thanks, I was wondering about that as well.

On 5/31/06, Yuval Ronen <ronen_yuval_at_[hidden]> wrote:
> What I'm suggesting is to provide a library for integer types of various
> sizes/alignments. This already partly exists in Boost.Integer (AFAIK,
> support for alignment is missing there). So Boost.Integer needs to be
> expanded for this.
>
On 6/2/06, Beman Dawes <bdawes_at_[hidden]> wrote:
> I've exposed the integer_cover_operators template and moved it to a separate
> header to make it generally available. I like your suggestion to make it
> part of Boost.Integer - I hadn't thought of that.
>
I've attached a basic exact.hpp header.  I took the endian.hpp header
and cut it down to something that might make a nice addition to
Boost.Integer regardless of the outcome of the endian discussion.

It's basically the unaligned_bytes idea, but done in host endianness.
Usage is exact_int_t<N> or exact_uint_t<N>.  ( it
BOOST_STATIC_ASSERT's if N is not a multiple of
numeric_limits<unsigned char>::digits )  It might be possible to make
them faster by typepunning the internal storage to a bitfield, but I
don't think that's legal.  I didn't use integral types instead of the
char array where the size matches nor bitfields internally because
that resulted (in g++ 3.4.6) in extra padding or alignment
requirements being added to the struct, which would presumably be
unacceptable.

Perhaps exact and aligned_exact could be added to uint_t and int_t?
As a typedef to void or a fancy template trick to have it not be
provided where impossible, presumably.  Additionally, though this is
slightly off-topic, why do uint_t and int_t not use __int64_t or long
long or similar when available?  That currently prevents using N>32 on
x86 with the attached code.

It might also be a nice template argument to some big_endian<> and
little_endian<> wrapper templates, if that design is used.  I find the
appearance reasonably elegant:
boost::little_endian< short >
boost::big_endian< boost::uint16_t >
boost::little_endian< boost::uint_t<24>::exact >
boost::little_endian< boost::int_t<32>::aligned_exact >
I particularly like the separation between sizing and endianness,
though it's probably too verbose for your tastes.

Hoping that that was more productive than my last few posts,
~ Scott McMurray