Re: reading binary data - C like bit field idiom

stevemflanagan@gmail.com wrote:


As far as I know, with the exclusion of compression formats, most binary
protocols have field sizes that are multiples of octets, so the ability
to do bit-level reading is probably more complexity than it is normally
worth.

Some other notes is that the field ordering is significant--which is
probably not a terribly big deal, but it can open up incompatibility
between JVMs, if the order of fields in reflective calls is modified.
It's also rather error-intolerant, relying on the fact that all fields
are part of the structure.

All-in-all, I'm not sure how useful it is, considering that reading (in
particular) many binary protocols requires turning some references from
numerical offsets or whatnot into references to higher-order objects. At
the very least, many have dynamic-length field members which also render
the code as presented difficult to use.

The last binary protocol I had time to play around with was the Java
class file specification, which I would consider typical of a "modern"
binary protocol. The internal structure is a bit messy, as a lot of data
points are indexes into a common pool, which is a pool of
variable-length members.

Oh yeah, and I would like to hurt whomever decided that Long and Double
constant elements were two entries long instead of one. They make
writing that code annoying.

On the bright side, that's another innovative use of annotations. Much
better than my use--as a way to set default options--which unexpectedly
involved much pain with a class loader that I would rather not have had
to experience.
--
Beware of bugs in the above code; I have only proved it correct, not
tried it. -- Donald E. Knuth