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 13:44:48

"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