Re: [boost] [binary-int] pre-release available

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-09-09 21:36:14

> 
> On 9/5/05, Paul Mensonides <pmenso57_at_[hidden]> wrote:
> 
> > > Also note that I only allowed values which are 4 binary
> > > digits long. This was just a design choice as I believe it
> > > would be confusing having nibbles in the middle that have
> > > under 4 digits.
> > 
> > Note that one of the common uses of binary literals is as packed 
> > representations
> > of several values. It isn't all that unusual to have a representation 
> > where the
> > length in bits of each part are arbitrary. If I were you, I would allow 
> > such 
> > usage, but then you can't do a simple, direct mapping. You'd have to 
> > convert
> > the input to (e.g.) a sequence of bits first, and the break it up into a 
> > mapping
> > to hexadecimal digits. One of the advantages to doing binary literals 
> > with the 
> > preprocessor is that you *can* do this. The template mechanism cannot
> > distinguish between 0001 and 01, but the preprocessor can. (Of course, 
> > it
> > becomes unreasonable to allow bit groups that are larger than a byte.) 
> 
> Yeah, I think I will do that. I also wanted to keep 4-bit sequences for 
> clarity and to prevent people from making subtle mistakes (accidentally 
> writing 7 1s instead of 8 1s, or something like that isn't too unreasonable 
> and can be tough for a programmer to notice), however the more I think about 
> it, the more I agree that I should allow representations as you describe, 
> since the desire truely is there and it's not horribly difficult to provide 
> the functionality.
> 

Sorry for the delay. I wanted to do this on Monday but I've been busy all 
week. After that reply, Paul emailed me his take on a solution using his 
Chaos preprocessor library which influenced some changes in design for my 
implementation using boost, though I did alter the logic a bit. Since I now 
allow arbitrary groupings of bits whose lengths are 8 or below, converting 
to octal is actually simpler than converting to hex, so the macro now yields 
an octal value. In addition to that, I added two extra forms: 
BOOST_BINARY_LITERAL_D and BOOST_SUFFIXED_BINARY_LITERAL_D, which take a an 
extra parameter at the start of the list which represents the while 
recursion depth (for more efficient use when nested inside another while 
call). Originally I wanted to make _S versions as well to account for the 
BOOST_PP_SEQ_FOLD_LEFT recursion depth "s," however I ran into some troubles 
since Boost.Preprocessor concatenates "s" onto BOOST_PP_SEQ_FOLD_LEFT_ with 
## as opposed to BOOST_PP_CAT for SEQ_CAT and SEQ_TRANSFORM. This means that 
my macro call to deduce the recursion depth never expands prior to 
concatenation. I'm sure there is a way for my implementation to forcibly 
expand the macro at the level of code that my implementation uses i.e. with 
BOOST_PP_EXPAND or other techniques, but my previous experience with the 
preprocessor doesn't go very far beyond using Boost.Preprocessor to produce 
sequential template specializations, so perhaps Paul or someone else would 
be able to fill in the gap more quickly, if they wouldn't mind.

Anyway, the macro is useable, efficient, and fairly elegant at the moment, 
so there's not really too much to complain about.You can test out this 
version at:

http://www.illegal-immigration.com/Riv/boost/binary_literal2.hpp

Again, the main change is that you can now use forms such as:

BOOST_BINARY_LITERAL( 101 1000 0011101 011101 0011 ) 

where each group is 8 bits or less in size. 

-- 
-Matt Calabrese