Re: [boost] Any interest in bitstream class?

On 6/28/2013 6:16 PM, Klaim - Joël Lamotte wrote:

On Sat, Jun 29, 2013 at 12:50 AM, Paul Long 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