Re: [boost] [xint] Sixth release, preliminary review again please

Subject: Re: [boost] [xint] Sixth release, preliminary review again please
From: David Abrahams (dave_at_[hidden])
Date: 2010-06-20 00:06:58

At Sat, 19 Jun 2010 01:08:37 -0400,
Chad Nelson wrote:
> 
> -----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.

So you're using a “deduced parameter” interface, I presume.

> 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.

If you could be more specific about what you found missing from the
docs, that might help.

> >> * 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-----
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com