Re: [boost] [MPL.Math] Updated version now available

From: Cromwell Enage (sponage_at_[hidden])
Date: 2006-01-11 22:39:19

--- Andy Little wrote:
> Hi Cromwell,

Happy new year, Andy.

> I am concerned  that "rational.hpp" depends on
> mpl::big_integral and mpl::double as well as some of
their
> operations, which are huge anounts of header
material.
> 
> It is simple to solve this by removing the
numeric_casts for
> big_integral and double, from rational.hpp.  I am
sure they can
> be put in the numeric stuff for these types.

I've added <boost/mpl/math/rational_/rational.hpp>,
which contains the minimal amount you need to use only
boost::mpl::integral_c et. al. and
boost::mpl::math::rational.  The
<boost/mpl/math/rational.hpp> header is reserved for
those who need the kitchen sink.

> As far as my other problems are concerned it appears
that the
> gcd header is the culprit in producing a template
too long for
> VC7.1 to hold in its debug database.

*sigh*  I *hate* it when compile-time complexity
differs from run-time complexity.

> Anyway changing the gcd algorithm to a recursive one
> wrapping boost::math::static_gcd (attached) in 
> "boost/math/commn_factor.hpp" cures the above
problem of
> compiler running out of keys and similar issues for
me.

I've reimplemented the integral_c_tag specialization
of boost::mpl::math::gcd so that it's wrapped around
an MPL-ized version of boost::math::static_gcd. 
Performance should be close to what you're looking
for.

> As previously mentioned I also reckon that it would
be best to
> make typeof registration separate.

I thought you said "optional".  Anyway, typeof
registration is now disabled by default; you must now
define the macro BOOST_MPL_CFG_REGISTER_WITH_TYPEOF to
enable it.

                              Cromwell D. Enage

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com