Hello Steven, Thank you for your hints concerning my code. I have incorporated your comments in the attached new versions of lambda.hpp and test_lambda.cpp. Steven Watanabe schrieb:
AMDG
Torsten Maehne wrote:
* Maybe drop specialization for quantity<BOOST_UNITS_DIMENSIONLESS_UNIT(System),Y>?
These specializations should not be needed.
I removed these specializations from lambda.hpp but left the tests for dimensionless types in test_lambda.cpp in place.
* Are the specializations for boost::units::one needed in the context of Boost.Lambda? It seems to be an implementation detail of Boost.Units.
Yes it's an implementation detail. You can leave off these specializations.
I removed all specializations concerning boost::one and removed the respective tests from test_lambda.cpp
* 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.)
This strikes me as being a separate issue, which doesn't belong in the units library.
Well, I agree this is a seperate issue. However, the usefulness of quantities in lambda expressions without the possibility to easily use them in binded calls to functions defined in boost/units/cmath.hpp is quite limited.
* 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.
These shouldn't compile.
I modified the checks so that now units and absolute units are passed as well as arguments to the lambda expressions. Then the ambiguous overload errors disappear. However, for the absolute unit tests: // T * absolute<unit<D, S> > // Error: no match for operator== BOOST_CHECK(((bl::_1 * bl::_2)(300.0, bu::absolute<si::temperature>()) == 300.0 * bu::absolute<si::temperature>())); // absolute<unit<D, S> > * T // Error: no match for operator== BOOST_CHECK(((bl::_1 * bl::_2)(300.0, bu::absolute<si::temperature>()) == 300.0 * bu::absolute<si::temperature>())); this approach leads to new compiler errors: no match for operator==. I left the non-compiling commented-out tests in place for documentation purposes.
* The check of unit<Dim1, System1> - unit<Dim2, System2> is not compiling. The compiler finds no matching definition of operator-.
Again these shouldn't compile.
This strikes me as being inconsistent, because it works for: unit<Dim1, System1> + unit<Dim2, System2> So what is the conceptual difference between: // unit<Dim1, System1> + unit<Dim2, System2> BOOST_CHECK(((bl::_1 + bu::meter)(bu::meter) == bu::meter)); BOOST_CHECK(((bu::meter + bl::_1)(bu::meter) == bu::meter)); BOOST_CHECK(((bl::_1 + bl::_2)(bu::meter, bu::meter) == bu::meter)); , which compiles, and: // unit<Dim1, System1> - unit<Dim2, System2> // // Error: no match for operator- // BOOST_CHECK(((bl::_1 - bl::_2)(bu::meter, bu::meter) == bu::meter)); // // Error: no match for operator- // BOOST_CHECK(((bl::_1 - bu::meter)(bu::meter) == bu::meter)); // // Error: no match for operator- // BOOST_CHECK(((bu::meter - bl::_1)(bu::meter) == bu::meter)); , which compiles not. The files do compile fine on my Debian Linux/Stable P4 machine with g++ versions 3.4.6 and 4.1.2. I unfortunately have no access to non-GNU C++ compilers. However, do you think lambda.hpp, test_lambda.cpp, and lambda.cpp are getting into a mature enough state to be integrated into Boost.Units? Best regards, Torsten