From: dizzy (dizzy_at_[hidden])
Date: 2008-05-23 09:36:37
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
- ByteSize is the size in bits of a single byte for the external
- 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_at_[hidden] "Linux is obsolete" -- AST
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk