Re: [boost] Endian library - request for comments

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

"Yuval Ronen" <ronen_yuval_at_[hidden]> wrote in message 
news:e5l56m$vse$1_at_sea.gmane.org...
> Beman Dawes wrote:
>> Back in 1999 and 2000, there was discussion of a Boost Endian library to
>> provided portable big and little endian integer types. I've dusted off
>> some old code from Darin Adler, gotten his permission to use the new
>> Boost license, and have put together a library.
>>
>> A zip file of the whole library is available at
>> http://mysite.verizon.net/~beman/endian.zip
>
> I think an Endian library would be most useful in Boost.
> However, I have some doubts about this proposal. It seems to me that it
> tries to solve two problems at once, and it doesn't look good. The first
> issue is providing integer types of various sizes/alignments. the second
> issue is Endianness. Wouldn't it be better to separate those two?
>
> If we want to provide with integer types of various sizes/alignments,
> then why shouldn't they allowed to be with native Endianness? And the
> complimentary question - if we want to provide with specific Endianness
> types, then why can't we do it with regular types such as int or long?

See Chis Kohlhoff's posting, and my response to him.

> 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.

Again, see Chis' post and my response. That is pretty much what he was 
suggesting IIUC.

> Then, there's also a need for Endian classes which are templated with
> some integer type. Something like:
>
>     boost::big_endian<int> x;
>     boost::little_endian<boost::uint32_t> y;
>     boost::big_endian<boost::signed_7_bytes_aligned> z;
>
> This way, the full scope of possibilities is provided.
>
>> The docs can be read at http://mysite.verizon.net/~beman/endian.html
>
> Just a tiny thing: a sentence describing how to convert to/from native
> integers would be very helpful. I know I could find it in the code, if
> I'd bother to look, and the code sample also implies there's an implicit
> conversion from native types, but what about the other way, and anyway,
> I think a short explaining sentence is a good idea.

I've expanded the docs. Will post later today. Yes, there are conversions to 
and from the cover type.

Thanks,

--Beman