Boost logo

Boost :

Subject: Re: [boost] [boost::endian] Request for comments/interest
From: Tomas Puverle (Tomas.Puverle_at_[hidden])
Date: 2010-05-30 10:01:32

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

I don't see what you find so irritating.

First of all, as I've pointed out in other post, endianess is not a problem
restricted to sending data over a network.

Second, at some point you will have to have a raw datastructure which will be
sent to a device. That is where endianness comes to play.

Am I missing something?

> All of my "home grown" marshalling designs require a copy somewhere -

Let's not get side tracked, please. I am not proposing a marshalling library
but an endian one.

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

Doesn't this contradict your point from the beginning of the message? Sorry
but I just feel confused now.

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

Again, please let me repeat that I cannot say anything about a marshalling
solution as I'm not proposing one. However, endian swapping can, in many
cases, be done with 0 copying.

Can you please, at least in pseudocode, describe how you would go from "raw
data" to application data?

Suppose I've just done the following:

void * buffer = <allocate memory>;
read(fh, buffer, size_of_buffer);

//now what?

That may help me understand your use case better.

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

I don't feel like I'm doing that. I have provided two interfaces - a copying
and a non-copying one without compromising the design in any way. If you've
looked at the code, can you perhaps be more specific about what you have in



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