Re: [boost] [Units] A first step to ease the usage of Units' quantities inside of functors created with the Lambda library

From: Torsten Maehne (Torsten.Maehne_at_[hidden])
Date: 2008-06-04 13:52:47

Hello Matthias and Steven,

following your suggestions, I've reworked my lambda.hpp (to go into,
boost/units/) to cover all overloaded operators for the Boost.Units
types quantity, unit, absolute, and one (I'm not sure, if the latter is
necessary. I just found it while grepping for missing operators.). The
open issues for lambda.hpp are:

* Maybe drop specialization for
  quantity<BOOST_UNITS_DIMENSIONLESS_UNIT(System),Y>?

* Are the specializations for boost::units::one needed in the
  context of Boost.Lambda? It seems to be an implementation
  detail of Boost.Units.

* Work out a solution for boost::lambda:bind's limitation
  concerning the binding of overloaded functions. The required
  static_cast to the function pointer (referring, e.g., a
  function from boost/units/cmath.hpp) is tedious. (I had no time yet to
  test Steven's proposal to use functors with appropriate sig template.)

I also created a unit test test_lambda.cpp (to go into
boost/libs/units/test), which tries to check each operator, for which a
specialization of Boost.Lambda's return type traits is included in
lambda.hpp. The test exposed additional issues:

* Are the checks for the operations involving
  quantity<BOOST_UNITS_DIMENSIONLESS_UNIT(System),Y> correct?
  Are they needed?

* All checks involving the multiplication/division of
  boost::units::unit and boost::units::absolute<boost::units::unit>
  types are not compiling. The compiler complains about ambiguous
  overloads for operator* and operator/ (originating from Boost.Units
  and Boost.Lambda). Therefore they are currently commented out. Some
  checks also involve the usage of Boost.Function

* The check fo unit<Dim1, System1> - unit<Dim2, System2> is not
  compiling. The compiler finds no matching definition of operator-.

* Are the checks for the operations involving absolute unit types
  correct?

* All checks for the boost::units::one types are not compiling. The
compiler complains about ambiguous overloads for operator* and operator/
(originating from Boost.Units and Boost.Lambda). Therefore they are
currently commented out.

* Add checks involving mathematical functions from boost/units/cmath.hpp
  once a solution for boost::lambda:bind's limitation concerning the
  binding of overloaded functions is found.

I improved the example lambda.cpp (to go into, boost/libs/units/example)
by adding more comments and a new thermal example demonstrating the use
of absolute quantities.

I developed the files inside a working copy of Boost.Units trunk.
test_lambda.cpp and lambda.cpp could be compiled by bjam. However, I had
to modify the Jamfile.v2 files in boost/libs/units/test and
boost/libs/units/example to contain a definition of BOOST_ROOT like this:

BOOST_ROOT = /opt/boost_1_35_0 ;

Otherwise the other Boost libraries aren't found during compilation. How
do you define this variable in Jamroot so that it becomes visible in the
Jamfile.v2 files? Defining the variable as an OS environment variable
doesn't help as the Boost.Build manual states. By googling for
BOOST_ROOT, I found statements, which suggest to use use-project /boost
: <path_to_Boost> ; instead. But this didn't help and the Boost.Build
manual seems to be still incomplete about this issue. Maybe you can help
me. This is how my Jamroot currently looks like:

use-project /boost
  : /opt/boost_1_35_0 ;

using gcc : 4.1 : g++-4.1 ;

using xsltproc : "/usr/bin/xsltproc" ;

using boostbook
         : "/usr/share/xml/docbook/stylesheet/nwalsh/"
         : "/usr/share/xml/docbook/schema/dtd/4.2"
         ;

using doxygen : "/usr/bin/doxygen" ;

using fop : "/usr/bin/fop"
          : "/usr/lib/jvm/java-6-sun-1.6.0.00"
          ;

I'm looking forward to your comments!

Best regards,

Torsten