Boost logo

Boost :

From: Matt Calabrese (rivorus_at_[hidden])
Date: 2005-09-14 00:56:20


I recently started toying with metamath for use in a current project of mine
with some really great results, though I ran into some unintuitive
organization in regards to inclusion that should probably be fixed. The main
"problem" comes from the fact that double.hpp does not include the
arithmetic specializations for double_. The reason why I consider this a
problem is that it makes working with generic mathematical metafunctions
difficult, as it requires the user of the function to know the inner
workings of the metafunction in order to know which associated arithmetic
operation files for double to include. For instance:

template< typename A, typename B, typename C >
struct math_function
: ::boost::mpl::plus< ::boost::mpl::times< A, B >, C >
{
};

Now, this metafunction may be meant to be used with any kind of compile-time
values (not just double_). All the file really should be required to include
is <boost/mpl/times.hpp> and <boost/mpl/plus.hpp>, or at least declarations
of the associated templates. Because of this, with the current layout of
metamath, the person using math_function from another file now has the
responsibility to include <boost/metamath/double/times.hpp> and
<boost/metamath/double/plus.hpp>, otherwise the metafunctions obviously will
not work correctly (well, assuming that they are actually instantiated, of
course). However, this is not a good solution since it means that the user
of math_function must know its implementation details in order to know to
include the appropriate metamath double operations. The other alternative
would be to include the double operations from the math_function file
itself, which also is not a good solution, since it implies that it knows
about double, which, considering it is a generic function meant to work with
any number of types which comply to the currently unspoken compile-time
value abstraction (unspoken for non-integral types, correct me if I'm
wrong?), is not feasible. The only truely intuitive, fully functional
solution I see is to have double's file include everything it needs to make
it conformant to the compile-time value pure abstraction (i.e. all of the
proper arithmetic operations). Short of this, there should at least be
another file that you can include which includes all of the appropriate
operations to make it comply to the proper pure abstraction which
programmers would usually include.

Also, the files for arithmetic operations currently use
::boost::mpl::apply2, yet never include <boost/mpl/apply.hpp>.

Slightly less damaging is that the double_macros file does not include
double.hpp, which is more just a little bit annoying, since it requires one
to include both files explicitly in order to actually use the macro in any
practical situation.

Finally, the constants pi, e, etc. are currently defined as being static
objects at namespace scope, which, as per Annex D.2 of the C++ standard, is
deprecated usage of the static keyword (one should prefer unnamed namespaces
instead). "ten" is also left out of these definitions, despite its existance
as a typedef in the meta sub-namespace.

-- 
-Matt Calabrese

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk