Boost logo

Boost :

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

> 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

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


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