On 9/8/11, Joe Mucchiello <jmucchiello@yahoo.com> 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.