Re: [boost] [boost::endian] Request for comments/interest

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 
as:

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 
compile.

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.

Cliff