[units] check if quantities are convertible one into the other

Hi,
I have two (or more) default (or user defined) system units. For certain
operations I assume that one quantity in one system can be converted into
another quantity in some other system with the same dimension. What
conversions are allowed depend on the included headers at best.
What is the best way to check at compile time that one quantity can be
converted into another?
For example, I have this function that sums two quantities with the same
dimension and returns the result of the left term. The function assumes that
qright is convertible to qleft. If it is not convertible I would like to
catch the error early with static_assert (or even with some enable_if to
ignore the function)
template

AMDG On 12/15/2010 10:12 AM, alfC wrote:
I have two (or more) default (or user defined) system units. For certain operations I assume that one quantity in one system can be converted into another quantity in some other system with the same dimension. What conversions are allowed depend on the included headers at best.
What is the best way to check at compile time that one quantity can be converted into another?
For example, I have this function that sums two quantities with the same dimension and returns the result of the left term. The function assumes that qright is convertible to qleft. If it is not convertible I would like to catch the error early with static_assert (or even with some enable_if to ignore the function)
template
quantity< unit > sum_to_left( quantity< unit > const& qleft, quantity< unit > const& qright ){ return boost::units::operator + (qleft, quantity< unit >(qright)); }
The ability to test for a conversion is liable to result in ODR problems. On the other hand, the errors are pretty horrendous right now. This is a fairly common problem. Could you file a trac ticket. I'll try to make the error more readable. In Christ, Steven Watanabe

The ability to test for a conversion is liable to result in ODR problems. On the other hand, the errors are pretty horrendous right now.
I am not sure how ODR applies here. But I guess a compile time check will
have the same limitations are the conversion itself. After all in the same
way the constructor
quantity1(q2) is defined, so should be an hypothetical
is_convertible
This is a fairly common problem. Could you file a trac ticket. I'll try to make the error more readable.
sure, https://svn.boost.org/trac/boost/ticket/4988
A better error message will help a lot in this and other contexts but think
it is a different issue with respect to the is_convertible

AMDG On 12/15/2010 11:10 AM, alfC wrote:
The ability to test for a conversion is liable to result in ODR problems. On the other hand, the errors are pretty horrendous right now. I am not sure how ODR applies here.
is_convertible would depend on which headers are #included. This makes ODR violations really easy.
But I guess a compile time check will have the same limitations are the conversion itself. After all in the same way the constructor
quantity1(q2) is defined, so should be an hypothetical is_convertible
::static_value. Just a though: for example, can the BOOST_UNITS_DEFINE_CONVERSION_FACTOR add some kind of is_convertible trait at the same time? (I know, it won't be useful for derived conversions).
In Christ, Steven Watanabe

The ability to test for a conversion is liable to result in ODR problems. On the other hand, the errors are pretty horrendous right now. I am not sure how ODR applies here.
is_convertible would depend on which headers are #included. This makes ODR violations really easy.
We could, however, make is_convertible mean "potentially convertible" by just verifying that the dimensions are consistent...then there is no ODR problem, it just doesn't guarantee that the conversion is defined even though it is possible. Matthias
participants (3)
-
alfC
-
Matthias Schabel
-
Steven Watanabe