Re: [boost] [metamath] File inclusion and use of static

From: Peder Holt (peder.holt_at_[hidden])
Date: 2005-09-15 01:44:22

Hi, Matt.

Thanks very much for the feedback.

On 9/14/05, Matt Calabrese <rivorus_at_[hidden]> 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
>