Closed NAThompson closed 9 months ago
The link doesn't look right.
@JohelEGP : Just checked it, but nonetheless here's the full code:
#include <mp-units/systems/si/si.h>
#include <cmath>
#include <limits>
using namespace mp_units;
using namespace mp_units::si::unit_symbols;
namespace mp_units {
template<auto R, typename Rep>
[[nodiscard]] constexpr bool isfinite(const quantity<R, Rep>& a) noexcept
requires
(requires {
isfinite(a.numerical_value_ref_in(a.unit));
} || requires {
std::isfinite(a.numerical_value_ref_in(a.unit));
})
{
using std::isfinite;
return isfinite(a.numerical_value_ref_in(a.unit));
}
}
#include <cassert>
int main() {
constexpr auto t = 3.0*m;
assert(isfinite(t));
assert(!isfinite(std::numeric_limits<double>::quiet_NaN()*s));
assert(!isfinite(std::numeric_limits<decltype(t)>::quiet_NaN()));
}
Sorry, I just looked at the wrong tab.
Looks good to me 😃
The above code is perfectly fine.
Just a question for my education/curiosity about where C++ is heading to: I know overloading std::
templates with user-defined specialisations is frowned upon ...
Having said this ... does this mean that one will have to define all possible math operations and combinations in -- for example -- the namespace mp_units
? That's going to be a lot of wrapper-style boilerplate code if one adds e.g. uncertainties, linear algebra, covariance matrices, w/ & w/o the std::complex<...>
data types, etc... just to be able to write consistent formulas regardless of whether they are simple/unconstraint fundamental types (e.g. scalars/gain)), unit-constraint types, etc. :thinking:
The beauty of the operator*(...)
is that one can define and call upon them in and from any namespace as long as the specialisation knows about the user type.
There must be a better solution hiding somewhere...
There must be a better solution hiding somewhere...
Not in C++23.
This is why we use:
using std::isfinite;
return isfinite(a.numerical_value_ref_in(a.unit));
This allows the user to provide isfinite
for the uncertainty type and use it as a representation type with quantity. In my talks, I already said that all math functions should become CPOs to simplify interoperability between various numeric libraries.
Thanks, @JohelEGP and @mpusz, for the info and the confirmation. Keep up the good work! :+1:
godbolt for potential implementation.
Example use case: