```
test\unit_test\runtime\magnitude_test.cpp(143): error C2672:
'units::check_same_type_and_value': no matching overloaded function
found
```
Maybe it's confused by accessing the static member variable template
using dot-notation on an _instance_? If so, let's see how it likes the
member-function syntax.
For each Magnitude `m`, we now support:
- `is_rational(m)` tells whether it represents a rational number.
- `is_integral(m)` tells whether it represents an integer (and
`is_integral(m)` implies `is_rational(m)`).
- `m.value<T>` represents the value of `m` in the type `T`.
If `T` is integral, we only support `m.value<T>` when `is_integral(m)`.
We also perform all intermediate computations in the widest type of the
same category (floating point, signed, or unsigned). This means we can,
for example, give first-class support to embedded users who may have
hardware support only for `float`: we can ensure they get the most
accurate `float` value we can compute, without burdening them with a
dependency on `long double` in their runtime code.
We are not yet ready to replace `ratio` as the definition of unit
magnitudes, but we're a step closer. The next step will be to decompose
a Magnitude into numerator, denominator, and irrational parts, giving us
full bidirectional convertibility with existing `ratio` instances. Then
we can migrate over in a controlled fashion.
The motivation for the `mag` sub-namespace was to distinguish something
like `mag::product_t<...>` from `dim::product_t<...>`, based on the
idioms of Aurora Units. However, we have no need for a `product_t` type
trait, since we can just use `operator*()`, so we can eliminate this
sub-namespace.
The new test actually passed without modifying the code. However, that
might be implementation-dependent (presumably based on canonicalization
of the `ratio` template parameter), so I wanted a more obviously correct
implementation.
Now References can be disabled to meassure a compile time impact. Also the same examples are now provided in two subdirectories to be able to easily compare the pros and cons of every quantity construction technique.
Chip Hogg
Markus Hofbauer
Mateusz Pusz