Re: [boost] Any interest in bitstream class?

Subject: Re: [boost] Any interest in bitstream class?
From: Paul Long (plong_at_[hidden])
Date: 2013-06-28 20:30:39

On 6/28/2013 6:16 PM, Klaim - Joël Lamotte wrote:
> On Sat, Jun 29, 2013 at 12:50 AM, Paul Long <plong_at_[hidden]> wrote:
>> What do you think? Should the bitstream library support multiple endian
>> schemes in the bit stream or is big endian enough?
> In all the use cases I am thinking about in my own projects, the
> application have a client and server parts and both client and server
> can/will be on different platforms (win/mac/linux plus some platform I'm
> not sure).
> Currently I'm using Raknet to communicate between the different processes,
> it provide a specific stream type but it's not very general.
> Does it answer your question?
Not really, since you didn't tell me what you thought the proposed 
bitstream library should support, but I think your answer would be that 
big endian in the bit stream is indeed enough.

BTW, I took a look at Raknet. Since C++ does not support reflection and 
I see a Raknet example where an entire struct is being written, the 
Raknet::Bitstream class must effectively call memcpy or, as Mathias 
Gaunard said in his email, call something like write(&x, sizeof x). 
However, I also see that if one undefines the manifest constant, 
__BITSTREAM_NATIVE_END, before calling Bitstream I/O functions for 
fundamental types or just using the Serialize() member function for 
fundamental types, Raknet performs "endian swapping." This implies a 
canonical form which is most likely big endian.

Since the components of your projects are interoperable across platforms 
with different endianness, I assume you have undefined this constant (or 
are using Serialize()) and are therefore most likely conveying data in 
network byte order on the wire. This is how my bitstream library 
works--integrals are normalized to network byte order in the bit stream. 
Although conveying data without serialization consumes fewer CPU 
cycles--less work to do--it is of course not interoperable between 
platforms of different endianness. Even without worrying about 
endianness, it is also not interoperable between the same platforms 
running software built with different compiler settings regarding 
alignment and padding within structs, unions, and classes. In other 
words, it's a really bad idea. That's why I personally think that the 
proposed bitstream library does not need to support anything other than 
big endian in the bit stream. But I'll go with whatever the consensus is.

Paul