"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