Boost logo

Boost :

From: Andy Little (andy_at_[hidden])
Date: 2006-01-14 09:49:23

"Cromwell Enage" wrote

> In the meantime, the main problem we've run into here
> is one of granularity. With integral_c and friends,
> you can just
> #include <boost/mpl/integral_c.hpp>
> #include <boost/mpl/plus.hpp>
> ...
> typedef plus<integral_c<long,1>,integral_c<short,2>
> three;
> Not so with these other numeric constants. You can't
> #include <boost/mpl/math/rational.hpp>
> #include <boost/mpl/plus.hpp>
> without
> #include <boost/mpl/math/rational_/plus.hpp>

The convention of headers used with integral_constants is already invalid
because of the use of the mpl::math namespace, therefore I dont see using a
different design as a problem.

> One of the two files must include this one. It's not
> going to be plus, so it has to be rational.
> Furthermore, for the moment, I can't be sure which
> operations will or will not be I have to
> #include them all.

Once the convention of each boost::math's types files having its own directory
is set I would be quite happy with:

 #include <boost/mpl/math/rational.hpp>
#include <boost/mpl/math/rational_/plus.hpp>

BTW What is the purpose of '_' suffix. on the directory name?

> To achieve the finer level of granularity you seek,
> then, I need a safe way to #include certain files if
> and only if other files are #included, e.g.
> #include <boost/mpl/math/rational.hpp>
> #include <boost/mpl/plus.hpp>
> implies
> #include <boost/mpl/math/rational_/plus.hpp>
> I'll look into it when I get the chance.

As stated above, just tell the user to get used to the convention of

 #include <boost/mpl/math/rational_/plus.hpp>

>> I'm not sure if you use rational with mpl integral
> constants in
>> your double implementation, but if you do that mod
> should help
>> compile times a there too.
> It's not *my* double implementation, it's Peder
> Holt's, and the metadata are already stored int

Ok... Apologies to Peder Holt for misattribuing it.


> If you can ensure that the *only* syntax you use for
> any operation (numeric or otherwise) is
> typedef typename some_op<...>::type some_constant;
> and not
> typedef some_op<...> some_constant;
> then maybe #defining a macro
> suffice.

In pqs the typeof interface is comprised of a limited number of types and
certainly not mpl operations . I would expect to have the granularity
primarily at the level of each type in the librarys interface. That means a
separate register_X_with_typeof.hpp header for each type. The messy problem of
exactly what type to register in mpl I now think needs to be left to the user,
because the mpl library author cant know how the user will use the library.

BTW while on the issue of result type of operations

The member ::type of rational being a simplified_rational sticks out as being
really odd. and with no precedent in the integral_constants.
As an example of how odd it strikes me ... If this logic was applied to
intgral_constants then the result type of

mpl::plus<int_<X>,int_<Y> >

would be


OTOH I would expect the format to be either something like:

template <typename N, typename D>
struct rational{
    typedef N numerator; // available for reflection, but no operations
on these here
    typedef D denominator; //...
    typedef rational type; // rational is a unary_metafunction

// then use (tediously)

template <typename Rational>
struct simplify_rational{
    typedef typename apply_simplification_impl<Rational>::type type; // type is
a rational<X,Y> where eg '5' /'10' --> '1'./ '2 'etc

IOW simplification should be an interface operation to simplify a rational
rather than a distinct user type resulting from the operation.

Or alternatively and more practical IMO because simplification is be required
before and after any operation anyway (to prevent overflow) it would relieve the
tedium to just do the simplification in place.

template <typename N, typename D>
struct rational{
      typedef detail::simplify_rational_impl<N,D> > impl;
    typedef typename impl::numerator numerator ;
    typedef typename impl::denominator denominator ;
    typedef rational<numerator, denominator> type ; // simplification in

IOW I dont see any advantage to making the member ::type of a rational other
than a rational.

>> [snip future plans w/o MPL]
> Try to eliminate the use of mpl::vector first, since
> it's the biggest slowdown for you. See if you can
> replace it with Boost.Preprocessor constructs. This
> method worked well for me when I gave big_integral an
> overhaul.

OK thanks for the tip.

Andy Little

Boost list run by bdawes at, gregod at, cpdaniel at, john at