Re: [boost] [boost::endian] Request for comments/interest

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