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.