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
mind?
Cheers,
Tom