Boost logo

Boost :

From: Cromwell Enage (sponage_at_[hidden])
Date: 2006-01-13 19:38:47

--- Andy Little wrote:
> "Cromwell Enage" wrote
> > I've added
> > which contains the minimal amount you need to use
> > boost::mpl::integral_c et. al. and
> > boost::mpl::math::rational. The
> > <boost/mpl/math/rational.hpp> header is reserved
> > those who need the kitchen sink.
> That seems like an odd way to do things. I would
expect the
> main header for rational to just contain the
interface for
> rational itself. Isn't it normally beneficial to
try to limit
> per header dependencies? What is the rationale
behind adding
> double and big_integral in there too?

It's an unfortunate artefact of the implementation.
If I could write
numeric_cast<double_c_tag,rational_tag> without using
numerator<double_c_tag>, or write
numerator<double_c_tag> without returning
simplified_rational<big_integral...>, I would.

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>

Not so with these other numeric constants. You can't

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


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

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.

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>


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

I'll look into it when I get the chance.

> 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

> > Anyway, typeof registration is now disabled by
> > you must now define the macro
> For each type, typeof registration is quite a
> process, so I want to only register those types that
I Really
> need to. Currently this is not the case so I get
for example
> mpl::math::zero, mpl::math::denominator, etc etc,
etc, etc
> and the kitchen sink registered for me though I
don't need
> registration for the vast majority of these types,
also bearing
> in mind that space in the Typeof vector is limited,
so I don't
> think registering everything is a practical way to
do it.


> It must be possible for me the user to be able to
register each
> type separately (only if it becomes necessary). Of
course the
> problem comes then because mpl works in terms of
> rather than type-names, so I might get an int_, an
> or a long_; a rational or a simplified_rational. I
> really know a clean solution to the problem of what
to register
> if I use mpl, (maybe 'per concept registration'
would be OK)
> but I don't think registering everything at one go
is a good
> solution.

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

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

                              Cromwell D. Enage

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around

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