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