From: Scott Schurr (scott_schurr_at_[hidden])
Date: 2005-09-02 15:40:51
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk