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-07 21:40:03

Hi there !  And thank you for your time and for your questions.

Before I answer the first question regarding 24-bit integers, etc.,
please allow me to kindly ask you:

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 ?)

Regarding the second question, regarding run-time dispatching of
operations (as opposed to compile-time dispatching), I will start with
a couple of examples that supports your question even more:

It is not just the endian-ness that might not be known at
compile-time. The alignment of data might also not be known before
explicitly checking it at run-time. Let me quote from the ugly
documentation that I have written
(http://adder.iworks.ro/Boost/RawMemory/#UsersManual):

"When we are dealing with an array of values (i.e. contiguous values)
and performance is critical, we might want to check whether the data
is aligned and specifically demand unchecked_memory_xfer if it is."

Ultimately, the number of bytes that are used to represent the integer
may be variable. Such is the case with the "mapping pair offsets" used
by NTFS to locate the contiguous runs of clusters that make up the
(non-MFT resident portion of the) file. In order to save precious MFT
(Master File Table) entry space, signed offsets are stored in
variable-sized (1 to 8-byte long) integers.

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.

For the specific example you kindly gave, I am thinking that the
following syntax might be useful for reading UCS-2 characters from a
file saved with Notepad (in "Unicode" or "Unicode Big Endian" format):

    const uint16_t nByteOrderMask =
        raw_memory <uint16_t, little_endian>::peek (pFileBuffer);

    const bool bBigEndian =
        nByteOrderMask == 0xFEFF;

    ... // The loop:
    {
        const uint16_t cCurrent =
            bBigEndian ?
                raw_memory <uint16_t, big_endian>::peek (pCurrent)
                :
                raw_memory <uint16_t, little_endian>::peek (pCurrent);
        ...
    }

I await your thoughts... Thank you again !  (-:

--
Yours truly,
Adder
On 9/7/11, Joe Mucchiello <jmucchiello_at_[hidden]> wrote:
> For a library designed to deal with the weirdness of binary file formats,
> I'm surprised it does not support 24-bit integers of arbitrary
> alignment/sign.
>
>> uint32_t x = raw_memory <uint32_t, big_endian>::peek (&vbBuffer [5]);
>
> Do you also support a non-template "endianness" parameter? Sometimes you
> don't know the endian-style of the file until you open it and read some
> value out of it.
>
>   Joe
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>