[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<class Dimension, class LeftSystem, class RightSystem> quantity< unit<Dimension, LeftSystem> > sum_to_left( quantity< unit<Dimension, LeftSystem> > const& qleft, quantity< unit<Dimension, RightSystem> > const& qright ){ return boost::units::operator + (qleft, quantity< unit<Dimension, LeftSystem> >(qright)); } Thank you, Alfredo
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<class Dimension, class LeftSystem, class RightSystem> quantity< unit<Dimension, LeftSystem> > sum_to_left( quantity< unit<Dimension, LeftSystem> > const& qleft, quantity< unit<Dimension, RightSystem> > const& qright ){ return boost::units::operator + (qleft, quantity< unit<Dimension, LeftSystem> >(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<quantity1, quantity2>::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).
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<quantity1, quantity2> feature. Thank you, Alfredo
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<quantity1, quantity2>::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 (4)
-
alfC -
Matthias Schabel -
Steven Watanabe