On 9/5/05, Paul Mensonides <pmenso57@comcast.net> 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