Re: [boost] Support for reading/writing binary 'streams' (asio?)

From: Beman Dawes (bdawes_at_[hidden])
Date: 2006-03-28 17:57:35

"Olaf van der Spek" <olafvdspek_at_[hidden]> wrote in message 
news:b2cc26e40603280821g993fd51s48edf012bd7a0247_at_mail.gmail.com...
> On 3/28/06, Beman Dawes <bdawes_at_[hidden]> wrote:
>>
>> "Olaf van der Spek" <olafvdspek_at_[hidden]> wrote in message
>> news:b2cc26e40603280426m1c14752do996f84adf0455ab6_at_mail.gmail.com...
>> > Hi,
>> >
>> > When reading/writing binary streams, you often need to read/write an
>> > (unaligned) integer in big, little or native endian. Is there support
>> > for this in Boost?
>>
>> Back in 2000 there was considerable Boost discussion of endian integers.
>> Darin Adler and I and some others contributed.
>>
>> We came up with a set of requirements that implied a surprisingly large
>> feature set. 1, 2, 3, 4, 5, 6, 7, and 8 byte integers and unsigned are
>> required. Unaligned for all, aligned for 2, 4, and 8 byte flavors. Both 
>> POD
>
> Isn't aligned when you have unaligned just an optimization?

Yep. I personally haven't had a need for aligned, but Darin Adler did, and I 
respect his judgement.

>> and non-POD flavors were requested.
>
> How does POD apply to this?

In theory, only POD types have strong enough layout guarantees to be 
portable across I/O operations. In practice, a type that is otherwise POD 
but has constructors and a destructor is in fact portable, but some people 
are scared to use such types because some compiler down the road might add 
some extra cruft.

>> Must work correctly regardless of char
>> being signed or unsigned. Must work correctly even when internal and
>> external number of bits differ.
>> No manual configuration. No optimization
>> (supposed optimizations turned out to be pessimizations all too often
>> between CPU's, compilers, compiler versions, or even when a compiler 
>> switch
>> was changed).
>>
>> IIRC, almost everyone in the discussion had a set of roll-your-own 
>> classes,
>> but none were Boost ready.
>
> And no work was done after the discussion?
> That's a shame, because I think it's really needed.

I do too, but it takes time and I guess no one had that.

I just took a look at the internals of my own roll-you-own classes, and I'd 
be embarrassed to post them since they are really just retreaded C code. C 
style casts and that sort of thing. Originally written in 1985! They are 
also just holders, without arithmetic operations. A Boost-quality set would 
provide full arithmetic functionality.

Open source software is very user driven. If no users care enough to do it 
themselves, or fund someone else to do it, it doesn't happen until a 
developer comes along willing to spend the time/effort.

--Beman