-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/18/2010 10:22 PM, David Abrahams wrote:
The changes between this release and the last one are:
* Refined the use of Boost.Parameter. Now only fixedlength takes a parameter; the other options are non-parameter types, which simplifies both their use and their implementation.
I think you might want to clarify that, since “parameter” has a general meaning having nothing to do with the library.
The general meaning is the one I had in mind. :-) fixedlength is one of the structs that I use for Boost.Parameter; it takes a (small-p) parameter of a length, in bits. The other structs previously took a Boolean parameter, but now they don't -- their mere existence, or lack thereof, is enough to tell the Boost.Parameter-enabled classes what to do. It was the first time I'd used Boost.Parameter on a class template. I wasn't able to find any examples of how to use it for that, other than the sole one in the documentation, so the learning curve was pretty steep. That's why the aforementioned "other structs" took a parameter even though they really didn't need one, it was my first attempt. If you ever feel the urge to update the documentation with more examples, please feel free to use XInt's integer_t class, I'm sure the next guy who tries to learn it would appreciate it.
* Minor redesign, taking advantage of proper policy-based design.
I've always wondered about this: is there a description somewhere of what constitutes “proper policy-based design?” I've never felt confident that I understood exactly what PBD is.
Just going by what I read around the 'net (since I don't have a copy of Alexandrescu's "Modern C++ Design", and didn't want to wait for one to be delivered from Amazon), it looks like it involves using one or more class templates, specialized to perform the same task in different ways depending on its parameters. I didn't find a single page that described it really well, I went through about a dozen of them to figure it out. I'm sure someone will correct me if I've got it wrong, but here's the way I'm using it in XInt. I've got several "policy" classes: nan_functions (which handles the differences between nothrow-integers and exception-based integers having to do with the Not-a-Number value), fixed_functions (handles the high-level differences between fixed-length and variable-length integers), and unsigned_negative_functions (which handles the various behaviors of unsigned types when confronted with negative values). Each of those is a class template itself, and takes one or more parameters describing which of the various policies it should implement. integer_t uses each of those policy classes as base classes. The parameters determine which version of the policy class it gets, via specialization. To make things clearer, here's a stripped-down version of fixed_functions: template <bitsize_t Bits, typename T, BOOST_XINT_CLASS_APARAMS> class fixed_functions: virtual public integer_t_data<BOOST_XINT_APARAMS> { public: T operator~() const { [...] } }; template <typename T, BOOST_XINT_CLASS_APARAMS> class fixed_functions<0, T, BOOST_XINT_APARAMS>: virtual public integer_t_data<BOOST_XINT_APARAMS> { // Nothing needed here at present. }; If the number of bits is zero, it means the integer is variable-length; any non-zero value means fixed-length. As you can see above, fixed-length types automatically inherit an operator~ function; variable-length ones, thanks to the specialization for zero bits, don't. A better example might be unsigned_negative_functions, which has a _fix_negative_unsigned function that's different for each of the six specializations, but it's not as easy to explain. For those playing the home game, the code responsible for all this is in the bottom half of boost/xint/detail/options.hpp (the top half of it deals with Boost.Parameter stuff). Feel free to ask if you have any questions... as you can probably tell from the above, I enjoy explaining things. :-) - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwcUMQACgkQp9x9jeZ9/wRsvQCfYkm5K/m25wMJ4dfo6obeP6Nk r/sAoM64Un0Guc4Ud/xLINe7Rh0NZccd =fcYp -----END PGP SIGNATURE-----