Re: [boost] [integer] Promotion of endian library code from vault

From: Neil Mayhew (neil_mayhew_at_[hidden])
Date: 2008-05-27 09:44:56

On 5/27/08 1:19 AM, Roland Schwarz wrote:
> 1) Would it be possible to add a conversion operator to char* ? At least
> for unaligned types.
>
> 2) I'd like to be able to initialize a struct containing endian<> types
> by making it a reference to some buffer.

I think perhaps you've misunderstood the purpose of endian. The idea is
to be able to define a structure like this:

struct example_t
{
    big8_t a;
    big24_t b;
    big32_t c;
};

example_t data;

You read it from a file or a socket with read(fd, &data, sizeof(data))
and then use data.a, data.b and data.c as if they were built-in integer
types.

Reading into a character buffer and then "mapping" a structure on top of
it could be done with reinterpret_cast<example_t*>(buffer), although
this is not the preferred approach. The idea is not to take individual
endian integers and force them to a particular position within a buffer,
but to let the whole struct do the work of computing the offsets. Of
course, that can be still done with reinterpret_cast, but it's not how
the library is designed to work.

> 3) The naming endian for the lib does not caption its "real" purpose. At
> least I was not aware of it altough I was searching for it. I'd 
> suggest something as
> ptype.hpp for _P_ortable _TYPES_.

You have a point here, although the original purpose of the library is
to provide a clean and safe way of accessing data that does not use
native endianness. The capability to handle unaligned and odd-sized
integers goes naturally with this, so it makes sense to me to keep the
name. It was what I searched for when I was looking for something like
this. I was trying to handle big-endian data on a little-endian platform.

I would say the purpose is NOT to provide portable types, but to be able
to handle non-portable types that are forced on us by legacy and
platform-specific data formats. Endian *can* be used to create portable
binary files, but users of endian should be careful to consider the
issues before making use of endian too heavily for new formats. A truly
portable format like XML is in general much preferable to creating new
binary data formats.

My only concern with the name endian is that there is already an
endian.hpp elsewhere in boost and I think it would be easy for people to
miss this endian, and never discover its functionality.

--Neil