Re: [boost] [integer] Promotion of endian library code from vault

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 
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_at_[hidden]
			"Linux is obsolete" -- AST