|
Boost : |
Subject: Re: [boost] [Submission] RawMemory (24-bit integers and runtime-dispatch)
From: Adder (adder.thief_at_[hidden])
Date: 2011-09-08 01:58:55
On 9/8/11, Joe Mucchiello <jmucchiello_at_[hidden]> wrote:
>>Where are you going to store the 24-bit integer that you read from
>>"raw memory" (= untyped memory = array of bytes) ? Or where is the
>>24-bit integer that you plan to write to "raw memory" stored ?
>>
>>(In what type of variable ?)
>
> It could be a vanilla int.
I would like to ask you:
How would you read the 3 bytes of data into a 32-bit integer ?
(E.g.: Read 16 bits, read 8 bits and put them together ? Read 32 bits
and discard bits ? Read 3 groups of 8 bits each ? Check alignment
before reading and branch according to result hoping to get better
performance ?)
How would you write the 32-bit integer value into 3 bytes of data ?
(E.g.: Write 16 bits and write 8 bits ? Write 32 bits ? Write 3 groups
of 8 bits each ?)
> 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) ?
> 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.
> The point of your library is to interface with low-level file formats.
> Anything goes down there.
Precisely since anything can go down there, I believe that the burden
has to be shared between the maintainer(s) of the library and the
programmers who use the library.
It cannot be otherwise, or I would be creating a monster.
The purpose of my questions has been to illustrate that, above a
certain level of choices, the possibilities fork exponentially and
thus should not be treated exclusively in the library.
That would artificially limit choices and performance for the final application.
>
>
>>My answer is probably obvious by now. I am thinking about letting the
>>programmer use the ultimate weapon she has in her toolchest:
>>
>> The mighty "if" instruction.
>
> I didn't need the long winded fluff.
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk