Re: [boost] [Submission] RawMemory (24-bit integers and runtime-dispatch)

Subject: Re: [boost] [Submission] RawMemory (24-bit integers and runtime-dispatch)
From: Adder (adder.thief_at_[hidden])
Date: 2011-09-12 21:02:33

>>How would you read the 3 bytes of data into a 32-bit integer ?
>
> With a lot of code I expect your library to mitigate for me. One way: [...]

That which you desire, you shall have.

For I could not forgive myself if I let people write that kind of code
in the future.

> I assume you can figure out the big endian method. What I don't understand
> is the question. For many years now people have written code similar to the
> above to deal with weird file formats.

For many years, people have been doing it wrong.

> Do you really think is "unheard of"
> to have to read 3-bytes into a 4-byte integer? What is the point of a Raw
> Memory library that does not provide simple functions to do this?

There are no "simple" functions to do this. Not unless you just want a
wrapper (over std::reverse, std::reverse_copy or std::accumulate) that
you never benchmark.

>>> I wrote:
>
>>> Or a boost::integer::uint24_t.
>>
>>Is uint24_t a way to represent an integer in 24 bits and perform
>>operations (arithmetic, input/output, etc. -- similarly to using a
>>fundamental type) ?
>
> I found it in boost::endian

Whatever.

Boost-wannabe.RawMemory is not about converting data that cannot be
processed natively to another kind of data that cannot be processed
natively.

Once I give you the uint32_t that you so much desire, you will be able
to place it in any bitfield or limited-size integer you choose. And
once you give me the uint32_t, I will poke it back to "raw memory".

>>> How about:
>>
>>> struct foo {
>>> int rgb:24;
>>> int bar:3;
>>> int baz:4;
>>> int alpha:1;
>>> };
>>
>>Forgive me. I believe that this approach is fundamentally wrong.
>
> You don't deal with legacy code much?

I am your regular graduate newbie.

> What do you do with a legacy process
> that writes struct foo to a file 100 times and then you need to read that
> file on another system? I can't call up the programmer who made the
> monstrosity 20 years ago and tell him his approach is fundamentally wrong.

We might have to study monstruosities (in order to obtain the spec of
the binary data format or understand legacy code).

But we should not write monstruosities again.

Nor encourage that via our libraries.

I know that you know how to deal portably with the "foo" struct above.
Otherwise, I would point to
http://adder.iworks.ro/Boost/RawMemory/#TheLastThing .

Thank you truly, for you are one of the few who cares to help me
improve my unworthy library, whether I like it/you or not.

--
Sincerely,
Adder