Re: [boost] [boost::endian] Request for comments/interest

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Terry Golubiewski (tjgolubi_at_[hidden])
Date: 2010-05-29 23:35:21

> - I can do a swap_in_place<>() on the original buffer.  0 copies.  0 work 
> in
> the case when the endianness is already correct.
> - On the other hand, you have to allocate a new buffer, placement new all 
> the
> endian types, perform the copy.  Cost: Allocation + at least 2N operations 
> in
> either case, not to mention the other bad side effects related to 
> unncessary
> work which I already detailed in another post.

OK.  I hadn't been considering the memory mapped use-case.  But I still feel 
confident that the typed approach doesn't suffer any extra overhead on 
same-endian machines.
Would you please give me a realistic concrete example, so that I can code it 
up and measure the number of copies that my approach uses.
I am really "stuck" on the network messaging paradigm, so an example will 
help me.

>> We're only considering byte-ordering here too.  An equally important part 
>> of
>> the endian problem for me, is the bit-ordering.  For this I use a similar
>> technique for portable bitfields
>>
>> bitfield<endian_t, w1, w2, w3, w4, w5, ...>
>
> I am not sure what the above means, sorry.

Its somewhat off-topic, and I didn't post the code for this class, because 
its complicated, but

  bitfield<big, 3, 6, -21, 9>

means four consecutive unsigned integer bit fields with widths of 3, 6, 21, 
and 9 bits, respectively, 39 bits occupying 5 bytes, with 1 bit of zero as 
the least-significant-bit of the last octet.
The first 3 bits correspond to the most-significant bits of the first octet. 
The sign on -21 means that that field is a signed integral field, while the 
others are unsigned.

   bitfield<little, 3, 6, -21, 9>

means almost the same thing, but the first 3 bits are the least significant 
bits of the first octet, and the single pad bit of zero at the end would be 
the most-significant bit of the final octet.

My point was that I don't think of endianess as being a "swapping" problem, 
but an "ordering" problem.
The bit-endianness of messages makes this clear for me, since swapping 
doesn't work.