
"Olaf van der Spek" <olafvdspek@gmail.com> wrote in message news:b2cc26e40603280821g993fd51s48edf012bd7a0247@mail.gmail.com...
On 3/28/06, Beman Dawes <bdawes@acm.org> wrote:
"Olaf van der Spek" <olafvdspek@gmail.com> wrote in message news:b2cc26e40603280426m1c14752do996f84adf0455ab6@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