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
> main header for rational to just contain the
> rational itself. Isn't it normally beneficial to
try to limit
> per header dependencies? What is the rationale
> 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
Not so with these other numeric constants. You can't
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 used...so 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.
I'll look into it when I get the chance.
> I'm not sure if you use rational with mpl integral
> your double implementation, but if you do that mod
> 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
> > BOOST_MPL_CFG_REGISTER_WITH_TYPEOF to enable it.
> For each type, typeof registration is quite a
> process, so I want to only register those types that
> need to. Currently this is not the case so I get
> mpl::math::zero, mpl::math::denominator, etc etc,
> and the kitchen sink registered for me though I
> registration for the vast majority of these types,
> in mind that space in the Typeof vector is limited,
so I don't
> think registering everything is a practical way to
> It must be possible for me the user to be able to
> type separately (only if it becomes necessary). Of
> 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
> if I use mpl, (maybe 'per concept registration'
would be OK)
> but I don't think registering everything at one go
is a good
If you can ensure that the *only* syntax you use for
any operation (numeric or otherwise) is
typedef typename some_op<...>::type some_constant;
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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk