Closed jbbjarnason closed 1 month ago
This is "by design" just because I can't think of an use case where you need different numeric types for different quantities. Do you have such a use case?
Previously in cpp, we had typed inter process communication abstraction with support for Voltage, Current, Temperature etc. Everything was transported as signed integer with fixed precision, but in business logic it was often useful to use double for different business logic.
Why did you choose different numeric types for "transport" and business logic?
Only because I could have full control of signed integers with fixed precision, for example nano meter or such, so I would control rounding and truncating fully before transmit.
This is not a hard requirement on my side so I can change the cpp code to double and use double then on everything.
This issue can be closed.
Ok. Closing this issue.
hey again @mamrhein
I remembered a use case which we heavily used from C++ mp units.
We wrote a EtherCat driver (communication to physical devices) for frequency inverter(motor controller) where we could reflect the configuration parameters of the frequency inverter in C++. For example:
// ATV320 specific data type and multiplier for unit
using decifrequency = mp_units::quantity<mp_units::si::deci<mp_units::si::hertz>, uint16_t>;
using decifrequency_signed = mp_units::quantity<mp_units::si::deci<mp_units::si::hertz>, int16_t>;
using decawatt = mp_units::quantity<mp_units::si::deca<mp_units::si::watt>, uint16_t>;
using atv_deciampere_rep = mp_units::quantity<mp_units::si::deci<mp_units::si::ampere>, uint16_t>;
Here at compile time the sizeof and signedness is strictly set for each type, which 100% reflects to the configuration(from the devices manual) of the frequency inverter. So when we serialize the configuration to the device we make no changes to the type.
This however also relies on strict Unit
which I believe is runtime in this library.
Is this something you would like this library to support?
I'm not sure whether I do understand what would be required here. To support different types for the numeric part of a quantity would mean to make AmountT a type parameter of each quantity struct. This would definitely be a breaking change. So, I'd like to avoid that unless there is a very strong demand.
Coming from cpp using
mp-units
https://github.com/mpusz/mp-units the quantity amount type was templated on quantity level, so each instance of quantity could adjust its representative type, in your library AmountT.For reference, from their cpp code
As far as I understand your library the AmountT is globally set, so for different units the same AmountT is used.
Was this a design decision made to begin with or is this something that could be defined on
trait Quantity
level? Or am I misunderstanding the whole thing.