Boost logo

Boost :

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Cliff Green (cliffg_at_[hidden])
Date: 2010-05-28 12:57:24

"Scott McMurray" wrote:
> Most uses I've seen involve different wire and memory models anyways,
> since the latter can change while the former is fixed, so I'm not
> convinced that the copy is always as terrible as has been implied.
> I'd certainly never keep a BMP header structure in memory for very
> long, for instance.

Exactly! I'm constantly irritated at work where the "wire model" is defined

Take this struct as defined in a header, cast it to char* or void* and blast
it across the network (or write to disk). Do the converse on the other side.
Swap as needed.

Every time I point out the dangers in that approach, the response I get is
"well, I made sure everything is aligned on four byte boundaries, and I know
how to swap bytes".

And then, a developer wastes three days debugging why a "bool" value doesn't
get handled correctly, or the padding at the end of the struct causes
different sizes to be transmitted across the network (or written to disk),
or an esoteric compiler aligns the values in the struct differently than
expected, or a 64-bit compile causes different padding than the 32-bit

All of my "home grown" marshalling designs require a copy somewhere -
usually values are extracted from a byte stream into app safe structures
(incoming) or appended to a byte stream (endian swapped as needed) for
outgoing needs.

So my point is:

In most general marshalling / serialization designs where portable binary
values are required, the transform step (from "wire" to "object / memory"
model) requires a copy anyway. The low-level endian facilities should not
require an extra copy, but trying to minimize all copying and constraining
the endian library design might be misguided.


Boost list run by bdawes at, gregod at, cpdaniel at, john at