"Dave Handley" wrote:
a. Performance when network endian is the same as machine endian - I'll discuss more on this later.
Studies have been performed comparing "receiver makes right" designs (where swapping is only performed by the receiver, if needed) with others. The costs of swapping on modern processors is pretty minimal compared with the design overhead and complexity, so "receiver makes right" many times is not justified.
b. When you are reading a complex packet of data off the network, a common use case would be to reinterpret_cast a block of data into a struct. When you are using different types for network and machine endian you end up having 2 structs - one to read the data off the network, and one to copy the data into. This could turn into a pretty severe maintenance burden.
And (as I just wrote in a different e-mail), you do know the brittleness and maintenance burden of "casting structs" and sending them over the network (or writing to file)? I've seen developers waste days trying to figure out subtle problems of alignment and mismatched message sizes. Not that I'm making a particular argument for or against a specific endian library design, just pointing out that any safe and portable marshalling scheme requires a transformation from the "wire model" to the "internal / memory / object model" somewhere (I.e. a transformation that includes a copy somewhere).
d. Finally, I would definitely want an endian interface that operated at a high level of abstraction - ie at the struct or container level, not at the built-in type level.
Definitely - while a Boost endian library might not be (and shouldn't be) a full marshalling design, it should nicely support one.
2) To copy or not to copy. I have a very big issue with any interface that enforces a copy. If I'm writing something to live on a memory limited embedded device, I absolutely want to be able to endian swap in place.
I agree that a Boost endian library should not require a copy, for the use cases where C-style low-level memory handling ("my struct matches the byte stream") are appropriate. But it should also encourage safer, more portable, and higher-level abstractions where robustness and safety is more important. Cliff