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

From: Scott Schurr (scott_schurr_at_[hidden])
Date: 2005-09-02 15:40:51

Greetings,

At the moment I'm anticipating a formal review of the binary_int
implementation sometime in October.  This seems like a good time
to suggest that anyone who's curious take a look at the 
pre-release version of binary_int.  Anything caught now improves
the likelihood that the October review will be the final review.

The binary_int template allows the compile time expression of 
integer binary literals. Usage looks like this:

  unsigned int regValue = binary_int<1000,1001,0011,0000>::value
  
There is no run-time code overhead for using this template; all 
overhead is at compile time. I expect these binary literals to 
work any place that an integer literal would work at compile 
(not preprocessing) time.  The template is designed to allow 
binary values up to 64-bits to be expressed, although it has 
only been tested up to 32-bits to date.

You'll find the template, its documentation, and a small unit 
test at:

  http://boost-consulting.com/vault/ under binary_int.zip

In addition to the issue of whether the template works for you, 
there are four points I'm curious about:

 o Some compilers used to complain when the most significant bit 
   of a binary_int was set.  I've fixed that problem as well as 
   I know how.  Do any compilers still see this problem, and 
   does it produce warnings or full fledged errors? 

 o Does the template properly produce 64-bit values on a 64-bit
   compiler?  The unit test only goes up to 32-bits since neither
   of my compilers support 64-bit compilation.

 o Are the names 'binary_int' and 'binary_nibble' good names?
   Pavel Vozenilek, who has very kindly been my Boost mentor,
   suggests 'bits' and 'nibble' may be better names.

 o There's a BOOST_WORKAROUND in the template so I can do
   something vaguely BOOST_STATIC_ASSERT like.  Pavel suggests
   that the workaround would be better solved in a general
   form that all compilers can accept.  What would be a
   better solution to the BOOST_WORKAROUND?

Thanks for your consideration.

Scott Schurr