On Friday 23 May 2008 15:19:32 Roland Schwarz wrote:
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?
Correct, I agree, that's why I guess I have written my own portable serialization library (although I never thought too much about reasons but those listed by you do apply in my case). I have something similar as you said, basically something like this (I'm showing only the integral case because is the basis of the framework, I also have utility serialization code for strings and such but those are based on the integral too): integral<ValueSignedness, ValueBits, Serializator<ByteSize, TypeSize, ExternSignedness, Endianess> > i; ValueSignedness can be "signed" or "unsigned" (I abuse these 2 integral types to use them as "tags"). ValueBits is the number of bits needed to form the value (the minimum number). Serializator is a concept which basically means having member functions for serialization, deserialization acording to the given template arguments representation: - ByteSize is the size in bits of a single byte for the external representation - TypeSize is the size in external representation bytes of the integral type as it will exist in the external representation (like you can specify you want an external integral type of 2 bytes of 16 bits each) - ExternSignedness can be "unsigned" (used as a tag), "signed_1scompl" (signed with one's complement), "signed_2ndcompl" (signed with two's complement) - Endianess can be "little_endian", "big_endian" which are also 2 tag types (I overlook the mixed endian and such cases, I do not need to support them). The code will take care of performing all needed conversions. One nice feature I like about my framework is that it is completely compile time configured which means that it will compile code to perform certain conversions ONLY if such conversions are required (for example if you compile the code on a high endian platform and you output in a high endian form then it will copy the data, unless other conversions are required by the ByteSize/TypeSize parameters, in general I've implemented about 4 optimized possible ways to perform the conversions considering 4 special cases of what the platform has and what has been requested, if no such optimization match is found a generic slower algorithm is used). -- Mihai RUSU Email: dizzy@roedu.net "Linux is obsolete" -- AST