
On Mon, Sep 12, 2011 at 10:47 AM, Tomas Puverle <Tomas.Puverle@morganstanley.com> 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