Re: [boost] [Endian] Review

Subject: Re: [boost] [Endian] Review
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-09-12 15:02:00

On Mon, Sep 12, 2011 at 10:47 AM, Tomas Puverle
<Tomas.Puverle_at_[hidden]> wrote:
>> A class template, perhaps named "endian_buffer", that is the same as
>> the current class endian except it does not provide the operators. The
>> typedefs provided would have "buf" added to the name (E.G. big32buf_t,
>> etc.)
>
> Beman,
>
> I would be in full support of this approach.  In fact, it's along the lines of
> what I was thinking when I suggested this signature for the "swap" function:
>
> template<typename T_>
> swapped_data<T_> native_to_big(T_)
>
> Clearly, your endian_buffer<> is very closely related to the above.  However, in
> my original email I didn't pursue the concept because I felt I already made too
> many suggestions.
>
> But since we're throwing out ideas, here are a few, off the cuff.  I am not
> married to this interface, but I think it points out the different things you
> may want to do with an endian_buffer:
>
> template<typename T_, bool Aligned_, std::size_t Size_ = sizeof(T_)>
> class endian_buffer;
>
> endian_buffer<void, ...> e1;

I'm not following the above - I'm having trouble understanding the
intent of void and how sizeof(void) would work.

> uint32_t x1 = big_to_native<uint32_t>(e1);
>
> endian_buffer<uint32_t, ...> e2;
> uint32_t x2 = big_to_native(e2);
>
> endian_buffer<uint32_t, true> e3;
> uint32_t & x3 = reorder_big_to_native(e3);

Do I understand correctly from your examples above that your
endian_buffer would to not have any associated endianness, but rather
would depend on the user explicitly calling functions to perform
conversions?

What I was thinking of was an endian_buffer where the endianness was
determined at compile time:

  template <BOOST_SCOPED_ENUM(endianness) E, typename T, std::size_t n_bits,
    BOOST_SCOPED_ENUM(alignment) A = alignment::unaligned>
    class endian_buffer;

So getting a value out after a read looks like this:

    big32buf_t v1;
    ... read into v1...
    int32_t x1 = v1;  // implicit conversion

And then update the value and writing it out looks like:

    ++x1;
    v1 = x1;  // implicit conversion
     ... write v1

I can see a possible advantage for endian_buffers without associated
endianness in applications that don't know what endianness they have
to deal with until runtime. Or am I completely misunderstanding what
you are suggesting?

--Beman