
Boost : 
From: Cromwell Enage (sponage_at_[hidden])
Date: 20060113 19:38:47
 Andy Little wrote:
> "Cromwell Enage" wrote
>
> > 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.
>
> 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>
>
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>
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.
#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.
> 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
BOOST_STATIC_CONSTANTs.
> > Anyway, typeof registration is now disabled by
default;
> > you must now define the macro
> > BOOST_MPL_CFG_REGISTER_WITH_TYPEOF to enable it.
>
> For each type, typeof registration is quite a
heavyweight
> 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.
Okay.
> 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
concepts
> rather than typenames, so I might get an int_, an
integral_c,
> or a long_; a rational or a simplified_rational. I
don't
> 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
BOOST_MPL_CFG_TYPEOF_NO_REGISTER_FUNCTIONS will
suffice.
> [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.
Cromwell D. Enage
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk