Boost Users :
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
> 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.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net