Re: [Boost-users] Needs advices on design ( mpl or processor )

Subject: Re: [Boost-users] Needs advices on design ( mpl or processor )
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-01-07 05:27:36

Le 07/01/12 10:27, Allan Nielsen a écrit :
>> I have no see yet your implementation and how I can help you in, but I guess
>> that you can find your own responses in the implementation of this library
>>
>> https://svn.boost.org/svn/boost/sandbox/SOC/2010/bit_masks/lib/integer/doc/html/index.html
> Cool, I will have a look at it.
>
>
>> In addition to what you want to do, I think that all this stuff can be
>> generalized to a compressed_tuple.
>>
>> About compressed_tuple.
>>
>> Tuples of types can be compressed depending on the bits needed to store the
>> underlying type of each one of the tuple elements. For example a
>> compressed_tuple<month,day,weekday>  would take 3 bytes, but month needs only
>> 5 bits, day 3 bits and weekday 3 bits, that is 11 bits which can be
>> represented using just 2 bytes.
> It sounds interesting, and might be quite close to what I want, but not exactly:
>
> Say I need to store 11 weekday ( encoded as an int 0-6 ) in a
> compressed_tuple, then this would require 11 * 3 bits = 33 ->  5 bytes.
>
> If I store 11 weekdays in a compressed_enum the only requirement is
> that 7^11<  MAX_STORAGE_SIZE. 7^11 = 1977326743, which is less than
> 2^32 and would therefor require 4 bytes.
You are right, the compression you propose higher, but has the 
disadvantage that to need integer product and division, while the 
compressed tuple I envision needs just shifts which should perform better.

Anyway both implementations are possible for the same interface, and 
this could result into two classes modeling the same concept with 
different space and speed constraints.

Best,
Vicente