Hi, Matt. Thanks very much for the feedback. On 9/14/05, Matt Calabrese <rivorus@gmail.com> wrote:
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.
The problem with this, is that we also want every file to be self-contained. Since metamath/double/times.hpp already includes metamath/double/double.hpp, this would lead to a circular dependency. That said, I agree with you that we need a single entry into the double math functions, but I suggest adding a boost/metamath/math.hpp (or similar) that includes all basic operations AND all math functions (sine,exponential,etc)
Also, the files for arithmetic operations currently use ::boost::mpl::apply2, yet never include <boost/mpl/apply.hpp>.
Fixed in CVS.
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.
I'll fix this as well.
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.
Haven't had time to look at this yet, but I will do as you propose. Regards, Peder Holt
-- -Matt Calabrese _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost