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-05 11:22:51

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