dizzy wrote:
On Friday 23 May 2008 14:05:56 Roland Schwarz wrote:
one cannot predict the alignment of the members. (Or am I wrong in this respect?)
Correct, which is why protocol binary structures are never mapped directly in memory (you can with some compiler extensions but you won't gain anything since I/O is the bottleneck in such cases and not memory copy). Instead a serialization aproach should solve such issues.
It seems I was wrong with my assumptions about endian.hpp: The proposed lib actually does have an unaligned type, i.e. it actually maps the types to char bytes[..] arrays. So the question remains what the standard has to say about alignment of struct foo { char bytes_1 [3]; char bytes_2 [2]; char bytes_3 [1]; char bytes_4 [4]; }; Will such a struct be equivalent to char bytes[3+2+1+4] ? Hmm, and foo isn't necessarily a POD. Writing this out with binary write... what is guaranteed? I fear not much.
That kinda looks like reinventing boost.serialization although with a different API (I did something similar in my code).
Indeed there are similarities. But there are differences as well. 1) I wanted a way to control layout on a per struct basis. I wanted to be able to go as low as bit position. 2) boost.serialization is fine when I want to make my in memory classes persistent, but it is of little help for the decoding of binary protocol packages. ( I do not claim it is not possible). 3) boost.serialization solves two orthogonal problems with a single implementation. One problem is mapping native types to portable types (partial overlap with standard lib << operators), the other is writing out a tree of objects (serialization). I was aiming only at the first problem, and so does endian.hpp I guess. Perhaps serialization could be refactored to allow more control over the layout within the serialize functions? -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at