True/False (Default: automatically determined from settings)
Configures CMake to add C++ modules to the list of default targets.
+import_std 2.3.0 · True/False (Default: automatically determined from settings)
Enables import std; usage.
std_format 2.2.0 · True/False (Default: automatically determined from settings)
ON/OFF (Default: OFF)
Adds C++ modules to the list of default targets.
MP_UNITS_BUILD_IMPORT_STD 2.3.0 · ON/OFF (Default: OFF)
Enables import std; usage.
MP_UNITS_API_STD_FORMAT 2.2.0 · ON/OFF (Default: automatically determined)
mp-units is a compile-time enabled feature-rich Modern C++ modular/header-only library that provides compile-time dimensional analysis and unit/quantity manipulation. Its key strengths include safety, performance, and developer experience.
The library source code is hosted on GitHub with a permissive MIT license.
Supported compilersThis library tries to provide the best user experience possible with the C++ language. To achieve that, it extensively uses the latest C++ language features.
Even though the library benefits from the latest C++ versions (if available), C++20 is enough to compile and use all of the library's functionality.
Please refer to C++ compiler support chapter for more details.
C++ modulesHeader files#include <iostream>\n#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\ninline constexpr struct smoot final : named_unit<\"smoot\", mag<67> * usc::inch> {} smoot;\n\nint main()\n{\n constexpr quantity dist = 364.4 * smoot;\n std::println(\"Harvard Bridge length = {::N[.1f]} ({::N[.1f]}, {::N[.2f]}) \u00b1 1 \u03b5ar\",\n dist, dist.in(usc::foot), dist.in(si::metre));\n}\n#include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <mp-units/systems/usc.h>\n#include <print>\n\nusing namespace mp_units;\n\ninline constexpr struct smoot final : named_unit<\"smoot\", mag<67> * usc::inch> {} smoot;\n\nint main()\n{\n constexpr quantity dist = 364.4 * smoot;\n std::println(\"Harvard Bridge length = {::N[.1f]} ({::N[.1f]}, {::N[.2f]}) \u00b1 1 \u03b5ar\",\n dist, dist.in(usc::foot), dist.in(si::metre));\n}\nOutput:
Harvard Bridge length = 364.4 smoot (2034.6 ft, 620.14 m) \u00b1 1 \u03b5ar\nTry it on Compiler Explorer
What issmoot? The smoot (/\u02c8smu\u02d0t/) is a nonstandard unit of length created as part of an MIT fraternity prank. It is named after Oliver R. Smoot, a fraternity pledge to Lambda Chi Alpha, who, in October 1958, lay on the Harvard Bridge (between Boston and Cambridge, Massachusetts) and was used by his fraternity brothers to measure the length of the bridge.
One smoot equals Oliver Smoot's height at the time of the prank (five feet and seven inches). The bridge's length was measured to be 364.4 smoots plus or minus one ear, with the \"plus or minus\" intended to express the measurement uncertainty.
Oliver Smoot graduated from MIT with the class of 1962, became a lawyer, and later became chairman of the American National Standards Institute (ANSI) and president of the International Organization for Standardization (ISO).
More on the smoot unit of length can be found at https://en.wikipedia.org/wiki/Smoot.
Important: Help needed!
The mp-units library might be the subject of ISO standardization for C++29. More on this can be found in the following ISO C++ proposals:
We are actively looking for parties interested in field-trialing the library.
"},{"location":"release_notes/","title":"Release Notes","text":""},{"location":"release_notes/#mp-units","title":"mp-units","text":""},{"location":"release_notes/#2.3.0","title":"2.3.0 WIP","text":"delta and absolute construction helpershas_unit_symbol support removedcore.h removedfinalfma, isfinite, isinf, and isnan math function added by @NAThompsonfma for quantity points addedquantity_point support added for quantity_cast and value_castvalue_cast<Unit, Representation> addedvalue_cast<Quantity>(q), value_cast<Quantity>(qp) and value_cast<QuantityPoint>(qp) added by @burnpanckinterconvertible(QuantitySpec, QuantitySpec) addedqp.quantity_from_zero() addedvalue_type type trait addedpercent or per_milleppm parts per million added by @nebkatatan2 2-argument arctangent added by @nebkatfmod floating-point division remainder added by @nebkatremainder IEEE division remainder added by @nebkatstd::format support added() in references, prefixes, and kind_ofzero_Fahrenheit renamed to zeroth_degree_Fahrenheitsi subnamespacemath.h header file broke up to smaller piecesfixed_string interface refactoredReferenceOf does not take a dimension anymoreunit_symbol_solidus::one_denominatorget_kind() now returns kind_ofcompat_macros.hfixed_string refactored to reflect the latest changes to P3094R2basic_symbol_text renamed to symbol_textratio hidden as an implementation detail behind mag_ratioframework.h introducedabsolute_point_origin does not use CRTP anymorefinalsi_quantities.h added to improve compile-timesvalidate_ascii_string refactored to is_basic_literal_character_setunderlying_type split to wrapped_type and value_type and used in code<ranges> header and switch to use an iterator-based copy algorithmterminate replaced with abort and a header file addedstd::remove_const_t removed and some replaced with the GCC-specific workaroundremove_reference_t and remove_cvref_t removedquantity and quantity_point are now hidden friendsQuantityLike conversions required Q::rep instead of using one provided by quantity_like_traitsQuantitySpec[Unit] replaced with make_reference in value_castice_point is now defined with the integral offset from absolute_zerosudo_cast fixedversion header file added to hacks.hquantity_cast to accept lvalue references (thanks @burnpanck)value_cast with lvalue references to quantity_point (thanks @burnpanck)smoot unit example added to the main pageMP_UNITS_AS_SYSTEM_HEADERS renamed to MP_UNITS_BUILD_AS_SYSTEM_HEADERSMP_UNITS_BUILD_LA and MP_UNITS_IWYU CMake options now have _DEV_ in the namecheck_cxx_feature_supported addedCMAKE_EXPORT_COMPILE_COMMANDS flag enabled for the developer's buildgenerate() now set cache_variablescan_run check added before running testsclang-tidy CI addedthis parameter support fixedinverse() support added for dimensions, quantity_spec, units, and references (1 / s will now create quantity and not a Unit)quantity_point does not provide zero() anymorequantity_spec and its kind should not compare equalfixed_stringcommon_type with a raw value is not needed anymore as for a long time now raw values are not convertible to the dimensionless quantitiessymbol_text definition simplifiedbasic_fixed_string(const CharT*, std::integral_constant<std::size_t, N>) constructor addedisq::activity added and becquerel definition updated to benefit from itgray and sievert now have correct associated quantity kindsUnitCompatibleWith concept added and applied to in(U) and force_in(U) functionsMagnitude / Unit operator addedderived_dimension)zero_Fahrenheit point origin addedunit_symbol<fmt>(U) signature refactored and the resulting text can now also be used at runtimemake_xxx factory functions replaced with two-parameter constructorsunit_symbol changed to constevalin(U) and force_in(U) now return auto to provide better diagnostics on clangquantity operators constraints refactoredfixed_string definitionunit_symbol_formatting enums now use std::int8_t as a representation typeunit_symbolCommonlyInvocableQuantities was overconstrained for the current library designare_ingredients_convertible now mandates explicit conversion for To dimensionless quantitiesquantity_point::point_for(PO) constraints fixedlatitude and longitude fixed to include 0 for N and E respectivelyCameCase concept identifiers FAQ addedgravitational_potential_energy equation fixed on a graphunits namespace renamed to mp_units (#317)<mp-units/...> rather then in <units/...> (#317)quantity_point (#414)quantity_spec to store not only dimension but also additional information about quantities (#405)quantity now takes reference object, which aggregates quantity_spec and a unit and a representation typefmtquantity_kind removed.in(Unit), .force_in(Unit) for quantity and quantity_spec.numerical_value_in(Unit) and .force_numerical_value_in(Unit)quantity can no longer be constructed with a raw value (#434)quantity_point can no longer be constructed with just a quantity and an explicit PointOrigin is always neededceil and floor are dangerous (#432)common_quantity, common_quantity_for, common_quantity_point, common_quantity_kind, and common_quantity_point_kind removednamed_derived_unit removed as it was not usedderived_unit renamed to derived_scaled_unitunit renamed to derived_unitU::is_named removed from the unit types and replaced with NamedUnit conceptPrefixFamily support removedmi(naut) renamed to nmiknot unit helper renamed to kn in FPSknot text symbol changed from \"knot\" to \"kn\"quantity op+() and op-() reimplemented in terms of reference rather then quantity typesglide_computer now use dimensionless quantities with ranged_representation as repfloor(), ceil(), and round() support added (thanks @hofbi)std::format support for compliant compilers addedmp-units to std::chrono types addedquantity_point to std::chrono::time_point addednautical_mile_per_hour and knot added to si::international systemquantity_point::origin, like std::chrono::time_point::clockhectare definition fixed to be a prefixed version of are + other unitsquantity_point_cast's constraintfmt algorithms were overconstrained with forward_iteratorderived_ratio calculationfill_t assignment operator fixedradioactivity header compilation fixedsi::hep::dim_momentum duplicated definition fixedfps can now coexist with international systemCMAKE_BUILD_TYPE in the conan_toolchain.cmake anymoreconanfile.py refactored to be Conan 2.0 readyvalidate() replaced with configure() to raise errors during conan install in Conan 1.Xlinear-algebra Conan repo is no needed anymoremp-units-systemCITATION.cff file addedCONTRIBUTING.md updatedScalableNumber renamed to Representationunits/quantity_io.h header filequantity::count() renamed to quantity::number()data system renamed to isq::iec80000 (quantity names renamed too)*deduced_unit renamed to *derived_unitnoble_derived_unitquantityquantity and quantity_cast refactoredabs() definition refactored to be more explicit about the return typestd::chrono::duration and other units librariesmodulation_rate support added (thanks @go2sh)isq::iec80000 support added (thanks @go2sh)UNITS_NO_LITERALS preprocessor definequantity_cast() generates less assembly instructionsquantity::op<<()equivalent trait usageexp() has sense only for dimensionless quantitiesdim_torque now properly divides by an angle (instead of multiply) + default unit name changequantity_cast() fixed to work correctly with representation types not convertible from std::intmax_tfoot_pound_force and foot_pound_force_per_secondBUILD_DOCS CMake option renamed to UNITS_BUILD_DOCScmake_find_package_multiquantity_point support added (thanks @johelegp)si::angular_velocity support added (thanks @mikeford3)exp(quantity)q_* UDL renamed to _q_**p* to *_per_*ratio changed to the NTTP kindexp and Exp renamed to exponent and ExponentScalar concept renamed to ScalableNumberquantity typemath.h function signatures refactored to use a Quantity concept (thanks @kwikius)[[nodiscard]] added to many functionssi::day unit symbol fixed to d (thanks @komputerwiz)si::mole unit symbol fixed to mol (thanks @mikeford3)ratio refactored to contain Exp template parameter (thanks a lot @oschonrock!)q_ prefix applied to all the UDLs (thanks @kwikius)unknown_unit renamed to unknown_coherent_unitstd::experimental::math support addedalias_unit (thanks @yasamoka)physical namespaceMany thanks to GitHub users @oschonrock, @kwikius, and @i-ky for their support in drafting a new library design.
"},{"location":"release_notes/#0.4.0","title":"0.4.0 Nov 17, 2019","text":"exp addedpow() and sqrt() operations on quantitiesunits removed from a std::experimental namespacebase_dimension class templatebase_dimension and derived unitsoperator<< on quantityfmt support addedupcasting_traits renamed to downcasting_traitsDimension template parameter removed from quantityunits moved to a std::experimental namespacemeter renamed to metreoperator* addeddimension_ prefix removed from names of derived dimensionsbase_dimension is a value provided as const& to the exp typeQuantityOf concept introducedquantity_cast<U, Rep>() support addedstd::remove_cvref_t, down with typename, std::type_identity)type_list, common_ratio, ratio, conditional_t)Note
The ISO terms provided below are only a few of many defined in the ISO/IEC Guide 99.
quantity kind of quantity, kind system of quantities base quantity derived quantity International System of Quantities, ISQ quantity dimension, dimension of a quantity, dimension Symbols representing the dimensions of the base quantities in the ISQ are:
Base quantity Symbol for dimension length \\(\\mathsf{L}\\) mass \\(\\mathsf{M}\\) time \\(\\mathsf{T}\\) electric current \\(\\mathsf{I}\\) thermodynamic temperature \\(\\mathsf{\u0398}\\) amount of substance \\(\\mathsf{N}\\) luminous intensity \\(\\mathsf{J}\\)Thus, the dimension of a quantity \\(Q\\) is denoted by \\(\\textsf{dim }Q = \\mathsf{L}^\u03b1\\mathsf{M}^\u03b2\\mathsf{T}^\u03b3\\mathsf{I}^\u03b4\\mathsf{\u0398}^\u03b5\\mathsf{N}^\u03b6\\mathsf{J}^\u03b7\\) where the exponents, named dimensional exponents, are positive, negative, or zero.
quantity of dimension one, dimensionless quantity measurement unit, unit of measurement, unit base unit derived unit coherent derived unit system of units coherent system of units off-system measurement unit, off-system unit International System of Units, SI quantity value, value of a quantity, value numerical quantity value, numerical value of a quantity, numerical value quantity equation unit equation numerical value equation, numerical quantity value equation Info
The below terms extend the official ISO glossary and are commonly referred to by the mp-units library.
base dimension derived dimension dimension equation quantity kind hierarchy, quantity hierarchy quantity character, character of a quantity, character ISO 80000-1_2009
In deriving the dimension of a quantity, no account is taken of its scalar, vector, or tensor character.
quantity specification, quantity_spec unit with an associated quantity, associated unit quantity reference, reference canonical representation of a unit, canonical unit reference unit See canonical representation of a unit
absolute quantity point origin, absolute point origin relative quantity point origin, relative point origin quantity point origin, point origin quantity point, absolute quantity ISO80000 ISO 80000-1:2009(E) \"Quantities and units \u2014 Part 1: General\", International Organization for Standardization.
Quincey \"Angles in the SI: a detailed proposal for solving the problem, Quincey, Paul (1 October 2021). SIBrochure The International System of Units (SI), International Bureau of Weights and Measures (20 May 2019), ISBN 978-92-822-2272-0.
"},{"location":"blog/","title":"Blog","text":""},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/","title":"What's new in mp-units 2.0?","text":"After a year of hard work, we've just released mp-units 2.0.0. It can be obtained from GitHub and Conan.
The list of the most significant changes introduced by the new version can be found in our Release Notes. We will also describe some of them in this post.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#why-20-if-10-was-never-released","title":"Why 2.0 if 1.0 was never released?","text":"Version 2 of the mp-units project is a huge change and a new quality for the users. We did not want to pretend that 2.0 is an evolutionary upgrade of the previous version of the project. It feels like a different product.
We could start a new repo named \"mp-units-v2\" similarly to range-v3 but we decided not to go this path. We kept the same repo and made the scope of the changes and potential breakage explicit with a drastic bump in the project version.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#what-has-changed","title":"What has changed?","text":"The answer is \"nearly everything\". The whole library and its documentation were rewritten nearly from scratch.
Here are the significant changes that the users can observe:
Repository name
If you didn't notice, the repository name was changed from \"mpusz/units\" to \"mpusz/mp-units\".
Header files content and layout
Previously, all the header files resided in the include/units directory. Now, they can be found in include/mp-units. The project file tree was significantly changed as well. Many files were moved to different subdirectories or renamed.
Namespace
Previously, all the definitions were provided in the units namespace, and now they are in the mp_units one.
Abstractions, interfaces, definitions
The interfaces of all of the types were refactored. We got unit symbols and a new way to construct a quantity and quantity_point. The readability of the generated types was improved thanks to the introduction of expression templates. Nearly all of the template arguments are now passed by values thanks to class NTTP extensions in C++20. As a result, unit definitions are much easier and terser. Also, the V2 has a powerful ability to model systems of quantities and provides definitions for many ISQ quantities.
Conan 2.0
Also, now we support Conan 2.0, which provides an updated way of handling dependencies.
Some cornerstones of the initial design did not prove in practice and were removed while we moved to version 2.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#the-downcasting-facility","title":"The downcasting facility","text":"The first and the most important of such features was removing the downcasting facility. This feature is still a powerful metaprogramming technique that allows users to map long class template instantiations to nicely named, short, and easy-to-understand user's strong types.
Such mapping works perfectly fine for 1-to-1 relationships. However, we often deal with N-to-1 connections in the quantities and units domain. Here are only a few such examples:
In the above examples, multiple entities \"wanted\" to register different names for identical class template instantiations, resulting in compile-time errors. We had to invent some hacks and workarounds to make it work, but we were never satisfied with the outcome.
Additionally, this facility could easily lead to ODR violations or provide different results depending on which header files were included in the translation units. This was too vulnerable to be considered a good practice here.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#no-udls-anymore","title":"No UDLs anymore","text":"Over the years, we have learned that UDLs are not a good solution. More information on this subject can be found in the Why don't we use UDLs to create quantities? chapter.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#no-construction-of-a-quantity-from-a-raw-value","title":"No construction of aquantity from a raw value","text":"To improve safety, we no longer allow the construction of quantities from raw values. In the new design, we always need to explicitly specify a unit to create a quantity:
quantity q1 = 42 * m;\nquantity<si::metre> = 2 * km;\nquantity q3(42, si::metre);\nThe previous approach was reported to be error-prone under maintenance. More on this subject can be found in the Why can't I create a quantity by passing a number to a constructor? chapter.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#new-look-and-feel","title":"New look and feel","text":"Here is a concise example showing you the new look and feel of the library:
#include <mp-units/format.h>\n#include <mp-units/systems/isq/isq.h>\n#include <mp-units/systems/si/si.h>\n#include <format>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity<isq::speed[m / s]> avg_speed(quantity<si::metre> d,\n quantity<si::second> t)\n{ return d / t; }\n\nint main()\n{\n auto speed = avg_speed(220 * km, 2 * h);\n std::println(\"{}\", speed); // 30.5556 m/s\n}\nAll of the changes we provided, although breaking ones, resulted in much better, easier, and safer abstractions. These offer a new quantity on the market and hopefully will be appreciated by our users.
Please check our new documentation to learn about the latest version of the project and find out how to benefit from all the new cool stuff we have here.
"},{"location":"blog/2023/12/09/mp-units-210-released/","title":"mp-units 2.1.0 released!","text":"A new product version can be obtained from GitHub and Conan.
The list of the most significant changes introduced by the new version can be found in our Release Notes. We will also describe the most important of them in this post.
"},{"location":"blog/2023/12/09/mp-units-210-released/#no-more-parenthesis-while-creating-quantities-with-derived-units","title":"No more parenthesis while creating quantities with derived units","text":"The V2 design introduced a way to create a quantity by multiplying a raw value and a unit:
quantity q1 = 42 * m;\nHowever, this meant that when we wanted to create a quantity having a derived unit, we had to put parenthesis around the unit equation or create a custom value of the named unit:
quantity q2 = 60 * (km / h);\n\nconstexpr auto kmph = km / h;\nquantity q3 = 60 * kmph;\n\nquantity q4 = 50 * (1 / s);\nWith the new version, we removed this restriction, and now we can type:
quantity q5 = 60 * km / h;\nquantity q6 = 50 / s;\nAs a side effect, we introduced a breaking change . We can't use the following definition of hertz anymore:
inline constexpr struct hertz : named_unit<\"Hz\", 1 / second, kind_of<isq::frequency>> {} hertz;\nand have to type either:
inline constexpr struct hertz : named_unit<\"Hz\", one / second, kind_of<isq::frequency>> {} hertz;\nor
inline constexpr struct hertz : named_unit<\"Hz\", inverse(second), kind_of<isq::frequency>> {} hertz;\nTo be consistent, we applied the same change to the dimensions and quantity specifications definitions. Now, to define a frequency we have to type:
C++23C++20Portableinline constexpr struct frequency : quantity_spec<inverse(period_duration)> {} frequency;\ninline constexpr struct frequency : quantity_spec<frequency, inverse(period_duration)> {} frequency;\nQUANTITY_SPEC(frequency, inverse(period_duration));\nmake_xxx factory functions replaced with two-parameter constructors","text":"In the initial version of the V2 framework, if someone did not like the multiply syntax to create a quantity we provided the make_quantity() factory function. A similar approach was used for quantity_point creation.
This version removes those ( breaking change ) and introduces two parameter constructors:
quantity q(42, si::metre);\nquantity_point qp(q, mean_sea_level);\nThe above change encourages a better design and results in a terser code.
"},{"location":"blog/2023/12/09/mp-units-210-released/#improved-definitions-of-becquerel-gray-and-sievert","title":"Improved definitions of becquerel, gray, and sievert","text":"In the initial V2 version, we lacked the definitions of the atomic and nuclear physics quantities, which resulted in simplified and unsafe definitions of becquerel, gray, and sievert units. We still do not model most of the quantities from this domain, but we've added the ones that are necessary for the definition of those units.
Thanks to the above, the following expressions will not compile:
quantity q1 = 1 * Hz + 1 * Bq;\nquantity<si::sievert> q2 = 42 * Gy;\nAnother significant improvement in this version was redesigning the way we provide compatibility with other similar libraries. The interfaces of quantity_like_traits and quantity_point_like_traits were changed and extended to provide conversion not only from but also to entities from other libraries ( breaking change ).
We've also introduced an innovative approach that allows us to specify if such conversions should happen implicitly or if they need to be forced explicitly.
More on this subject can be found in the Interoperability with Other Libraries chapter.
"},{"location":"blog/2023/12/09/mp-units-210-released/#point-origins-can-now-be-derived-from-each-other","title":"Point origins can now be derived from each other","text":"Previously, each class derived from absolute_point_origin was considered a unique independent point origin. On the other hand, it was OK to derive multiple classes from the same relative_point_origin, and those were specifying the same point in the domain. We found this confusing and limiting. This is why, in this version, the absolute_point_origin uses a CRTP idiom to be able to detect between points that should be considered different from the ones that should be equivalent.
If we derive from the same instantiation of absolute_point_origin we end up with an equivalent point origin. This change allows us to provide different names for the same temperature points:
inline constexpr struct absolute_zero : absolute_point_origin<absolute_zero, isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr struct zeroth_kelvin : decltype(absolute_zero) {} zeroth_kelvin;\n\ninline constexpr struct ice_point : relative_point_origin<absolute_zero + 273.15 * kelvin> {} ice_point;\ninline constexpr struct zeroth_degree_Celsius : decltype(ice_point) {} zeroth_degree_Celsius;\nPlease note that this is a breaking change as well.
"},{"location":"blog/2023/12/09/mp-units-210-released/#unit-symbol-text-can-now-be-properly-used-at-runtime","title":"Unit symbol text can now be properly used at runtime","text":"The interface of the previous definition of unit_symbol function allowed the use of the returned buffer only at compile-time. This was too limiting as users often want to use unit symbols at runtime (e.g., print them to the console). The new version redesigned the interface of this function ( breaking change ) to return a buffer that can be properly used at both compilation and runtime:
std::string_view unit1 = unit_symbol(m / s);\nstd::cout << unit1 << \"\\n\"; // m/s\nstd::string_view unit2 = unit_symbol<{.solidus = unit_symbol_solidus::never}>(m / s);\nstd::cout << unit2 << \"\\n\"; // m s\u207b\u00b9\nA new product version can be obtained from GitHub and Conan.
Among other features, this release provides long-awaited support for C++20 modules, redesigns and enhances text output formatting, and greatly simplifies quantity point usage. This post describes those and a few other smaller interesting improvements, while a much longer list of the most significant changes introduced by the new version can be found in our Release Notes.
"},{"location":"blog/2024/06/14/mp-units-220-released/#c20-modules-and-project-structure-cleanup","title":"C++20 modules and project structure cleanup","text":"GitHub Issue #7 was our oldest open issue before this release. Not anymore. After 4.5 years, we finally closed it, even though the C++ modules' support is still really limited.
Info
To benefit from C++ modules, we need at least:
In the upcoming months, hopefully, the situation will improve with the bug fixes in CMake, gcc-14, and MSVC.
Note
More requirements for C++ modules support can be found in the CMake's documentation.
To enable the compilation and distribution of C++ modules, a cxx_modules Conan or MP_UNITS_BUILD_CXX_MODULES CMake option has to be enabled.
With the above, the following C++ modules will be provided:
flowchart TD\n mp_units --- mp_units.systems --- mp_units.coremp_units.core mp-units::core Core library framework and systems-independent utilities mp_units.systems mp-units::systems All the systems of quantities and units mp_units mp-units::mp-units Core + Systems The easiest way to use them is just to import mp_units; at the beginning of your translation unit (see the Quick Start chapter for some usage examples).
Note
C++20 modules support still have some issues when imported from the installed CMake target. See the following GitLab issue for more details.
In this release, we also highly limited the number of CMake targets ( breaking change ). Now, they correspond exactly to the C++ modules they provide. This means that many smaller partial targets were removed. We also merged text output targets with the core library's definition.
The table below specifies where we can now find the contents of previously available CMake targets:
Before Nowmp-units::utility mp-units::core mp-units::core-io mp-units::core mp-units::core-fmt mp-units::core mp-units::{system_name} mp-units::systems While we were enabling C++ modules, we also had to refactor our header files slightly ( breaking change ). Some had to be split into smaller pieces (e.g., math.h), while others had to be moved to a different subdirectory (e.g., chrono.h).
In version 2.2, the following headers have a new location or contents:
Header File C++ Module Contents mp-units/math.hmp_units.core System-independent functions only mp-units/systems/si/math.h mp_units.systems Trigonometric functions using si::radian mp-units/systems/angular/math.h mp_units.systems Trigonometric functions using angular::radian mp-units/systems/si/chrono.h mp_units.systems std::chrono compatibility traits Benefiting from this opportunity, we also cleaned up core and systems definitions ( breaking change ).
Regarding the library's core, we removed core.h and exposed only one header framework.h that provides all of the library's framework so the user does not have to enumerate files like unit.h, quantity.h, and quantity_point.h anymore. Those headers are not gone, they were put to the mp-units/framework subheader. So they are still there if you really need them.
Regarding the changes in systems definitions, we moved the wrapper header files with the entire system definition to the mp-units/systems subdirectory. Additionally, they now also include framework.h, so a system include is enough to use the library. Thanks to that our users don't have to write tedious code like the below anymore:
#include <mp-units/systems/cgs.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n\n// ...\n#include <mp-units/quantity_point.h>\n#include <mp-units/systems/cgs/cgs.h>\n#include <mp-units/systems/international/international.h>\n#include <mp-units/systems/isq/isq.h>\n#include <mp-units/systems/si/si.h>\n\n// ...\nAdditionally, we merged all of the compatibility-related macros into one header file mp-units/compat_macros.h. This header file should be explicitly included before importing C++ modules if we want to benefit from the Wide Compatibility tools.
With this release, nearly all of the Conan and CMake build options were refactored with the intent of providing better control over the library's API.
Previously, the library used the latest available feature set supported by a specific compiler. For example, quantity_spec definitions would use CRTP on an older compiler or provide a simpler API on a newer one thanks to the C++23 this deduction feature. This could lead to surprising results where the same code written by the user would compile fine on one compiler but not the other.
From this release, all API extensions have their corresponding configuration options in Conan and CMake. With this, a user has full control over the API exposed by the library. Those options expose three values:
True - The feature is always enabled (the configuration error will happen if the compiler does not support this feature)False - The feature is disabled, and an older alternative is always used.Auto - The feature is automatically enabled if the compiler supports it (old behavior).Additionally, some CMake options were renamed to better express the impact on our users ( breaking change ). For example, now CMake options include:
MP_UNITS_API_* - options affecting the library's API,MP_UNITS_BUILD_* - options affecting the build process,MP_UNITS_DEV_* - options primarily useful for the project developers or people who want to compile our unit tests and examples.Before this release, the library always depended on gsl-lite to perform runtime contract and asserts checking. In this release we introduced new options to control if contract checking should be based on gsl-lite, ms-gsl, or may be completely disabled.
"},{"location":"blog/2024/06/14/mp-units-220-released/#freestanding-support","title":"Freestanding support","text":"From this release it is possible to configure the library in the freestanding mode. This limits the functionality and interface of the library to be compatible with the freestanding implementations.
Info
To learn more, please refer to the Build options chapter.
"},{"location":"blog/2024/06/14/mp-units-220-released/#simplified-quantity-point-support","title":"Simplified quantity point support","text":"This release significantly simplifies the usage of quantity points and affine space abstractions in general.
Previously, the user always had to define an explicit point origin even if the domain being modeled does not have such an explicit origin. Now, in such cases, we can benefit from the implicit point origins. For example:
NowBeforequantity_point price_usd{100 * USD};\nconstexpr struct zero final : absolute_point_origin<currency> {} zero;\n\nquantity_point price_usd = zero + 100 * USD;\nAs we can see above, the new design allows direct-initializing quantity_point class template from a quantity, but only if the former one is defined in terms of the implicit point origin. Otherwise, an explicit origin still always has to be provided during initialization.
Also, we introduced the possibility of specifying a default point origin in the unit definition. With that, we could provide proper temperature scales without forcing the user to always use the origins explicitly. Also, a new member function, .quantity_from_zero(), was introduced that always returns the quantity from the unit's specific point origin or from the implicit point origin otherwise.
quantity_point temp{20 * deg_C};\nstd::cout << \"Temperature: \" << temp << \" (\"\n << temp.in(deg_F).quantity_from_zero() << \", \"\n << temp.in(K).quantity_from_zero() << \")\\n\";\nquantity_point temp = si::zeroth_degree_Celsius + 20 * deg_C;\nstd::cout << \"Temperature: \" << temp << \" (\"\n << temp.in(deg_F).quantity_from(usc::zeroth_degree_Fahrenheit) << \", \"\n << temp.in(K).quantity_from(si::zeroth_kelvin) << \")\\n\";\nMore information about the new design can be found in The Affine Space chapter.
"},{"location":"blog/2024/06/14/mp-units-220-released/#unified-temperature-point-origins-names","title":"Unified temperature point origins names","text":"By omission, we had the following temperature point origins in the library:
si::zero_kelvin (for si::kelvin),si::zeroth_degree_Celsius (for si::degree_Celsius),usc::zero_Fahrenheit (for usc::degree_Fahrenheit).With this release, the last one was renamed to usc::zeroth_degree_Fahrenheit to be consistently named with its corresponding unit and with the si::zeroth_degree_Celsius ( breaking change ).
There were several known issues when units were deriving from each other (e.g., #512 and #537). We could either highly complicate the framework to allow these which could result in much longer compilation times or disallow inheriting from units at all. We chose the second option.
With this release all of of the units must be marked as final. To enforce this we have changed the definition of the Unit<T> concept, which now requires type T to be final ( breaking change ).
WG21 Study Group 16 (Unicode) raised concerns about potential ABI issues when different translation units are compiled with different ordinary literal encodings. Those issues were resolved with a change to units definitions ( breaking change ). It affects only units that specify both Unicode and ASCII symbols. The new design requires the Unicode symbol to be provided as a UTF-8 literal.
This also means that the basic_symbol_text has fixed character types for both symbols. This is why it was renamed to symbol_text ( breaking change ).
inline constexpr struct ohm final : named_unit<symbol_text{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\ninline constexpr struct ohm : named_unit<basic_symbol_text{\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\nNote
On C++20-compliant compilers it should be enough to type the following in the unit's definition:
inline constexpr struct ohm final : named_unit<{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\nSimilarly to units, now also all dimensions, quantity specifications, and point origins have to be marked final ( breaking change ).
inline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct length final : quantity_spec<dim_length> {} length;\n\ninline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr auto zeroth_kelvin = absolute_zero;\ninline constexpr struct kelvin final : named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\n\ninline constexpr struct ice_point final : relative_point_origin<quantity_point{273'150 * milli<kelvin>}> {} ice_point;\ninline constexpr auto zeroth_degree_Celsius = ice_point;\ninline constexpr struct degree_Celsius final : named_unit<symbol_text{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\ninline constexpr struct dim_length : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct length : quantity_spec<dim_length> {} length;\n\ninline constexpr struct absolute_zero : absolute_point_origin<absolute_zero, isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr struct zeroth_kelvin : decltype(absolute_zero) {} zeroth_kelvin;\ninline constexpr struct kelvin : named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\n\ninline constexpr struct ice_point : relative_point_origin<quantity_point{273'150 * milli<kelvin>}> {} ice_point;\ninline constexpr struct zeroth_degree_Celsius : decltype(ice_point) {} zeroth_degree_Celsius;\ninline constexpr struct degree_Celsius : named_unit<symbol_text{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\nPlease also note, that the absolute_point_origin does not use CRTP idiom anymore ( breaking change ).
With this release, we can print not only whole quantities but also just their units or dimensions. Also, we fixed the std::format support so users can now enjoy full C++20 compatibility and don't have to use fmtlib anymore.
We have also changed the grammar for quantities formatting ( breaking change ). It introduces the composition of underlying formatters that finally allows us to properly format user-defined representation types (assuming they have std::format support). Additionally, thanks to a new %? token, we can provide a custom format string that will properly print quantity of any unit.
Here is a small preview of what is now available:
using namespace mp_units::si::unit_symbols;\nusing namespace mp_units::international::unit_symbols;\nquantity q = (90. * km / h).in(mph);\n\nstd::cout << \"Number: \" << q.numerical_value_in(mph) << \"\\n\";\nstd::cout << \"Unit: \" << q.unit << \"\\n\";\nstd::cout << \"Dimension: \" << q.dimension << \"\\n\";\nstd::println(\"{::N[.2f]}\", q);\nstd::println(\"{:.4f} in {} of {}\", q.numerical_value_in(mph), q.unit, q.dimension);\nstd::println(\"{:%N in %U of %D:N[.4f]}\", q);\nNumber: 55.9234\nUnit: mi/h\nDimension: LT\u207b\u00b9\n55.92 mi/h\n55.9234 in mi/h of LT\u207b\u00b9\n55.9234 in mi/h of LT\u207b\u00b9\nMore on this subject can be found in the updated Text Output chapter.
"},{"location":"blog/2024/06/14/mp-units-220-released/#improved-casts","title":"Improved casts","text":"We added a new conversion function. value_cast<Unit, Representation> forces the conversion of both a unit and representation type in one step and always ensures that the best precision is provided.
Also, we have finally added proper implementations of value_cast and quantity_cast for quantity points.
This release made a few small refactorings that, without changing the user-facing API, allowed us to improve the readability of the generated types that can be observed in the compilation errors.
Example 1 (clang):
NowBeforeerror: no matching function for call to 'time_to_goal'\n 26 | const quantity ttg = time_to_goal(half_marathon_distance, pace);\n | ^~~~~~~~~~~~\nnote: candidate template ignored: constraints not satisfied [with distance:auto = quantity<kilo_<metre>{}, double>,\n speed:auto = quantity<derived_unit<second, per<kilo_<metre>>>{}, double>]\n 13 | QuantityOf<isq::time> auto time_to_goal(QuantityOf<isq::length> auto distance,\n | ^\nnote: because 'QuantityOf<quantity<derived_unit<si::second, per<si::kilo_<si::metre> > >{{{}}}>, isq::speed>' evaluated to false\n 14 | QuantityOf<isq::speed> auto speed)\n | ^\nnote: because 'QuantitySpecOf<std::remove_const_t<decltype(quantity<derived_unit<second, per<kilo_<metre> > >{{{}}}, double>::quantity_spec)>, struct speed{{{}}}>' evaluated to false\n 61 | concept QuantityOf = Quantity<Q> && QuantitySpecOf<std::remove_const_t<decltype(Q::quantity_spec)>, QS>;\n | ^\nnote: because 'implicitly_convertible(kind_of_<derived_quantity_spec<isq::time, per<isq::length> > >{}, struct speed{{{}}})' evaluated to false\n 147 | QuantitySpec<T> && QuantitySpec<decltype(QS)> && implicitly_convertible(T{}, QS) &&\n | ^\n1 error generated.\nCompiler returned: 1\nerror: no matching function for call to 'time_to_goal'\n 26 | const quantity ttg = time_to_goal(half_marathon_distance, pace);\n | ^~~~~~~~~~~~\nnote: candidate template ignored: constraints not satisfied [with distance:auto = quantity<kilo_<metre{{}}>{}, double>,\n speed:auto = quantity<derived_unit<second, per<kilo_<metre{{}}>>>{}, double>]\n 13 | QuantityOf<isq::time> auto time_to_goal(QuantityOf<isq::length> auto distance,\n | ^\nnote: because 'QuantityOf<quantity<derived_unit<si::second, per<si::kilo_<si::metre{{}}> > >{{{}}}>, isq::speed>' evaluated to false\n 14 | QuantityOf<isq::speed> auto speed)\n | ^\nnote: because 'QuantitySpecOf<std::remove_const_t<decltype(quantity<derived_unit<second, per<kilo_<metre{{}}> > >{{{}}}, double>::quantity_spec)>, struct speed{{{}}}>' evaluated to false\n 61 | concept QuantityOf = Quantity<Q> && QuantitySpecOf<std::remove_const_t<decltype(Q::quantity_spec)>, QS>;\n | ^\nnote: because 'implicitly_convertible(kind_of_<derived_quantity_spec<isq::time, per<isq::length> >{{}, {{}}}>{}, struct speed{{{}}})' evaluated to false\n 147 | QuantitySpec<T> && QuantitySpec<decltype(QS)> && implicitly_convertible(T{}, QS) &&\n | ^\n1 error generated.\nCompiler returned: 1\nExample 2 (gcc):
NowBeforeerror: no matching function for call to 'Box::Box(quantity<reference<isq::height, si::metre>(), int>, quantity<reference<horizontal_length, si::metre>(), int>,\n quantity<reference<isq::width, si::metre>(), int>)'\n 27 | Box my_box(isq::height(1 * m), horizontal_length(2 * m), isq::width(3 * m));\n | ^\nnote: candidate: 'Box::Box(quantity<reference<horizontal_length, si::metre>()>, quantity<reference<isq::width, si::metre>()>,\n quantity<reference<isq::height, si::metre>()>)'\n 19 | Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n | ^~~\nnote: no known conversion for argument 1 from 'quantity<reference<isq::height, si::metre>(),int>'\n to 'quantity<reference<horizontal_length, si::metre>(),double>'\n 19 | Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^\nerror: no matching function for call to 'Box::Box(quantity<reference<isq::height(), si::metre()>(), int>, quantity<reference<horizontal_length(), si::metre()>(), int>,\n quantity<reference<isq::width(), si::metre()>(), int>)'\n 27 | Box my_box(isq::height(1 * m), horizontal_length(2 * m), isq::width(3 * m));\n | ^\nnote: candidate: 'Box::Box(quantity<reference<horizontal_length(), si::metre()>()>, quantity<reference<isq::width(), si::metre()>()>,\n quantity<reference<isq::height(), si::metre()>()>)'\n 19 | Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n | ^~~\nnote: no known conversion for argument 1 from 'quantity<reference<isq::height(), si::metre()>(),int>'\n to 'quantity<reference<horizontal_length(), si::metre()>(),double>'\n 19 | Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^\nThis release provided lots of changes to the mp_units/math.h header file.
First, we got several outstanding contributions:
fma, isfinite, isinf, and isnan math functions were added by @NAThompson,ppm, atan2, fmod, and remainder were added by @nebkat.Thanks!
Additionally, we changed the namespace for trigonometric functions using SI units. Now they are inside of the mp_units::si subnamespace and not in mp_units::isq like it was the case before ( breaking change ).
Also, the header itself was split into smaller pieces that improve C++20 modules definitions.
"},{"location":"blog/2024/06/14/mp-units-220-released/#ratio-made-an-implementation-detail-of-the-library","title":"ratio made an implementation detail of the library","text":"We decided not to expose ratio and associated interfaces in the public part of the library ( breaking change ). Standardization of it could be problematic as we have std::ratio already.
Alternatively, as in the public interface it was always only used with mag, we introduced a new helper called mag_ratio to provide the magnitude of the unit defined in terms of a rational conversion factor. Here is a comparison of the code with previous and current definitions:
inline constexpr struct yard final : named_unit<\"yd\", mag_ratio<9'144, 10'000> * si::metre> {} yard;\ninline constexpr struct foot final : named_unit<\"ft\", mag_ratio<1, 3> * yard> {} foot;\ninline constexpr struct yard : named_unit<\"yd\", mag<ratio{9'144, 10'000}> * si::metre> {} yard;\ninline constexpr struct foot : named_unit<\"ft\", mag<ratio{1, 3}> * yard> {} foot;\nSeveral groups in the ISO C++ Committee reviewed the P1935: A C++ Approach to Physical Units proposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potential standardization of such a library and encouraged further work. The authors also got valuable initial feedback that highly influenced the design of the V2 version of the mp-units library.
In the following years, we scoped on getting more feedback from the production and design. This resulted in version 2 of the mp-units library that resolved many issues the users and Committee members raised. The features and interfaces of this version are close to being the best we can get with the current version of the C++ language standard.
We submitted three new proposals related to the standardization of the quantities and units library for the last ISO C++ Committee meeting:
std::quantity as a numeric type.Those were reviewed and briefly discussed in several groups: Numerics (SG6), Safety & Security (SG23), and Library Evolution Working Group (LEWG). Most of the feedback was positive, and the Committee is interested in spending more time on such proposals.
The following poll was taken by the LEWG:
LEWG POLL: Given that our time is limited, more time should be promised for a quantities and units library
Strongly in Favor In favor Neutral Against Strongly Against 10 13 4 0 0Attendance: 22 + 6
Number of Authors: 4
Authors\u2019 position: 4x SF
Outcome: Strong consensus in favor
Additionally, some concerns were raised about the large scope of the proposal. We were encouraged to return with more details and design rationale in a unified paper. This is what we are working on now for the next Committee meeting that will happen in mid-March 2024 in Tokyo.
"},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/","title":"Report from the St. Louis 2024 ISO C++ Committee meeting","text":"We made significant progress in the standardization of this library during the ISO C++ Committee meeting in St. Louis.
"},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/#p30942r3-stdbasic_fixed_string","title":"P30942R3:std::basic_fixed_string","text":"First, the fixed_string was unanimously forwarded from the SG18 LEWG Incubator to the Library Evolution Working Group (LEWG). The group suggested a few minor changes to the paper, which resulted in the R3 version of the proposal.
The paper is in excellent shape, and the entire wording is ready as well. Hopefully it will progress quickly through the remaining groups in the Committee.
"},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/#p3045r1-quantities-and-units-library","title":"P3045R1: Quantities and units library","text":"In the SG6 (Numerics), we had a really efficient discussion about the recently raised usability issues with temperatures and the Minimal Viable Product (MVP) scope.
The following polls were taken:
POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, and quantity kinds. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
Strongly in Favor In favor Neutral Against Strongly Against 7 4 7 0 0POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, quantity kinds, and quantities of the same kind. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
Strongly in Favor In favor Neutral Against Strongly Against 5 2 5 2 0POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, quantity kinds, and affine spaces. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
Strongly in Favor In favor Neutral Against Strongly Against 5 0 8 1 0As we can see, there are no controversies about the first poll that states that the MVP should include at least:
The next polls add either:
quantity_point).SG6 considered those less important, but no one was strongly against including those in the MVP. We were asked to return with better motivation and usage examples for those features.
If you are depending on quantities of the same kind or quantity points in your project and you would like to see them in the std library, please let us know about your use cases.
Besides SG6, we spent six hours in the SG18 LEWG Incubator discussing the details of the library design. The proposal was very well received, and we got a few valuable comments and suggestions that we will apply to the next version of the paper.
"},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/","title":"Report from the Tokyo 2024 ISO C++ Committee meeting","text":"The Tokyo 2024 meeting was a very important step in the standardization of this library. Several WG21 groups reviewed proposals, and the feedback was really good.
"},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/#p3045r0-quantities-and-units-library","title":"P3045R0: Quantities and units library","text":"The Study Group 6 (Numerics) discussed the proposal for several hours. The initial feedback was positive. There were some concerns related to the description and design of the affine space abstractions in the library. Besides that, the people in the room liked what they saw.
We run a few polls in SG6 as well:
POLL: The syntax number * unit is the right solution for constructing quantities. Not allowing reordering the operands is correct.
POLL: Not defining any UDLs is the right solution.
No objection to unanimous consent.
The paper was also briefly discussed in SG18 LEWG Incubator, and the initial feedback was also positive. No polls were taken.
SG16 Unicode does not meet during ISO C++ Committee F2F meetings. Still, the text output chapter paper was also reviewed by it during an online meeting before Tokyo. We got good feedback and are expected to return with the updated version. No polls were taken.
"},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/#p30942r1-stdbasic_fixed_string","title":"P30942R1:std::basic_fixed_string","text":"In the SG18 LEWG Incubator, before we started to talk about P3045R0, we spent a few hours discussing the design of the std::basic_fixed_string, which is proposed for C++26. The group gave excellent feedback, and if the R2 version addresses it properly, the paper is expected to progress to LEWG (Library Evolution Working Group) in St. Louis.
Plenty of polls were taken:
POLL: We should promise more committee time to pursuing std::basic_fixed_string, knowing that our time is scarce and this will leave less time for other work.
POLL: Should the constructor from a string literal be consteval?
POLL: Do we want to add .view()?
POLL: Do we want the .size member to be an integral_constant<size_t, N> (and .empty to be bool_constant<N==0>)?
POLL: Should the index operator[] return a reference to const?
POLL: Should the constructor from a string literal have a precondition that txt[N] == 0?
Info
mp-units library tries to provide the best user experience possible with the C++ language. To achieve that, it extensively uses the latest C++ language features.
Even though the library benefits from the latest C++ versions (if available), C++20 is enough to compile and use all of the library's functionality. Newer features can be hidden behind some preprocessor macros providing a backward-compatible way to use them.
The table below provides the minimum compiler version required to compile the code using a specific C++ feature:
C++ Feature C++ version gcc clang apple-clang MSVC Minimum support 20 12 16 15 Nonestd::format 20 13 17 None None C++ modules 20 None 17 None None Static constexpr variables in constexpr functions 23 13 17 None None Explicit this parameter 23 14 18 None None Important
Enabling/disabling features listed above may influence the API of the library and the ABI of the customers' projects.
"},{"location":"getting_started/cpp_compiler_support/#stdformat","title":"std::format","text":"std::format yet (even when the compiler supports it).__cpp_lib_format feature test macro.Note
More requirements for C++ modules support can be found in the CMake's documentation.
"},{"location":"getting_started/cpp_compiler_support/#static-constexpr-variables-in-constexpr-functions","title":"Staticconstexpr variables in constexpr functions","text":"std::string_view from the unit_symbol() and dimension_symbol() functionsstd::string_view type has a reference semantics so it has to point to a storage with a longer lifetime.mp_units::basic_fixed_string<CharT, N> instead.__cpp_constexpr >= 202211L feature test macro.this parameter","text":"quantity_spec definitions.__cpp_explicit_this_parameter feature test macro.metre instead of meter?","text":"This is how the BIPM defines it in the SI Brochure (British English spelling by default).
"},{"location":"getting_started/faq/#why-dont-we-use-udls-to-create-quantities","title":"Why don't we use UDLs to create quantities?","text":"Many reasons make UDLs a poor choice for a physical units library:
Typical implementations of UDLs tend to always use the widest representation type available. In the case of std::chrono::duration, the following is true:
using namespace std::chrono_literals;\nauto d1 = 42s;\nauto d2 = 42.s;\nstatic_assert(std::is_same_v<decltype(d1)::rep, std::int64_t>);\nstatic_assert(std::is_same_v<decltype(d2)::rep, long double>);\nWhen such UDL is intermixed in arithmetics with any quantity type of a shorter representation type, it will always expand it to the longest one. In other words, such long type spreads until all types use it everywhere.
While increasing the coverage for the library, we learned that many unit symbols conflict with built-in types or numeric extensions. A few of those are: F (farad), J (joule), W (watt), K (kelvin), d (day), l or L (litre), erg, ergps. Usage of the _ prefix would make it work for mp-units, but in case the library is standardized, those naming collisions would be a big issue. This is why we came up with the _q_ prefix that would become q_ after standardization (e.g., 42q_s), which is not that nice anymore.
UDLs with the same identifiers defined in different namespace can't be disambiguated in the C++ language. If both SI and CGS systems define _q_s UDL for a second unit, then it would not be possible to specify which one to use in case both namespaces are \"imported\" with using directives.
Another bad property of UDLs is that they do not compose. A coherent unit of angular momentum would have a UDL specified as _q_kg_m2_per_s. Now imagine that we want to make every possible user happy. How many variations of that unit would we predefine for differently scaled versions of all unit ingredients?
UDLs are also really expensive to define and specify. Typically, for each unit, we need two definitions. One for integral and another one for floating-point representation. Before the V2 framework, the coherent unit of angular momentum was defined as:
constexpr auto operator\"\" _q_kg_m2_per_s(unsigned long long l)\n{\n gsl_Expects(std::in_range<std::int64_t>(l));\n return angular_momentum<kilogram_metre_sq_per_second, std::int64_t>(static_cast<std::int64_t>(l));\n}\n\nconstexpr auto operator\"\" _q_kg_m2_per_s(long double l)\n{\n return angular_momentum<kilogram_metre_sq_per_second, long double>(l);\n}\nA quantity class template in the mp-units library has no publicly available constructor taking a raw value. Such support is provided by the std::chrono::duration and was pointed out to us as a red flag safety issue by a few parties already.
Consider the following structure and a code using it:
struct X {\n std::vector<std::chrono::milliseconds> vec;\n // ...\n};\nX x;\nx.vec.emplace_back(42);\nEverything works fine for years until, at some point, someone changes the structure to:
struct X {\n std::vector<std::chrono::microseconds> vec;\n // ...\n};\nThe code continues to compile just fine, but all the calculations are off now. This is why we decided to not follow this path.
In the mp-units library, both a number and a unit have to always be explicitly provided in order to form a quantity.
Note
The same applies to the construction of quantity_point using an explicit point origin. To prevent similar safety issues during maintenance, the initialization always requires providing both a quantity and a PointOrigin that we use as a reference point.
In the initial design of this library, the resulting type of division of two quantities was their common representation type:
static_assert(std::is_same_v<decltype(10 * km / (5 * km)), int>);\nFirst of all, this was consistent with std::chrono::duration behavior. Additional reasoning behind it was not providing a false impression of a strong quantity type for something that looks and feels like a regular number. Also, all of the mathematic and trigonometric functions were working fine out of the box with such representation types, so we did not have to rewrite sin(), cos(), exp(), and others.
However, the feedback we got from the production usage was that such an approach is really bad for generic programming. It is hard to handle the result of the two quantities' division (or multiplication) as it might be either a quantity or a fundamental type. If we want to raise such a result to some power, we must use units::pow or std::pow depending on the resulting type. Those are only a few issues related to such an approach.
Moreover, suppose we divide quantities of the same dimension but with units of significantly different magnitudes. In that case, we may end up with a really small or a huge floating-point value, which may result in losing lots of precision. Returning a dimensionless quantity from such cases allows us to benefit from all the properties of scaled units and is consistent with the rest of the library.
Note
More information on the current design can be found in the Dimensionless Quantities chapter.
"},{"location":"getting_started/faq/#why-do-the-identifiers-for-concepts-in-the-library-use-camelcase","title":"Why do the identifiers for concepts in the library useCamelCase?","text":"Initially, C++20 was meant to use CamelCase for all the concept identifiers. All the concepts from the std::ranges library were merged with such names into the standard document draft. Frustratingly, CamelCase concepts got dropped from the C++ standard at the last moment before releasing C++20. Now, we are facing the predictable consequences of running out of names.
As long as some concepts in the library could be easily named with a standard_case there are some that are hard to distinguish from the corresponding type names, such as Quantity, QuantityPoint, QuantitySpec, or Reference. This is why we decided to use CamelCase consistently for all the concept identifiers to make it clear when we are talking about a type or concept identifier.
However, we are aware that this might be a temporary solution. In case the library gets standardized, we can expect the ISO C++ Committee to bikeshed/rename all of the concept identifiers to a standard_case, even if it will result in a harder to understand code.
Note
In case you have a good idea of how to rename existing concepts to the standard_case, please let us know in the associated GitHub Issue.
Both C++ and ISO 80000 are standardized by the ISO. ISO 80000 and the SI standards specify Unicode symbols as the official unit names for some quantities (e.g. \u03a9 symbol for the resistance quantity). As the mp-units library will be proposed for standardization as a part of the C++ Standard Library we have to obey the rules and be consistent with ISO specifications.
Note
We do understand engineering reality and the constraints of some environments. This is why the library has the option of ASCII-only Quantity Symbols.
"},{"location":"getting_started/faq/#why-dont-we-have-cmake-options-to-disable-the-building-of-tests-and-examples","title":"Why don't we have CMake options to disable the building of tests and examples?","text":"Over time, many people provided PRs proposing adding options to build tests and examples conditionally. Here are a few examples:
We admit this is a common practice in the industry, but we also believe this is a bad pattern.
First, the only need for such options comes when a user wants to use add_subdirectory() in CMake to handle dependencies. Such an approach does not scale and should be discouraged. There is little use for such a practice in times when we have dedicated package managers like Conan.
The second thing is that our observation is that many people are fixed on disabling \"unneeded\" subdirectories from compilation, but they do not see or address the biggest issue, which is polluting user's build environment with our development-specific settings. Propagating our restrictive compilation flags to user's project is not the best idea as it might cause a lot of harm if this project stops to compile because of that.
Last but not least, not having those options is on purpose. Top level CMakeLists.txt file should only be used by mp-units developers and contributors as an entry point for the project's development. We want to ensure that everyone will build ALL the code correctly before pushing a commit. Having such options would allow unintended issues to leak to PRs and CI.
This is why our projects have two entry points:
add_subdirectory() to handle the dependencies.Note
For more details on this please refer to the CMake + Conan: 3 Years Later - Mateusz Pusz lecture that Mateusz Pusz provided at the C++Now 2021 conference.
"},{"location":"getting_started/installation_and_usage/","title":"Installation And Usage","text":"This chapter provides all the necessary information to obtain and build the code using mp-units. It also describes how to build or distribute the library and generate its documentation.
"},{"location":"getting_started/installation_and_usage/#project-structure","title":"Project structure","text":""},{"location":"getting_started/installation_and_usage/#repository-directory-tree-and-dependencies","title":"Repository directory tree and dependencies","text":"The GitHub repository contains three independent CMake-based projects:
./src
in case this library becomes part of the C++ standard, it will have no external dependencies but until then, it depends on the following:
std::format is not supported yet on a specific compiler)..
additionally to the dependencies of ./src project, it uses:
./test_package
Important: Library users should not use the top-level CMake file
Top level CMakeLists.txt file should only be used by mp-units developers and contributors as an entry point for the project's development. We want to ensure that everyone will build ALL the code correctly before pushing a commit. Having such options would allow unintended issues to leak to PRs and CI.
This is why our projects have two entry points:
add_subdirectory() to handle the dependencies.To learn more about the rationale, please check our FAQ.
"},{"location":"getting_started/installation_and_usage/#modules","title":"Modules","text":"The mp-units library provides the following C++ modules:
flowchart TD\n mp_units --- mp_units.systems --- mp_units.coremp_units.core mp-units::core Core library framework and systems-independent utilities mp_units.systems mp-units::systems All the systems of quantities and units mp_units mp-units::mp-units Core + Systems Note
C++ modules are provided within the package only when:
cxx_modules Conan option is set to True,MP_UNITS_BUILD_CXX_MODULES CMake option is set to ON.All of the project's header files can be found in the mp-units/... subdirectory.
mp-units/framework.h contains the entire library's framework definitions,mp-units/concepts.h exposes only the library's concepts for generic code needs,mp-units/format.h provides text formatting support,mp-units/ostream.h enables streaming of the library's objects to the text output,mp-units/math.h provides overloads of common math functions for quantities,mp-units/random.h provides C++ pseudo-random number generators for quantities,mp-units/compat_macros.h provides macros for wide compatibility.More detailed header files can be found in subfolders which typically should not be included by the end users:
mp-units/framework/... provides all the public interfaces of the framework,mp-units/bits/... provides private implementation details only (no public definitions),mp-units/ext/... contains external dependencies that at some point in the future should be replaced with C++ standard library facilities.The systems definitions can be found in the mp-units/systems/... subdirectory:
mp-units/systems/isq.h provides International System of Quantities (ISQ) definitions,mp-units/systems/isq.h might be expensive to compile in every translation unit. There are some smaller, domain targeted files available for explicit inclusion in the mp-units/systems/isq/... subdirectory.
mp-units/systems/si.h provides International System of Units (SI) definitions and associated math functions,mp-units/systems/angular.h provides strong angular units and associated math functions,mp-units/systems/international.h provides international yard and pound units,mp-units/systems/imperial.h includes international.h and extends it with imperial units,mp-units/systems/usc.h includes international.h and extends it with United States customary system of units,mp-units/systems/cgs.h provides centimetre-gram-second system of units,mp-units/systems/iau.h provides astronomical system of units,mp-units/systems/hep.h provides units used in high-energy physics,mp-units/systems/typographic.h provides units used in typography or typesetting,mp-units/systems/natural.h provides an example implementation of natural units.mp-units/systems/si.h might be expensive to compile in every translation unit. There are some smaller files available for explicit inclusion in the mp-units/systems/si/... subdirectory.
mp-units/systems/si/unit_symbols.h is the most expensive to include.
This library assumes that most of the dependencies will be provided by the Conan Package Manager. If you want to obtain required dependencies by other means, some modifications to the library's CMake files might be needed. The rest of the dependencies responsible for documentation generation are provided by python3-pip.
In case you are not familiar with Conan, to install it (or upgrade) just do:
pip install -U conan\nAfter that, you might need to add a custom profile file for your development environment in ~/.conan2/profiles directory. An example profile can look as follows:
~/.conan2/profiles/gcc12[settings]\narch=x86_64\nbuild_type=Release\ncompiler=gcc\ncompiler.cppstd=20\ncompiler.libcxx=libstdc++11\ncompiler.version=12\nos=Linux\n\n[conf]\ntools.build:compiler_executables={\"c\": \"gcc-12\", \"cpp\": \"g++-12\"}\nSetting the language version
Please note that the mp-units library requires at least C++20 to be set in a Conan profile or forced via the Conan command line. If we do the former, we will not need to provide -s compiler.cppstd=20 every time we run a Conan command line (as provided in the command line instructions below).
Using Ninja as a CMake generator for Conan
It is highly recommended to set Ninja as a CMake generator for Conan. To do so, we should create a ~/.conan2/global.conf file that will set tools.cmake.cmaketoolchain:generator to one of the Ninja generators. For example:
tools.cmake.cmaketoolchain:generator=\"Ninja Multi-Config\"\nSeparate build folders for different configurations
~/.conan2/global.conf file may also set tools.cmake.cmake_layout:build_folder_vars which makes working with several compilers or build configurations easier. For example, the below line will force Conan to generate separate CMake presets and folders for each compiler and C++ standard version:
tools.cmake.cmake_layout:build_folder_vars=[\"settings.compiler\", \"settings.compiler.version\", \"settings.compiler.cppstd\"]\nIn such a case, we will need to use a configuration-specific preset name in the Conan instructions provided below rather than just conan-default and conan-release (e.g. conan-gcc-13-23 and conan-gcc-13-23-release)
Note
Most of the below options are related to the C++ language features available in the compilers. Please refer to the C++ compiler support chapter to learn more about which C++ features are required and which compiler support them.
"},{"location":"getting_started/installation_and_usage/#conan-options","title":"Conan options","text":"cxx_modules 2.2.0 \u00b7 True/False (Default: automatically determined from settings)
Configures CMake to add C++ modules to the list of default targets.
std_format 2.2.0 \u00b7 True/False (Default: automatically determined from settings)
Enables the usage of std::format and associated facilities for text formatting. If it is not supported, then the {fmt} library is used instead.
string_view_ret 2.2.0 \u00b7 True/False (Default: automatically determined from settings)
Enables returning std::string_view from the unit_symbol() and dimension_symbol() functions. If this feature is not available, those functions will return mp_units::basic_fixed_string<CharT, N> instead.
no_crtp 2.2.0 \u00b7 True/False (Default: automatically determined from settings)
Removes the need for the usage of the CRTP idiom in the quantity_spec definitions.
contracts 2.2.0 \u00b7 none/gsl-lite/ms-gsl (Default: gsl-lite)
Enables checking of preconditions and additional asserts in the code.
freestanding 2.2.0 \u00b7 True/False (Default: False)
Configures the library in the freestanding mode. When enabled, the library's source code should build with the compiler's -ffreestanding compilation option without any issues.
user.mp-units.build:all 2.2.0 \u00b7 True/False (Default: False)
Enables compilation of all the source code, including tests and examples. To support this, it requires some additional Conan build dependencies described in Repository directory tree and dependencies. It also runs unit tests during Conan build (unless tools.build:skip_test configuration property is set to True).
user.mp-units.build:skip_la 2.2.0 \u00b7 True/False (Default: True)
If user.mp-units.build:all is enabled, among others, Conan installs the external wg21-linear_algebra dependency and enables the compilation of linear algebra-based tests and usage examples. Such behavior can be disabled with this option.
user.mp-units.analyze:clang-tidy 2.2.0 \u00b7 True/False (Default: False)
Enables clang-tidy analysis.
"},{"location":"getting_started/installation_and_usage/#cmake-options","title":"CMake options","text":"MP_UNITS_BUILD_AS_SYSTEM_HEADERS 2.2.0 \u00b7 ON/OFF (Default: OFF)
Exports library as system headers.
MP_UNITS_BUILD_CXX_MODULES 2.2.0 \u00b7 ON/OFF (Default: OFF)
Adds C++ modules to the list of default targets.
MP_UNITS_API_STD_FORMAT 2.2.0 \u00b7 ON/OFF (Default: automatically determined)
Enables the usage of std::format and associated facilities for text formatting. If it is not supported, then the {fmt} library is used instead.
MP_UNITS_API_STRING_VIEW_RET 2.2.0 \u00b7 ON/OFF (Default: automatically determined)
Enables returning std::string_view from the unit_symbol() and dimension_symbol() functions. If this feature is not available, those functions will return mp_units::basic_fixed_string<CharT, N> instead.
MP_UNITS_API_NO_CRTP 2.2.0 \u00b7 ON/OFF (Default: automatically determined)
Removes the need for the usage of the CRTP idiom in the quantity_spec definitions.
MP_UNITS_API_CONTRACTS 2.2.0 \u00b7 NONE/GSL-LITE/MS-GSL (Default: GSL-LITE)
Enables checking of preconditions and additional asserts in the code.
MP_UNITS_API_FREESTANDING 2.2.0 \u00b7 ON/OFF (Default: OFF)
Configures the library in the freestanding mode. When enabled, the library's source code should build with the compiler's -ffreestanding compilation option without any issues.
MP_UNITS_DEV_BUILD_LA 2.2.0 \u00b7 ON/OFF (Default: ON)
Enables building code depending on the linear algebra library.
MP_UNITS_DEV_IWYU 2.2.0 \u00b7 ON/OFF (Default: OFF)
Enables include-what-you-use analysis.
MP_UNITS_DEV_CLANG_TIDY 2.2.0 \u00b7 ON/OFF (Default: OFF)
Enables clang-tidy analysis.
"},{"location":"getting_started/installation_and_usage/#cmake-with-presets-support","title":"CMake with presets support","text":"It is recommended to use at least CMake 3.23 to build this project as this version introduced support for CMake Presets schema version 4, used now by Conan to generate presets files. All build instructions below assume that you have such support. If not, your CMake invocations have to be replaced with something like:
mkdir build && cd build\ncmake .. -G \"Ninja Multi-Config\" -DCMAKE_TOOLCHAIN_FILE=<path_to_generators_dir>/conan_toolchain.cmake\ncmake --build . --config Release\nTip
In case you can't use CMake 3.23 but you have access to CMake 3.20 or later, you can append -c tools.cmake.cmaketoolchain.presets:max_schema_version=2 to the conan install command which will force Conan to use an older version of the CMake Presets schema.
There are many different ways of installing/reusing mp-units in your project. Below we mention only a few of many options possible.
Important: Prefer using Conan if possible
The easiest and most recommended way to obtain mp-units is with the Conan package manager. See Conan + CMake (release) for a detailed instruction.
"},{"location":"getting_started/installation_and_usage/#copy","title":"Copy","text":"As mp-units is a C++ header-only library you can simply copy all needed src/*/include subdirectories to your source tree.
Note
In such a case, you are on your own to ensure all the dependencies are installed and their header files can be located during the build. Please also note that some compiler-specific flags are needed to make the code compile without issues.
"},{"location":"getting_started/installation_and_usage/#copy-cmake","title":"Copy + CMake","text":"If you copy the whole mp-units repository to your project's file tree, you can reuse CMake targets defined by the library. To do so, you should use CMakeLists.txt file from the ./src directory:
add_subdirectory(<path_to_units_folder>/src)\n# ...\ntarget_link_libraries(<your_target> <PUBLIC|PRIVATE|INTERFACE> mp-units::mp-units)\nNote
You are still on your own to make sure all the dependencies are installed and their header and CMake configuration files can be located during the build.
"},{"location":"getting_started/installation_and_usage/#conan-cmake-release","title":"Conan + CMake (release)","text":"Tip
If you are new to the Conan package manager, it is highly recommended to read Obtaining Dependencies and refer to Consuming packages chapter of the official Conan documentation for more information.
mp-units releases are hosted on Conan-Center. The following steps may be performed to obtain an official library release:
Create Conan configuration file (either conanfile.txt or conanfile.py) in your project's top-level directory and add mp-units as a dependency of your project. For example, the simplest file may look as follows:
conanfile.txt[requires]\nmp-units/2.2.0\n\n[options]\nmp-units:cxx_modules=True\n\n[layout]\ncmake_layout\n\n[generators]\nCMakeToolchain\nCMakeDeps\nImport mp-units and its dependencies definitions to your project's build procedure with find_package:
find_package(mp-units REQUIRED)\nLink your CMake targets with mp-units:
target_link_libraries(<your_target> <PUBLIC|PRIVATE|INTERFACE> mp-units::mp-units)\nDownload, build, and install Conan dependencies before running the CMake configuration step:
conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing\ncmake --preset conan-default\ncmake --build --preset conan-release\nThis chapter describes the procedure to Live At Head, which means using the latest stable version of mp-units all the time.
Note
Please note that even though the Conan packages that you will be using are generated ONLY for builds that are considered stable (passed our CI tests), some minor regressions may happen (our CI and C++20 build environment is not perfect yet). Also, please expect that the library interface might, and probably will, change occasionally. Even though we do our best, such changes might not be reflected in the project's documentation right away.
The procedure is similar to the one described in Conan + CMake (release) with the following differences:
Before starting the previous procedure, add mp-units remote to your Conan configuration:
conan remote add conan-mpusz https://mpusz.jfrog.io/artifactory/api/conan/conan-oss\nIn your Conan configuration file, provide the package identifier of the mpusz/testing stream:
[requires]\nmp-units/2.3.0@mpusz/testing\n\n[options]\nmp-units:cxx_modules=True\n\n[layout]\ncmake_layout\n\n[generators]\nCMakeToolchain\nCMakeDeps\nTip
The identifiers of the latest packages can always be found in the project's README file or on the project's Artifactory.
Force Conan to check for updated recipes with -u:
conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing -u\nIn case you don't want to use Conan in your project and just want to install the mp-units library on your file system and use find_package(mp-units) from another repository to find it; it is enough to perform the following steps:
conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing\nmv CMakeUserPresets.json src\ncd src\ncmake --preset conan-default -DCMAKE_INSTALL_PREFIX=<your_installation_path>\ncmake --build --preset conan-release --target install\nIn case you would like to build all the mp-units source code (with unit tests and examples), you should:
user.mp-units.build:all = True.git clone https://github.com/mpusz/mp-units.git && cd units\nconan build . -pr <your_conan_profile> -s compiler.cppstd=23 -o '&:cxx_modules=True' -c user.mp-units.build:all=True -b missing\nThe above will download and install all of the dependencies needed for the development of the library, build all of the source code, and run unit tests.
If you prefer to build the project via CMake rather than Conan, then you should replace the conan build with conan install command and then follow with a regular CMake build:
cmake --preset conan-default\ncmake --build --preset conan-release\ncmake --build --preset conan-release --target all_verify_interface_header_sets\ncmake --build --preset conan-release --target test\nStarting from mp-units 2.0 we are using Material for MkDocs to build our documentation. The easiest way to install all the required dependencies is with pip:
pip install -U mkdocs-material mkdocs-rss-plugin\nAdditionally, a Cairo Graphics library is required by Material for MkDocs. Please follow the official MkDocs documentation to install it.
After that, you can either:
easily start a live server to preview the documentation as you write
mkdocs serve\nbuild the documentation
mkdocs build\nTo test CMake installation and Conan packaging or create a Conan package run:
conan create . --user <username> --channel <channel> -pr <your_conan_profile> -s compiler.cppstd=20 -o '&:cxx_modules=True' -c user.mp-units.build:all=True -b missing\nThe above will create a Conan package and run tests provided in ./test_package directory.
"},{"location":"getting_started/installation_and_usage/#uploading-mp-units-package-to-the-conan-server","title":"Uploading mp-units package to the Conan server","text":"conan upload -r <remote-name> --all mp-units/2.2.0@<user>/<channel>\nmp-units is a Modern C++ library that provides compile-time dimensional analysis and unit/quantity manipulation. The initial versions of the library were inspired by the std::chrono::duration but with each release, the interfaces diverged from the original to provide a better user experience.
Info
A brief introduction to the library's interfaces and the rationale for changes in version 2.0 of mp-units were provided in detail by Mateusz Pusz in the \"The Power of C++ Templates With mp-units: Lessons Learned & a New Library Design\" talk at the C++ on Sea 2023 conference.
"},{"location":"getting_started/introduction/#open-source","title":"Open Source","text":"mp-units is Free and Open Source, with a permissive MIT license. Check out the source code and issue tracking (for questions and support, reporting bugs, suggesting feature requests and improvements) at https://github.com/mpusz/mp-units.
"},{"location":"getting_started/introduction/#with-the-users-experience-in-mind","title":"With the User's Experience in Mind","text":"Most of the critical design decisions in the library are dictated by the requirement of providing the best user experience possible. Other C++ physical units libraries are \"famous\" for their enormous and hard-to-understand error messages (one line of the error log often does not fit on one slide). The ultimate goal of mp-units is to improve this and make compile-time errors and debugging as easy and user-friendly as possible.
To achieve this goal, several techniques are applied:
Important: It is all about errors
In many generic C++ libraries, compile-time errors do not happen often. It is hard to break std::string or std::vector in a way that won't compile with a huge error log. Physical quantities and units libraries are different. Generation of compile-time errors is the main reason to use such a library.
quantity and quantity_point)- Compile-time checked conversions of quantities and units- Unique support for many quantities of the same kind- Type-safe equations on scalar, vector, and tensor quantities and their units- Value-preserving conversions Performance - All the compile-time logic implemented as immediate (consteval) functions- As fast or even faster than working with fundamental types- No space size overhead needed to implement high-level abstractions Great User Experience - Optimized for readable compilation errors and great debugging experience- Efficient and composable way to specify a unit of choice- Value-based dimension, unit, and quantity equations Feature Rich - Systems of Quantities- Systems of Units- Scalar, vector, and tensor quantities- The affine space- Different models of the universe (e.g. natural units systems)- Strong dimensionless quantities- Strong angular system- Supports any unit's magnitude (huge, small, floating-point)- Faster-than-lightspeed constants- Highly adjustable text-output formatting Easy to Extend - Each entity can be defined with a single line of code- User can easily extend the systems with custom dimensions, quantities, and units Low Standardization Cost - Small number of predefined entities thanks to their composability- No external dependencies (assuming full C++20 support)- No macros in the user interface (besides portability and standard-compliance issues)- Possibility to be standardized as a freestanding part of the C++ Standard Library"},{"location":"getting_started/look_and_feel/","title":"Look and Feel","text":"Here is a small example of operations possible on scalar quantities:
C++ modulesHeader filesimport mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\n// simple numeric operations\nstatic_assert(10 * km / 2 == 5 * km);\n\n// conversions to common units\nstatic_assert(1 * h == 3600 * s);\nstatic_assert(1 * km + 1 * m == 1001 * m);\n\n// derived quantities\nstatic_assert(1 * km / (1 * s) == 1000 * m / s);\nstatic_assert(2 * km / h * (2 * h) == 4 * km);\nstatic_assert(2 * km / (2 * km / h) == 1 * h);\n\nstatic_assert(2 * m * (3 * m) == 6 * m2);\n\nstatic_assert(10 * km / (5 * km) == 2);\n\nstatic_assert(1000 / (1 * s) == 1 * kHz);\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\n// simple numeric operations\nstatic_assert(10 * km / 2 == 5 * km);\n\n// conversions to common units\nstatic_assert(1 * h == 3600 * s);\nstatic_assert(1 * km + 1 * m == 1001 * m);\n\n// derived quantities\nstatic_assert(1 * km / (1 * s) == 1000 * m / s);\nstatic_assert(2 * km / h * (2 * h) == 4 * km);\nstatic_assert(2 * km / (2 * km / h) == 1 * h);\n\nstatic_assert(2 * m * (3 * m) == 6 * m2);\n\nstatic_assert(10 * km / (5 * km) == 2);\n\nstatic_assert(1000 / (1 * s) == 1 * kHz);\nTry it on Compiler Explorer
This library requires some C++20 features (concepts and constraints, classes as NTTP, ...). Thanks to them, a user gets a powerful but still easy-to-use interface where all unit conversions and dimensional analysis can be performed without sacrificing accuracy. Please see the below example for a quick preview of basic library features:
C++ modulesHeader files#include <format>\n#include <iomanip>\n#include <iostream>\n#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,\n QuantityOf<isq::time> auto t)\n{\n return d / t;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n using namespace mp_units::international::unit_symbols;\n\n constexpr quantity v1 = 110 * km / h;\n constexpr quantity v2 = 70 * mph;\n constexpr quantity v3 = avg_speed(220. * isq::distance[km], 2 * h);\n constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * h);\n constexpr quantity v5 = v3.in(m / s);\n constexpr quantity v6 = value_cast<m / s>(v4);\n constexpr quantity v7 = value_cast<int>(v6);\n\n std::cout << v1 << '\\n'; // 110 km/h\n std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n'; // ***70 mi/h\n std::cout << std::format(\"{:*^10}\\n\", v3); // *110 km/h*\n std::println(\"{:%N in %U of %D}\", v4); // 70 in mi/h of LT\u207b\u00b9\n std::println(\"{::N[.2f]}\", v5); // 30.56 m/s\n std::println(\"{::N[.2f]U[dn]}\", v6); // 31.29 m\u22c5s\u207b\u00b9\n std::println(\"{:%N}\", v7); // 31\n}\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <format>\n#include <iomanip>\n#include <iostream>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,\n QuantityOf<isq::time> auto t)\n{\n return d / t;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n using namespace mp_units::international::unit_symbols;\n\n constexpr quantity v1 = 110 * km / h;\n constexpr quantity v2 = 70 * mph;\n constexpr quantity v3 = avg_speed(220. * isq::distance[km], 2 * h);\n constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * h);\n constexpr quantity v5 = v3.in(m / s);\n constexpr quantity v6 = value_cast<m / s>(v4);\n constexpr quantity v7 = value_cast<int>(v6);\n\n std::cout << v1 << '\\n'; // 110 km/h\n std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n'; // ***70 mi/h\n std::cout << std::format(\"{:*^10}\\n\", v3); // *110 km/h*\n std::println(\"{:%N in %U of %D}\", v4); // 70 in mi/h of LT\u207b\u00b9\n std::println(\"{::N[.2f]}\", v5); // 30.56 m/s\n std::println(\"{::N[.2f]U[dn]}\", v6); // 31.29 m\u22c5s\u207b\u00b9\n std::println(\"{:%N}\", v7); // 31\n}\nTry it on Compiler Explorer
Note
More code examples can be found in the Examples chapter.
"},{"location":"getting_started/quick_start/","title":"Quick Start","text":"This chapter provides a quick introduction to get you started with mp-units. Much more details can be found in our User's Guide.
"},{"location":"getting_started/quick_start/#quantities","title":"Quantities","text":"A quantity is a concrete amount of a unit representing a quantity type of a specified dimension with a specific representation. It is represented in the library with a quantity class template.
The SI Brochure says:
SI Brochure
The value of the quantity is the product of the number and the unit. The space between the number and the unit is regarded as a multiplication sign (just as a space between units implies multiplication).
Following the above, the value of a quantity in the mp-units library is created by multiplying a number with a predefined unit:
C++ modulesHeader filesimport mp_units;\n\nusing namespace mp_units;\n\nquantity q = 42 * si::metre / si::second;\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q = 42 * si::metre / si::second;\nInfo
In case someone doesn't like the multiply syntax or there is an ambiguity between operator* provided by this and other libraries, there are two other ways to create a quantity:
delta construction helper:
import mp_units;\n\nusing namespace mp_units;\n\nquantity q = delta<si::metre / si::second>(42);\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q = delta<si::metre / si::second>(42);\nA two-parameter constructor:
C++ modulesHeader filesimport mp_units;\n\nusing namespace mp_units;\n\nquantity q{42, si::metre / si::second};\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q{42, si::metre / si::second};\nThe above creates an instance of quantity<derived_unit<si::metre, per<si::second>>{}, int>. The same can be obtained using optional unit symbols:
import mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity q = 42 * m / s;\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity q = 42 * m / s;\nImportant
Unit symbols introduce a lot of short identifiers into the current scope, which may cause naming collisions with unrelated but already existing identifiers in the code base. This is why unit symbols are opt-in and typically should be imported only in the context where they are being used (e.g., function scope).
A user has several options here to choose from depending on the required scenario and possible naming conflicts:
using-directiveusing-declarationcustom short identifierunit namesExplicitly \"import\" all of the symbols of a specific system of units from a dedicated unit_symbols namespace with a using-directive:
using namespace mp_units;\n\nvoid foo(double speed_m_s)\n{\n // imports all the SI symbols at once\n using namespace si::unit_symbols;\n quantity speed = speed_m_s * m / s;\n // ...\n}\nNote
This solution is perfect for small and isolated scopes but can cause surprising issues when used in larger scopes or when used for the entire program namespace.
There are 29 named units in SI, and each of them has many prefixed variations (e.g., ng, kcd, ...). It is pretty easy to introduce a name collision with those.
Selectively bring only the required and not-conflicting symbols with using-declarations:
using namespace mp_units;\n\nvoid foo(double N)\n{\n // 'N' function parameter would collide with the SI symbol for Newton, so we only bring what we need\n using si::unit_symbols::m;\n using si::unit_symbols::s;\n quantity speed = N * m / s;\n // ...\n}\nSpecify a custom not conflicting unit identifier for a unit:
using namespace mp_units;\n\nvoid foo(double speed_m_s)\n{\n // names of some local variables are conflicting with the symbols we want to use\n auto m = ...;\n auto s = ...;\n\n constexpr Unit auto mps = si::metre / si::second;\n quantity speed = speed_m_s * mps;\n}\nFull unit names are straightforward to use and often provide the most readable code:
using namespace mp_units;\n\nvoid foo(double m, double s)\n{\n quantity speed = m * si::metre / (s * si::second);\n // ...\n}\nQuantities of the same kind can be added, subtracted, and compared to each other:
C++ modulesHeader filesimport mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nstatic_assert(1 * km + 50 * m == 1050 * m);\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nstatic_assert(1 * km + 50 * m == 1050 * m);\nVarious quantities can be multiplied or divided by each other:
static_assert(140 * km / (2 * h) == 70 * km / h);\nNote
In case you wonder why this library does not use UDLs to create quantities, please check our FAQ.
"},{"location":"getting_started/quick_start/#quantity-points","title":"Quantity points","text":"The quantity point specifies an absolute quantity with respect to an origin. If no origin is provided explicitly, an implicit one will be provided by the library.
Together with quantities, they model The Affine Space.
Quantity points should be used in all places where adding two values is meaningless (e.g., temperature points, timestamps, altitudes, readouts from the car's odometer, etc.).
The set of operations that can be done on quantity points is limited compared to quantities. This introduces an additional type-safety.
C++ modulesHeader files#include <print>\nimport mp_units;\n\nint main()\n{\n using namespace mp_units;\n using namespace mp_units::si::unit_symbols;\n using namespace mp_units::usc::unit_symbols;\n\n quantity_point temp = absolute<deg_C>(20.);\n std::println(\"Temperature: {} ({})\",\n temp.quantity_from_zero(),\n temp.in(deg_F).quantity_from_zero());\n}\n#include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <mp-units/systems/usc.h>\n#include <print>\n\nint main()\n{\n using namespace mp_units;\n using namespace mp_units::si::unit_symbols;\n using namespace mp_units::usc::unit_symbols;\n\n quantity_point temp = absolute<deg_C>(20.);\n std::println(\"Temperature: {} ({})\",\n temp.quantity_from_zero(),\n temp.in(deg_F).quantity_from_zero());\n}\nThe above outputs:
Temperature: 20 \u2103 (68 \u2109)\nInfo
Check The Affine Space chapter to learn more about quantity points.
"},{"location":"users_guide/terms_and_definitions/","title":"Terms and Definitions","text":"The mp-units project consistently uses the official metrology vocabulary defined by the ISO and BIPM. You can find essential project-related definitions in our documentation's \"Glossary\" chapter. Even more, terms are provided in the official metrology vocabulary of the ISO and BIPM.
Tip
Please familiarize yourself with terms from \"Glossary\" to better understand the documentation and improve domain-related communication and discussions.
"},{"location":"users_guide/examples/avg_speed/","title":"avg_speed","text":"Try it on Compiler Explorer
Let's continue the previous example. This time, our purpose will not be to showcase as many library features as possible, but we will scope on different interfaces one can provide with the mp-units. We will also describe some advantages and disadvantages of presented solutions.
First, we either import a module or include all the necessary header files and import all the identifiers from the mp_units namespace:
#include <exception>\n#include <iostream>\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/ostream.h>\n#include <mp-units/systems/cgs.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n\nnamespace {\n\nusing namespace mp_units;\nNext, we define two functions calculating average speed based on quantities of fixed units and integral and floating-point representation types, respectively, and a third function that we introduced in the previous example:
avg_speed.cppconstexpr quantity<si::metre / si::second, int> fixed_int_si_avg_speed(quantity<si::metre, int> d,\n quantity<si::second, int> t)\n{\n return d / t;\n}\n\nconstexpr quantity<si::metre / si::second> fixed_double_si_avg_speed(quantity<si::metre> d, quantity<si::second> t)\n{\n return d / t;\n}\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d, QuantityOf<isq::time> auto t)\n{\n return d / t;\n}\nWe also added a simple utility to print our results:
avg_speed.cpptemplate<QuantityOf<isq::length> D, QuantityOf<isq::time> T, QuantityOf<isq::speed> V>\nvoid print_result(D distance, T duration, V speed)\n{\n const auto result_in_kmph = speed.force_in(si::kilo<si::metre> / non_si::hour);\n std::cout << \"Average speed of a car that makes \" << distance << \" in \" << duration << \" is \" << result_in_kmph\n << \".\\n\";\n}\nNow, let's analyze how those three utility functions behave with different sets of arguments. First, we are going to use quantities of SI units and integral representation:
avg_speed.cppvoid example()\n{\n using namespace mp_units::si::unit_symbols;\n\n // SI (int)\n {\n constexpr auto distance = 220 * km;\n constexpr auto duration = 2 * h;\n\n std::cout << \"SI units with 'int' as representation\\n\";\n\n print_result(distance, duration, fixed_int_si_avg_speed(distance, duration));\n print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\n }\nThe above provides the following output:
SI units with 'int' as representation\nAverage speed of a car that makes 220 km in 2 h is 108 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nPlease note that in the first two cases, we must convert length from km to m and time from h to s. The converted values are used to calculate speed in m/s which is then again converted to the one in km/h. Those conversions not only impact the application's runtime performance but may also affect the precision of the final result. Such truncation can be easily observed in the first case where we deal with integral representation types (the resulting speed is 108 km/h).
The second scenario is really similar to the previous one, but this time, function arguments have floating-point representation types:
avg_speed.cpp // SI (double)\n {\n constexpr auto distance = 220. * km;\n constexpr auto duration = 2. * h;\n\n std::cout << \"\\nSI units with 'double' as representation\\n\";\n\n // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n print_result(distance, duration, fixed_int_si_avg_speed(value_cast<int>(distance), value_cast<int>(duration)));\n print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\n }\nConversion from floating-point to integral representation types is considered value-truncating and that is why now, in the first case, we need an explicit call to value_cast<int>.
In the text output, we can observe that, again, the resulting value gets truncated during conversions in the first cast:
SI units with 'double' as representation\nAverage speed of a car that makes 220 km in 2 h is 108 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nNext, let's do the same for integral and floating-point representations, but this time using international mile:
avg_speed.cpp // International mile (int)\n {\n using namespace mp_units::international::unit_symbols;\n\n constexpr auto distance = 140 * mi;\n constexpr auto duration = 2 * h;\n\n std::cout << \"\\nInternational mile with 'int' as representation\\n\";\n\n // it is not possible to make a lossless conversion of miles to meters on an integral type\n // (explicit cast needed)\n print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));\n print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\n }\n\n // International mile (double)\n {\n using namespace mp_units::international::unit_symbols;\n\n constexpr auto distance = 140. * mi;\n constexpr auto duration = 2. * h;\n\n std::cout << \"\\nInternational mile with 'double' as representation\\n\";\n\n // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n // also it is not possible to make a lossless conversion of miles to meters on an integral type\n // (explicit cast needed)\n print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));\n print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\n }\nOne important difference here is the fact that as it is not possible to make a lossless conversion of miles to meters on a quantity using an integral representation type, so this time, we need a value_cast<m, int> to force it.
If we check the text output of the above, we will see the following:
International mile with 'int' as representation\nAverage speed of a car that makes 140 mi in 2 h is 111 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112 km/h.\n\nInternational mile with 'double' as representation\nAverage speed of a car that makes 140 mi in 2 h is 111 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\nPlease note how the first and third results get truncated using integral representation types.
In the end, we repeat the scenario for CGS units:
avg_speed.cpp {\n constexpr auto distance = 22'000'000 * cgs::centimetre;\n constexpr auto duration = 7200 * cgs::second;\n\n std::cout << \"\\nCGS units with 'int' as representation\\n\";\n\n // it is not possible to make a lossless conversion of centimeters to meters on an integral type\n // (explicit cast needed)\n print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));\n print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\n }\n\n // CGS (double)\n {\n constexpr auto distance = 22'000'000. * cgs::centimetre;\n constexpr auto duration = 7200. * cgs::second;\n\n std::cout << \"\\nCGS units with 'double' as representation\\n\";\n\n // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n // it is not possible to make a lossless conversion of centimeters to meters on an integral type\n // (explicit cast needed)\n print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));\n\n print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\n }\n}\n\n} // namespace\nAgain, we observe value_cast being used in the same places and consistent truncation errors in the text output:
CGS units with 'int' as representation\nAverage speed of a car that makes 22000000 cm in 7200 s is 108 km/h.\nAverage speed of a car that makes 22000000 cm in 7200 s is 110 km/h.\nAverage speed of a car that makes 22000000 cm in 7200 s is 109 km/h.\n\nCGS units with 'double' as representation\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 108 km/h.\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 110 km/h.\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 110 km/h.\nThe example file ends with a simple main() function:
int main()\n{\n try {\n example();\n } catch (const std::exception& ex) {\n std::cerr << \"Unhandled std exception caught: \" << ex.what() << '\\n';\n } catch (...) {\n std::cerr << \"Unhandled unknown exception caught\\n\";\n }\n}\nhello_units","text":"Try it on Compiler Explorer
This is a really simple example showcasing the features of the mp-units library.
First, we either import the mp_units module or include the headers for:
#include <mp-units/compat_macros.h>\n#include <mp-units/ext/format.h>\n#include <iomanip>\n#include <iostream>\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\nAlso, to shorten the definitions, we \"import\" all the symbols from the mp_units namespace.
using namespace mp_units;\nNext, we define a simple function that calculates the average speed based on the provided arguments of length and time:
hello_units.cppconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d, QuantityOf<isq::time> auto t)\n{\n return d / t;\n}\nThe above function template takes any quantities implicitly convertible to isq::length and isq::time, respectively. Those quantities can use any compatible unit and a representation type. The function returns a result of a straightforward equation and ensures that its quantity type is implicitly convertible to isq::speed.
Tip
Besides verifying the type returned from the function, constraining a generic return type is beneficial for users of such a function as it provides more information of what to expect from a function than just using auto.
int main()\n{\n using namespace mp_units::si::unit_symbols;\n using namespace mp_units::international::unit_symbols;\nThe above lines explicitly opt into using unit symbols from two systems of units. As this introduces a lot of short identifiers into the current scope, it is not done implicitly while including a header file.
hello_units.cpp constexpr quantity v1 = 110 * km / h;\n constexpr quantity v2 = 70 * mph;\n constexpr quantity v3 = avg_speed(220. * km, 2 * h);\n constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * isq::duration[h]);\n constexpr quantity v5 = v3.in(m / s);\n constexpr quantity v6 = value_cast<m / s>(v4);\n constexpr quantity v7 = value_cast<int>(v6);\n23 & 24 create a quantity of kind isq::length / isq::time with the numbers and units provided. Such quantities can be converted or assigned to any other quantity with a matching kind.25 calls our function template with quantities of kind isq::length and isq::time and number and units provided.26 explicitly provides quantity types of the quantities passed to a function template. This time, those will not be quantity kinds anymore and will have more restrictive conversion rules.27 changes the unit of a quantity v3 to m / s in a value-preserving way (floating-point representations are considered to be value-preserving).28 does a similar operation, but this time, it would also succeed for value-truncating cases (if that was the case).29 does a value-truncating conversion of changing the underlying representation type from double to int. std::cout << v1 << '\\n'; // 110 km/h\n std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n'; // ***70 mi/h\n std::cout << MP_UNITS_STD_FMT::format(\"{:*^10}\\n\", v3); // *110 km/h*\n std::cout << MP_UNITS_STD_FMT::format(\"{:%N in %U of %D}\\n\", v4); // 70 in mi/h of LT\u207b\u00b9\n std::cout << MP_UNITS_STD_FMT::format(\"{::N[.2f]}\\n\", v5); // 30.56 m/s\n std::cout << MP_UNITS_STD_FMT::format(\"{::N[.2f]U[dn]}\\n\", v6); // 31.29 m\u22c5s\u207b\u00b9\n std::cout << MP_UNITS_STD_FMT::format(\"{:%N}\\n\", v7); // 31\n}\nThe above presents various ways to print a quantity. Both stream insertion operations and std::format facilities are supported.
Tip
MP_UNITS_STD_FMT is used for compatibility reasons. If a specific compiler does not support std::format or a user prefers to use the {fmt} library, this macro will resolve to fmt namespace. Otherwise, the std namespace will be used.
si_constants","text":"Try it on Compiler Explorer
The next example presents all the seven defining constants of the SI system. We can observe how Faster-than-lightspeed Constants work in practice.
si_constants.cpp#include <mp-units/compat_macros.h>\n#include <mp-units/ext/format.h>\n#include <iostream>\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#endif\n\ntemplate<class T>\n requires mp_units::is_scalar<T>\ninline constexpr bool mp_units::is_vector<T> = true;\nAs always, we start with the inclusion of all the needed header files. After that, for the simplicity of this example, we hack the character of quantities to be able to express vector quantities with simple scalar types.
si_constants.cppint main()\n{\n using namespace mp_units;\n using namespace mp_units::si;\n using namespace mp_units::si::unit_symbols;\n\n std::cout << \"The seven defining constants of the SI and the seven corresponding units they define:\\n\";\n std::cout << MP_UNITS_STD_FMT::format(\"- hyperfine transition frequency of Cs: {} = {::N[.0]}\\n\",\n 1. * si2019::hyperfine_structure_transition_frequency_of_cs,\n (1. * si2019::hyperfine_structure_transition_frequency_of_cs).in(Hz));\n std::cout << MP_UNITS_STD_FMT::format(\"- speed of light in vacuum: {} = {::N[.0]}\\n\",\n 1. * si2019::speed_of_light_in_vacuum,\n (1. * si2019::speed_of_light_in_vacuum).in(m / s));\n std::cout << MP_UNITS_STD_FMT::format(\"- Planck constant: {} = {::N[.8e]}\\n\",\n 1. * si2019::planck_constant, (1. * si2019::planck_constant).in(J * s));\n std::cout << MP_UNITS_STD_FMT::format(\"- elementary charge: {} = {::N[.9e]}\\n\",\n 1. * si2019::elementary_charge, (1. * si2019::elementary_charge).in(C));\n std::cout << MP_UNITS_STD_FMT::format(\"- Boltzmann constant: {} = {::N[.6e]}\\n\",\n 1. * si2019::boltzmann_constant, (1. * si2019::boltzmann_constant).in(J / K));\n std::cout << MP_UNITS_STD_FMT::format(\"- Avogadro constant: {} = {::N[.8e]}\\n\",\n 1. * si2019::avogadro_constant, (1. * si2019::avogadro_constant).in(one / mol));\n std::cout << MP_UNITS_STD_FMT::format(\"- luminous efficacy: {} = {}\\n\",\n 1. * si2019::luminous_efficacy, (1. * si2019::luminous_efficacy).in(lm / W));\n}\nThe main part of the example prints all of the SI-defining constants. While analyzing the output of this program (provided below), we can easily notice that a direct printing of the quantity provides just a value 1 with a proper constant symbol. This is the main power of the Faster-than-lightspeed Constants feature. Only after we explicitly convert the unit of a quantity to proper SI units we get an actual numeric value of the constant.
The seven defining constants of the SI and the seven corresponding units they define:\n- hyperfine transition frequency of Cs: 1 \u0394\u03bd_Cs = 9192631770 Hz\n- speed of light in vacuum: 1 c = 299792458 m/s\n- Planck constant: 1 h = 6.62607015e-34 J s\n- elementary charge: 1 e = 1.602176634e-19 C\n- Boltzmann constant: 1 k = 1.380649e-23 J/K\n- Avogadro constant: 1 N_A = 6.02214076e+23 1/mol\n- luminous efficacy: 1 K_cd = 683 lm/W\nWarning
This chapter's features are experimental and subject to change or removal. Please share your feedback if something seems wrong or could be improved.
"},{"location":"users_guide/framework_basics/character_of_a_quantity/#scalars-vectors-and-tensors","title":"Scalars, vectors, and tensors","text":"ISO 80000-2
Scalars, vectors and tensors are mathematical objects that can be used to denote certain physical quantities and their values. They are as such independent of the particular choice of a coordinate system, whereas each scalar component of a vector or a tensor and each component vector and component tensor depend on that choice.
Such distinction is important because each quantity character represents different properties and allows different operations to be done on its quantities.
For example, imagine a physical units library that allows the creation of a \\(speed\\) quantity from both \\(length / time\\) and \\(length * time\\). It wouldn't be too safe to use such a product, right?
Now we have to realize that both of the above operations (multiplication and division) are not even mathematically defined for linear algebra types such as vectors or tensors. On the other hand, two vectors can be passed as arguments to dot and cross-product operations. The result of the first one is a scalar. The second one results in a vector that is perpendicular to both vectors passed as arguments. Again, it wouldn't be safe to allow replacing those two operations with each other or expect the same results from both cases. This simply can't work.
"},{"location":"users_guide/framework_basics/character_of_a_quantity/#isq-defines-quantities-of-all-characters","title":"ISQ defines quantities of all characters","text":"While defining quantities ISO 80000 explicitly mentions when a specific quantity has a vector or tensor character. Here are some examples:
Quantity Character Quantity Equation \\(duration\\) scalar {base quantity} \\(mass\\) scalar {base quantity} \\(length\\) scalar {base quantity} \\(path\\; length\\) scalar {base quantity} \\(radius\\) scalar {base quantity} \\(position\\; vector\\) vector {base quantity} \\(velocity\\) vector \\(position\\; vector / duration\\) \\(acceleration\\) vector \\(velocity / duration\\) \\(force\\) vector \\(mass * acceleration\\) \\(power\\) scalar \\(force \\cdot velocity\\) \\(moment\\; of\\; force\\) vector \\(position\\; vector \\times force\\) \\(torque\\) scalar \\(moment\\; of\\; force \\cdot \\{unit\\; vector\\}\\) \\(surface\\; tension\\) scalar \\(\\lvert force \\rvert / length\\) \\(angular\\; displacement\\) scalar \\(path\\; length / radius\\) \\(angular\\; velocity\\) vector \\(angular\\; displacement / duration * \\{unit\\; vector\\}\\) \\(momentum\\) vector \\(mass * velocity\\) \\(angular\\; momentum\\) vector \\(position\\; vector \\times momentum\\) \\(moment\\; of\\; inertia\\) tensor \\(angular\\; momentum \\otimes angular\\; velocity\\)In the above equations:
Note
As of now, all of the C++ physical units libraries on the market besides mp-units do not support the operations mentioned above. They expose only multiplication and division operators, which do not work for linear algebra-based representation types. If a user of those libraries would like to create the quantities provided in the above table properly, this would result in a compile-time error stating that multiplication and division of two linear algebra vectors is impossible.
"},{"location":"users_guide/framework_basics/character_of_a_quantity/#characters-dont-apply-to-dimensions-and-units","title":"Characters don't apply to dimensions and units","text":"ISO 80000 explicitly states that dimensions are orthogonal to quantity characters:
ISO 80000-1:2009
In deriving the dimension of a quantity, no account is taken of its scalar, vector, or tensor character.
Also, it explicitly states that:
ISO 80000-2
All units are scalars.
"},{"location":"users_guide/framework_basics/character_of_a_quantity/#defining-vector-and-tensor-quantities","title":"Defining vector and tensor quantities","text":"To specify that a specific quantity has a vector or tensor character a value of quantity_character enumeration can be appended to the quantity_spec describing such a quantity type:
inline constexpr struct position_vector final : quantity_spec<length, quantity_character::vector> {} position_vector;\ninline constexpr struct displacement final : quantity_spec<length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<position_vector, length, quantity_character::vector> {} position_vector;\ninline constexpr struct displacement final : quantity_spec<displacement, length, quantity_character::vector> {} displacement;\nQUANTITY_SPEC(position_vector, length, quantity_character::vector);\nQUANTITY_SPEC(displacement, length, quantity_character::vector);\nWith the above, all the quantities derived from position_vector or displacement will have a correct character determined according to the kind of operations included in the quantity equation defining a derived quantity.
For example, velocity in the below definition will be defined as a vector quantity (no explicit character override is needed):
inline constexpr struct velocity final : quantity_spec<speed, position_vector / duration> {} velocity;\ninline constexpr struct velocity final : quantity_spec<velocity, speed, position_vector / duration> {} velocity;\nQUANTITY_SPEC(velocity, speed, position_vector / duration);\nAs we remember, the quantity class template is defined as follows:
template<Reference auto R,\n RepresentationOf<get_quantity_spec(R).character> Rep = double>\nclass quantity;\nThe second template parameter is constrained with a RepresentationOf concept that checks if the provided representation type satisfies the requirements for the character associated with this quantity type.
Note
The current version of the C++ Standard Library does not provide any types that could be used as a representation type for vector and tensor quantities. This is why users are on their own here .
To provide examples and implement unit tests, our library uses the types proposed in the P1385 and available as a Conan package in the Conan Center. However, thanks to the provided customization points, any linear algebra library types can be used as a vector or tensor quantity representation type.
To enable the usage of a user-defined type as a representation type for vector or tensor quantities, we need to provide a partial specialization of is_vector or is_tensor customization points.
For example, here is how it can be done for the P1385 types:
#include <matrix>\n\nusing la_vector = STD_LA::fixed_size_column_vector<double, 3>;\n\ntemplate<>\ninline constexpr bool mp_units::is_vector<la_vector> = true;\nWith the above, we can use la_vector as a representation type for our quantity:
Quantity auto q = la_vector{1, 2, 3} * isq::velocity[m / s];\nIn case there is an ambiguity of operator* between mp-units and a linear algebra library, we can either:
use two-parameter constructor
Quantity auto q = quantity{la_vector{1, 2, 3}, isq::velocity[m / s]};\nprovide a dedicated overload of operator* that will resolve the ambiguity and wrap the above
template<Reference R>\nQuantity auto operator*(la_vector rep, R)\n{\n return quantity{rep, R{}};\n}\nNote
The following does not work:
Quantity auto q1 = la_vector{1, 2, 3} * m / s;\nQuantity auto q2 = isq::velocity(la_vector{1, 2, 3} * m / s);\nquantity<isq::velocity[m/s]> q3{la_vector{1, 2, 3} * m / s};\nIn all the cases above, the SI unit m / s has an associated scalar quantity of isq::length / isq::time. la_vector is not a correct representation type for a scalar quantity so the construction fails.
Sometimes we want to use a vector quantity, but we don't care about its direction. For example, the standard gravity acceleration constant always points down, so we might not care about this in a particular scenario. In such a case, we may want to \"hack\" the library to allow scalar types to be used as a representation type for scalar quantities.
For example, we can do the following:
template<class T>\n requires mp_units::is_scalar<T>\ninline constexpr bool mp_units::is_vector<T> = true;\nwhich says that every type that can be used as a scalar representation is also allowed for vector quantities.
Doing the above is actually not such a big \"hack\" as the ISO 80000 explicitly allows it:
ISO 80000-2
A vector is a tensor of the first order and a scalar is a tensor of order zero.
Despite it being allowed by ISO 80000, for type-safety reasons, we do not allow such a behavior by default, and a user has to opt into such scenarios explicitly.
"},{"location":"users_guide/framework_basics/concepts/","title":"Concepts","text":"This chapter enumerates all the user-facing concepts in the mp-units library.
"},{"location":"users_guide/framework_basics/concepts/#Dimension","title":"Dimension<T>","text":"Dimension concept matches a dimension of either a base or derived quantity:
base_dimension class template. It should be instantiated with a unique symbol identifier describing this dimension in a specific system of quantities.All of the above dimensions have to be marked as final.
DimensionOf<T, V>","text":"DimensionOf concept is satisfied when both arguments satisfy a Dimension concept and when they compare equal.
QuantitySpec<T>","text":"QuantitySpec concept matches all the quantity specifications including:
quantity_spec class template instantiated with a base dimension argument.quantity_spec class template instantiated with a result of a quantity equation passed as an argument.quantity_spec class template instantiated with another \"parent\" quantity specification passed as an argument.All of the above quantity specifications have to be marked as final.
QuantitySpecOf<T, V>","text":"QuantitySpecOf concept is satisfied when both arguments satisfy a QuantitySpec concept and when T is implicitly convertible to V.
Additionally:
T should not be a nested quantity specification of VT is quantity kind or V should not be a nested quantity specification of TThose additional conditions are required to make the following work:
static_assert(ReferenceOf<si::radian, isq::angular_measure>);\nstatic_assert(!ReferenceOf<si::radian, dimensionless>);\nstatic_assert(!ReferenceOf<isq::angular_measure[si::radian], dimensionless>);\nstatic_assert(ReferenceOf<one, isq::angular_measure>);\nstatic_assert(!ReferenceOf<dimensionless[one], isq::angular_measure>);\nUnit<T>","text":"Unit concept matches all the units in the library including:
named_unit class template instantiated with a unique symbol identifier describing this unit in a specific system of units.named_unit class template instantiated with a unique symbol identifier and a product of multiplying another unit with some magnitude.prefixed_unit class template instantiated with a prefix symbol, a magnitude, and a unit to be prefixed.named_unit class template instantiated with a unique symbol identifier and a result of unit equation passed as an argument.All of the above units have to be marked as final.
Note
In the mp-units library, physical constants are also implemented as units.
"},{"location":"users_guide/framework_basics/concepts/#AssociatedUnit","title":"AssociatedUnit<T>","text":"AssociatedUnit concept describes a unit with an associated quantity and is satisfied by:
named_unit class template instantiated with a unique symbol identifier and a QuantitySpec of a quantity kind.All units in the SI have associated quantities. For example, si::second is specified to measure isq::time.
Natural units typically do not have an associated quantity. For example, if we assume c = 1, a natural::second unit can be used to measure both time and length. In such case, speed would have a unit of one.
PrefixableUnit<T>","text":"PrefixableUnit concept is satisfied by all units derived from a named_unit class template for which a customization point unit_can_be_prefixed<T{}> was not explicitly set to false. Such units can be passed as an argument to a prefixed_unit class template.
All units in the SI can be prefixed with SI-defined prefixes.
Some off-system units like non_si::day can't be prefixed. To enforce that, the following has to be provided:
template<> inline constexpr bool unit_can_be_prefixed<non_si::day> = false;\nUnitOf<T, V>","text":"UnitOf concept is satisfied for all units T matching an AssociatedUnit concept with an associated quantity type implicitly convertible to V.
Additionally, the kind of V and the kind of quantity type associated with T must be the same, or the quantity type associated with T may not be derived from the kind of V.
This condition is required to make dimensionless[si::radian] invalid as si::radian should be only used for isq::angular_measure, which is a nested quantity kind within the dimensionless quantities tree.
Reference<T>","text":"Reference concept is satisfied by all quantity reference types. Such types provide all the meta-information required to create a Quantity. A Reference can either be:
AssociatedUnit.reference class template with a QuantitySpec passed as the first template argument and a Unit passed as the second one.ReferenceOf<T, V>","text":"ReferenceOf concept is satisfied by references T which have a quantity specification that satisfies QuantitySpecOf<V> concept. |
Representation<T>","text":"Representation concept constraints a type of a number that stores the value of a quantity.
RepresentationOf<T, Ch>","text":"RepresentationOf concept is satisfied by all Representation types that are of a specified quantity character Ch.
A user can declare a custom representation type to be of a specific character by providing the specialization with true for one or more of the following variable templates:
is_scalar<T>is_vector<T>is_tensor<T>If we want to use scalar types to also express vector quantities (e.g., ignoring the \"direction\" of the vector) the following definition can be provided to enable such a behavior:
template<class T>\n requires mp_units::is_scalar<T>\ninline constexpr bool mp_units::is_vector<T> = true;\nQuantity<T>","text":"Quantity concept matches every quantity in the library and is satisfied by all types being or deriving from an instantiation of a quantity class template.
QuantityOf<T, V>","text":"QuantityOf concept is satisfied by all the quantities for which a QuantitySpecOf<V> is true.
PointOrigin<T>","text":"PointOrigin concept matches all quantity point origins in the library. It is satisfied by either:
absolute_point_origin class template.relative_point_origin class template.PointOriginFor<T, V>","text":"PointOriginFor concept is satisfied by all PointOrigin types that have quantity type implicitly convertible from quantity specification V, which means that V must satisfy QuantitySpecOf<T::quantity_spec>.
si::ice_point can serve as a point origin for points of isq::Celsius_temperature because this quantity type implicitly converts to isq::thermodynamic_temperature.
However, if we define mean_sea_level in the following way:
inline constexpr struct mean_sea_level final : absolute_point_origin<isq::altitude> {} mean_sea_level;\nthen it can't be used as a point origin for points of isq::length or isq::width as none of them is implicitly convertible to isq::altitude:
QuantityPoint<T>","text":"QuantityPoint concept is satisfied by all types being either a specialization or derived from quantity_point class template.
QuantityPointOf<T, V>","text":"QuantityPointOf concept is satisfied by all the quantity points T that match the following value V:
V Condition QuantitySpec The quantity point quantity specification satisfies QuantitySpecOf<V> concept. PointOrigin The point and V have the same absolute point origin."},{"location":"users_guide/framework_basics/concepts/#QuantityLike","title":"QuantityLike<T>","text":"QuantityLike concept provides interoperability with other libraries and is satisfied by a type T for which an instantiation of quantity_like_traits type trait yields a valid type that provides:
reference that matches the Reference concept,rep type that matches RepresentationOf concept with the character provided in reference.to_numerical_value(T) static member function returning a raw value of the quantity packed in either convert_explicitly or convert_implicitly wrapper that enables implicit conversion in the latter case.from_numerical_value(rep) static member function returning T packed in either convert_explicitly or convert_implicitly wrapper that enables implicit conversion in the latter case.This is how support for std::chrono::seconds can be provided:
template<>\nstruct mp_units::quantity_like_traits<std::chrono::seconds> {\n static constexpr auto reference = si::second;\n using rep = std::chrono::seconds::rep;\n\n [[nodiscard]] static constexpr convert_implicitly<rep> to_numerical_value(const std::chrono::seconds& d)\n {\n return d.count();\n }\n\n [[nodiscard]] static constexpr convert_implicitly<std::chrono::seconds> from_numerical_value(const rep& v)\n {\n return std::chrono::seconds(v);\n }\n};\n\nquantity q = 42s;\nstd::chrono::seconds dur = 42 * s;\nQuantityPointLike<T>","text":"QuantityPointLike concept provides interoperability with other libraries and is satisfied by a type T for which an instantiation of quantity_point_like_traits type trait yields a valid type that provides:
reference that matches the Reference concept.point_origin that matches the PointOrigin concept.rep type that matches RepresentationOf concept with the character provided in reference.to_numerical_value(T) static member function returning a raw value of the quantity being the offset of the point from the origin packed in either convert_explicitly or convert_implicitly wrapper that enables implicit conversion in the latter case.from_numerical_value(rep) static member function returning T packed in either convert_explicitly or convert_implicitly wrapper that enables implicit conversion in the latter case.This is how support for a std::chrono::time_point of std::chrono::seconds can be provided:
template<typename C>\nstruct mp_units::quantity_point_like_traits<std::chrono::time_point<C, std::chrono::seconds>> {\n using T = std::chrono::time_point<C, std::chrono::seconds>;\n static constexpr auto reference = si::second;\n static constexpr struct point_origin_ final : absolute_point_origin<isq::time> {} point_origin{};\n using rep = std::chrono::seconds::rep;\n\n [[nodiscard]] static constexpr convert_implicitly<rep> to_numerical_value(const T& tp)\n {\n return tp.time_since_epoch().count();\n }\n\n [[nodiscard]] static constexpr convert_implicitly<T> from_numerical_value(const rep& v)\n {\n return T(std::chrono::seconds(v));\n }\n};\n\nquantity_point qp = time_point_cast<std::chrono::seconds>(std::chrono::system_clock::now());\nstd::chrono::sys_seconds q = qp + 42 * s;\nThe most important entities in the mp-units library are:
The graph provided below presents how those and a few other entities depend on each other:
flowchart TD\n Unit --- Reference\n Dimension --- QuantitySpec[\"Quantity specification\"]\n quantity_character[\"Quantity character\"] --- QuantitySpec\n QuantitySpec --- Reference[\"Quantity reference\"]\n Reference --- Quantity\n quantity_character -.- Representation\n Representation --- Quantity\n Quantity --- QuantityPoint[\"Quantity point\"]\n PointOrigin[\"Point origin\"] --- QuantityPoint\n\n click Dimension \"#dimension\"\n click quantity_character \"#quantity-character\"\n click QuantitySpec \"#quantity-specification\"\n click Unit \"#unit\"\n click Reference \"#quantity-reference\"\n click Representation \"#quantity-representation\"\n click Quantity \"#quantity\"\n click PointOrigin \"#point-origin\"\n click QuantityPoint \"#quantity-point\"Dimension specifies the dependence of a quantity on the base quantities of a particular system of quantities. It is represented as a product of powers of factors corresponding to the base quantities, omitting any numerical factor.
In the mp-units library, we use the terms:
For example:
iec80000::dim_traffic_intensity base dimension to extend ISQ with strong information technology quantities.Base dimensions can be defined by the user in the following way:
inline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct dim_time final : base_dimension<\"T\"> {} dim_time;\nDerived dimensions are implicitly created by the library's framework based on the quantity equation provided in the quantity specification:
C++23C++20Portableinline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct time final : quantity_spec<dim_time> {} time;\ninline constexpr struct speed final : quantity_spec<length / time> {} speed;\n\nstatic_assert(speed.dimension == dim_length / dim_time);\ninline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct time final : quantity_spec<time, dim_time> {} time;\ninline constexpr struct speed final : quantity_spec<speed, length / time> {} speed;\n\nstatic_assert(speed.dimension == dim_length / dim_time);\nQUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(time, dim_time);\nQUANTITY_SPEC(speed, length / time);\n\nstatic_assert(speed.dimension == dim_length / dim_time);\nImportant
Users should not explicitly define any derived dimensions. Those should always be implicitly created by the framework.
The multiplication/division on quantity specifications also multiplies/divides their dimensions:
static_assert((length / time).dimension == dim_length / dim_time);\nThe dimension equation of isq::dim_length / isq::dim_time results in the derived_dimension<isq::dim_length, per<isq::dim_time>> type.
ISO 80000 explicitly states that quantities (even of the same kind) may have different characters:
The quantity character in the mp-units library is implemented with the quantity_character enumeration:
enum class quantity_character { scalar, vector, tensor };\nInfo
You can read more on quantity characters in the \"Character of a Quantity\" chapter.
"},{"location":"users_guide/framework_basics/design_overview/#quantity-specification","title":"Quantity specification","text":"Dimension is not enough to describe a quantity. This is why the ISO 80000 provides hundreds of named quantity types. It turns out that there are many more quantity types in the ISQ than the named units in the SI.
This is why the mp-units library introduces a quantity specification entity that stores:
Note
We know that it might be sometimes confusing to talk about quantities, quantity types/names, and quantity specifications. However, it might be important to notice here that even the ISO 80000 admits that:
It is customary to use the same term, \"quantity\", to refer to both general quantities, such as length, mass, etc., and their instances, such as given lengths, given masses, etc. Accordingly, we are used to saying both that length is a quantity and that a given length is a quantity by maintaining the specification \u2013 \"general quantity, \\(Q\\)\" or \"individual quantity, \\(Q_\\textsf{a}\\)\" \u2013 implicit and exploiting the linguistic context to remove the ambiguity.
In the mp-units library, we have a:
quantity class template,quantity_spec class template that among others identifies a specific quantity type/name.For example:
isq::length, isq::mass, isq::time, isq::electric_current, isq::thermodynamic_temperature, isq::amount_of_substance, and isq::luminous_intensity are the specifications of base quantities in the ISQ.isq::width, isq::height, isq::radius, and isq::position_vector are only a few of many quantities of a kind length specified in the ISQ.isq::area, isq::speed, isq::moment_of_force are only a few of many derived quantities provided in the ISQ.Quantity specification can be defined by the user in one of the following ways:
C++23C++20Portableinline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct height final : quantity_spec<length> {} height;\ninline constexpr struct speed final : quantity_spec<length / time> {} speed;\ninline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct height final : quantity_spec<height, length> {} height;\ninline constexpr struct speed final : quantity_spec<speed, length / time> {} speed;\nQUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(height, length);\nQUANTITY_SPEC(speed, length / time);\nThe quantity equation of isq::length / isq::time results in the derived_quantity_spec<isq::length, per<isq::time>> type.
A unit is a concrete amount of a quantity that allows us to measure the values of quantities of the same kind and represent the result as a number being the ratio of the two quantities.
For example:
si::second, si::metre, si::kilogram, si::ampere, si::kelvin, si::mole, and si::candela are the base units of the SI.si::kilo<si::metre> is a prefixed unit of length.si::radian, si::newton, and si::watt are examples of named derived units within the SI.non_si::minute is an example of a scaled unit of time.si::si2019::speed_of_light_in_vacuum is a physical constant standardized by the SI in 2019.Note
In the mp-units library, physical constants are also implemented as units.
A unit can be defined by the user in one of the following ways:
template<PrefixableUnit U> struct kilo_ : prefixed_unit<\"k\", mag_power<10, 3>, U{}> {};\ntemplate<PrefixableUnit auto U> inline constexpr kilo_<decltype(U)> kilo;\n\ninline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\ninline constexpr struct minute final : named_unit<\"min\", mag<60> * second> {} minute;\ninline constexpr struct gram final : named_unit<\"g\", kind_of<isq::mass>> {} gram;\ninline constexpr auto kilogram = kilo<gram>;\ninline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\n\ninline constexpr struct speed_of_light_in_vacuum final : named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\nThe unit equation of si::metre / si::second results in the derived_unit<si::metre, per<si::second>> type.
ISO defines a quantity as:
Quote
property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
After that, it says:
Quote
A reference can be a measurement unit, a measurement procedure, a reference material, or a combination of such.
In the mp-units library, a quantity reference provides all the domain-specific metadata for the quantity besides its numerical value:
Together with the value of a representation type, it forms a quantity.
In the library, we have two different ways to provide a reference:
reference class template with this quantity spec and a unit passed as arguments.Note
All the units of the SI have associated quantity kinds and may serve as a reference.
For example:
si::metre is defined in the SI as a unit of isq::length and thus can be used as a reference to instantiate a quantity of length (e.g., 42 * m).isq::height[m] results with reference<isq::height, si::metre>, which can be used to instantiate a quantity of isq::height with a unit of si::metre (e.g., 42 * isq::height[m]).Quantity representation defines the type used to store the numerical value of a quantity. Such a type should be of a specific quantity character provided in the quantity specification.
Note
By default, all floating-point and integral (besides bool) types are treated as scalars.
ISO defines a quantity as:
Quote
property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
This is why a quantity class template is defined in the library as:
template<Reference auto R,\n RepresentationOf<get_quantity_spec(R).character> Rep = double>\nclass quantity;\nIts value can be easily created by multiplying/dividing the numerical value and a reference.
For example:
42 * m, 42 * si::metre, 42 * isq::height[m], and isq::height(42 * m) create a quantity.quantity<si::metre, int>, quantity<isq::height[m]>).In the affine space theory, the point origin specifies where the \"zero\" of our measurement's scale is.
In the mp-units library, we have two types of point origins:
For example:
inline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr struct ice_point final : relative_point_origin<absolute_zero + 273'150 * milli<kelvin>> {} ice_point;\nQuantity point implements a point in the affine space theory.
In the mp-units library, the quantity point is implemented as:
template<Reference auto R,\n PointOriginFor<get_quantity_spec(R)> auto PO,\n RepresentationOf<get_quantity_spec(R).character> Rep = double>\nclass quantity_point;\nIts value can be easily created by adding/subtracting the quantity with a point origin.
For example:
ice_point provided in the previous example:constexpr auto room_reference_temperature = ice_point + delta<isq::Celsius_temperature[deg_C]>(21);\nThe quantities we discussed so far always had some specific type and physical dimension. However, this is not always the case. While performing various computations, we sometimes end up with so-called \"dimensionless\" quantities, which ISO defines as quantities of dimension one:
ISO/IEC Guide 99
Dividing two quantities of the same kind always results in a quantity of dimension one. However, depending on what type of quantities we divide or what their units are, we may end up with slightly different results.
Note
In mp-units, dividing two quantities of the same dimension always results in a quantity with the dimension being dimension_one. This is often different for other physical units libraries, which may return a raw representation type for such cases. A raw value is also always returned from the division of two std::chrono::duration objects.
To read more about the reasoning for this design decision, please check our FAQ.
"},{"location":"users_guide/framework_basics/dimensionless_quantities/#dividing-quantities-of-the-same-type","title":"Dividing quantities of the same type","text":"First, let's analyze what happens if we divide two quantities of the same type:
constexpr QuantityOf<dimensionless> auto q = isq::height(200 * m) / isq::height(50 * m);\nIn such a case, we end up with a dimensionless quantity that has the following properties:
static_assert(q.quantity_spec == dimensionless);\nstatic_assert(q.dimension == dimension_one);\nstatic_assert(q.unit == one);\nIn case we would like to print its value, we would see a raw value of 4 in the output with no unit being printed.
Now let's see what happens if we divide quantities of the same dimension and unit but which have different quantity types:
constexpr QuantityOf<dimensionless> auto q = isq::work(200 * J) / isq::heat(50 * J);\nAgain we end up with dimension_one and one, but this time:
static_assert(q.quantity_spec == isq::work / isq::heat);\nAs shown above, the result is not of a dimensionless type anymore. Instead, we get a quantity type derived from the performed quantity equation. According to the ISQ, work divided by heat is the recipe for the thermodynamic efficiency quantity, thus:
static_assert(implicitly_convertible(q.quantity_spec, isq::efficiency_thermodynamics));\nNote
The quantity of isq::efficiency_thermodynamics is of a kind dimensionless, so it is implicitly convertible to dimensionless and satisfies the QuantityOf<dimensionless> concept.
Now, let's see what happens when we divide two quantities of the same type but different units:
constexpr QuantityOf<dimensionless> auto q = isq::height(4 * km) / isq::height(2 * m);\nThis time, we still get a quantity of the dimensionless type with a dimension_one as its dimension. However, the resulting unit is not one anymore:
static_assert(q.unit == mag_power<10, 3> * one);\nIn case we would print the text output of this quantity, we would not see a raw value of 2000, but 2 km/m.
First, it may look surprising, but this is consistent with dividing quantities of different dimensions. For example, if we divide 4 * km / 2 * s, we do not expect km to be \"expanded\" to m before the division, right? We would expect the result of 2 km/s, which is exactly what we get when we divide quantities of the same kind.
This is a compelling feature that allows us to express huge or tiny ratios without the need for big and expensive representation types. With this, we can easily define things like a Hubble's constant that uses a unit that is proportional to the ratio of kilometers per megaparsecs, which are both units of length:
inline constexpr struct hubble_constant final :\n named_unit<{u8\"H\u2080\", \"H_0\"}, mag_ratio<701, 10> * si::kilo<si::metre> / si::second / si::mega<parsec>> {} hubble_constant;\nAnother important use case for dimensionless quantities is to provide strong types for counts of things. For example:
Thanks to assigning strong names to such quantities, later on, they can be explicitly used as arguments in the quantity equations of other quantities deriving from them.
"},{"location":"users_guide/framework_basics/dimensionless_quantities/#predefined-units-of-the-dimensionless-quantity","title":"Predefined units of the dimensionless quantity","text":"As we observed above, the most common unit for dimensionless quantities is one. It has the ratio of 1 and does not output any textual symbol.
Important: one is an identity
A unit one is special in the entire type system of units as it is considered to be an identity operand in the unit expression templates. This means that, for example:
static_assert(one * one == one);\nstatic_assert(one * si::metre == si::metre);\nstatic_assert(si::metre / si::metre == one);\nThe same is also true for dimension_one and dimensionless in the domains of dimensions and quantity specifications.
Besides the unit one, there are a few other scaled units predefined in the library for usage with dimensionless quantities:
inline constexpr struct percent final : named_unit<\"%\", mag_ratio<1, 100> * one> {} percent;\ninline constexpr struct per_mille final : named_unit<{u8\"\u2030\", \"%o\"}, mag_ratio<1, 1000> * one> {} per_mille;\ninline constexpr struct parts_per_million final : named_unit<\"ppm\", mag_ratio<1, 1'000'000> * one> {} parts_per_million;\ninline constexpr auto ppm = parts_per_million;\none","text":"Quantities of the unit one are the only ones that are implicitly convertible from a raw value and explicitly convertible to it. This property also expands to usual arithmetic operators.
Thanks to the above, we can type:
quantity<one> inc(quantity<one> q) { return q + 1; }\nvoid legacy(double) { /* ... */ }\n\nif (auto q = inc(42); q != 0)\n legacy(static_cast<int>(q));\nSpecial, often controversial, examples of dimensionless quantities are an angular measure and solid angular measure quantities that are defined in the ISQ to be the result of a division of \\(arc\\; length / radius\\) and \\(area / radius^2\\) respectively. Moreover, ISQ also explicitly states that both can be expressed in the unit one. This means that both angular measure and solid angular measure should be of a kind dimensionless.
On the other hand, ISQ also specifies that a unit radian can be used for angular measure, and a unit steradian can be used for solid angular measure. Those should not be mixed or used to express other types of dimensionless quantities. This means that both angular measure and solid angular measure should also be quantity kinds by themselves.
Note
Many people claim that angle being a dimensionless quantity is a bad idea. There are proposals submitted to make an angle a base quantity and rad to become a base unit. More on this topic can be found in the \"Strong Angular System\" chapter.
Thanks to the usage of magnitudes the library provides efficient strong types for all angular types. This means that with the built-in support for magnitudes of \\(\\pi\\) we can provide accurate conversions between radians and degrees. The library also provides common trigonometric functions for angular quantities:
using namespace mp_units::si::unit_symbols;\nusing mp_units::angular::unit_symbols::rad;\nusing mp_units::angular::unit_symbols::deg;\nusing mp_units::angular::unit_symbols::grad;\n\nquantity speed = 110 * km / h;\nquantity rate_of_climb = -0.63657 * m / s;\nquantity glide_ratio = speed / -rate_of_climb;\nquantity glide_angle = angular::asin(1 / glide_ratio);\n\nstd::println(\"Glide ratio: {::N[.1f]}\", glide_ratio.in(one));\nstd::println(\"Glide angle:\");\nstd::println(\" - {::N[.4f]}\", glide_angle.in(rad));\nstd::println(\" - {::N[.2f]}\", glide_angle.in(deg));\nstd::println(\" - {::N[.2f]}\", glide_angle.in(grad));\nThe above program prints:
Glide ratio: 48.0\nGlide angle:\n - 0.0208 rad\n - 1.19\u00b0\n - 1.33\u1d4d\nNote
In the production code the above speed and rate_of_climb quantities should probably be modelled as separate typed quantities of the same kind.
Angular quantities are not the only ones with such a \"strange\" behavior. Another but a similar case is a storage capacity quantity specified in IEC-80000-13 that again allows expressing it in both one and bit units.
Those cases make dimensionless quantities an exceptional tree in the library. This is the only quantity hierarchy that contains more than one quantity kind in its tree:
flowchart TD\n dimensionless[\"dimensionless\\n[one]\"]\n dimensionless --- rotation\n dimensionless --- efficiency\n dimensionless --- angular_measure[\"angular_measure\\n[rad]\"]\n angular_measure --- rotational_displacement\n angular_measure --- phase_angle\n dimensionless --- solid_angular_measure[\"solid_angular_measure\\n[sr]\"]\n dimensionless --- drag_factor\n dimensionless --- storage_capacity[\"storage_capacity\\n[bit]\"] --- equivalent_binary_storage_capacity\n dimensionless --- ...To provide such support in the library, we provided an is_kind specifier that can be appended to the quantity specification:
inline constexpr struct angular_measure final : quantity_spec<dimensionless, arc_length / radius, is_kind> {} angular_measure;\ninline constexpr struct solid_angular_measure final : quantity_spec<dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;\ninline constexpr struct storage_capacity final : quantity_spec<dimensionless, is_kind> {} storage_capacity;\ninline constexpr struct angular_measure final : quantity_spec<angular_measure, dimensionless, arc_length / radius, is_kind> {} angular_measure;\ninline constexpr struct solid_angular_measure final : quantity_spec<solid_angular_measure, dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;\ninline constexpr struct storage_capacity final : quantity_spec<storage_capacity, dimensionless, is_kind> {} storage_capacity;\nQUANTITY_SPEC(angular_measure, dimensionless, arc_length / radius, is_kind);\nQUANTITY_SPEC(solid_angular_measure, dimensionless, area / pow<2>(radius), is_kind);\nQUANTITY_SPEC(storage_capacity, dimensionless, is_kind);\nWith the above, we can constrain radian, steradian, and bit to be allowed for usage with specific quantity kinds only:
inline constexpr struct radian final : named_unit<\"rad\", metre / metre, kind_of<isq::angular_measure>> {} radian;\ninline constexpr struct steradian final : named_unit<\"sr\", square(metre) / square(metre), kind_of<isq::solid_angular_measure>> {} steradian;\ninline constexpr struct bit final : named_unit<\"bit\", one, kind_of<storage_capacity>> {} bit;\nbut still allow the usage of one and its scaled versions for such quantities.
In most libraries, physical constants are implemented as constant (possibly constexpr) quantity values. Such an approach has some disadvantages, often affecting the run time performance and causing a loss of precision.
When dealing with equations involving physical constants, they often occur more than once in an expression. Such a constant may appear both in a numerator and denominator of a quantity equation. As we know from fundamental physics, we can simplify such an expression by striking a constant out of the equation. Supporting such behavior allows a faster runtime performance and often a better precision of the resulting value.
"},{"location":"users_guide/framework_basics/faster_than_lightspeed_constants/#physical-constants-as-units","title":"Physical constants as units","text":"The mp-units library allows and encourages the implementation of physical constants as regular units. With that, the constant's value is handled at compile-time, and under favorable circumstances, it can be simplified in the same way as all other repeated units do. If it is not simplified, the value is stored in a type, and the expensive multiplication or division operations can be delayed in time until a user selects a specific unit to represent/print the data.
Such a feature often also allows using simpler or faster representation types in the equation. For example, instead of always having to multiply a small integral value with a big floating-point constant number, we can just use the integral type all the way. Only in case a constant will not simplify in the equation, and the user will require a specific unit, such a multiplication will be lazily invoked, and the representation type will need to be expanded to facilitate that. With that, addition, subtractions, multiplications, and divisions will always be the fastest - compiled away or done in out-of-order execution.
To benefit from all of the above, in the mp-units library, SI defining and other constants are implemented as units in the following way:
namespace si {\n\nnamespace si2019 {\n\ninline constexpr struct speed_of_light_in_vacuum final :\n named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\n\n} // namespace si2019\n\ninline constexpr struct magnetic_constant final :\n named_unit<{u8\"\u03bc\u2080\", \"u_0\"}, mag<4> * mag_pi * mag_power<10, -7> * henry / metre> {} magnetic_constant;\n\n} // namespace mp_units::si\nWith the above definitions, we can calculate vacuum permittivity as:
constexpr auto permeability_of_vacuum = 1. * si::magnetic_constant;\nconstexpr auto speed_of_light_in_vacuum = 1 * si::si2019::speed_of_light_in_vacuum;\n\nQuantityOf<isq::permittivity_of_vacuum> auto q = 1 / (permeability_of_vacuum * pow<2>(speed_of_light_in_vacuum));\n\nstd::println(\"permittivity of vacuum = {} = {::N[.3e]}\", q, q.in(F / m));\nThe above first prints the following:
permittivity of vacuum = 1 \u03bc\u2080\u207b\u00b9 c\u207b\u00b2 = 8.854e-12 F/m\nAs we can clearly see, all the calculations above were just about multiplying and dividing the number 1 with the rest of the information provided as a compile-time type. Only when a user wants a specific SI unit as a result, the unit ratios are lazily resolved.
Another similar example can be an equation for total energy:
QuantityOf<isq::mechanical_energy> auto total_energy(QuantityOf<isq::momentum> auto p,\n QuantityOf<isq::mass> auto m,\n QuantityOf<isq::speed> auto c)\n{\n return isq::mechanical_energy(sqrt(pow<2>(p * c) + pow<2>(m * pow<2>(c))));\n}\nconstexpr auto GeV = si::giga<si::electronvolt>;\nconstexpr QuantityOf<isq::speed> auto c = 1. * si::si2019::speed_of_light_in_vacuum;\nconstexpr auto c2 = pow<2>(c);\n\nconst auto p1 = isq::momentum(4. * GeV / c);\nconst QuantityOf<isq::mass> auto m1 = 3. * GeV / c2;\nconst auto E = total_energy(p1, m1, c);\n\nstd::cout << \"in `GeV` and `c`:\\n\"\n << \"p = \" << p1 << \"\\n\"\n << \"m = \" << m1 << \"\\n\"\n << \"E = \" << E << \"\\n\";\n\nconst auto p2 = p1.in(GeV / (m / s));\nconst auto m2 = m1.in(GeV / pow<2>(m / s));\nconst auto E2 = total_energy(p2, m2, c).in(GeV);\n\nstd::cout << \"\\nin `GeV`:\\n\"\n << \"p = \" << p2 << \"\\n\"\n << \"m = \" << m2 << \"\\n\"\n << \"E = \" << E2 << \"\\n\";\n\nconst auto p3 = p1.in(kg * m / s);\nconst auto m3 = m1.in(kg);\nconst auto E3 = total_energy(p3, m3, c).in(J);\n\nstd::cout << \"\\nin SI base units:\\n\"\n << \"p = \" << p3 << \"\\n\"\n << \"m = \" << m3 << \"\\n\"\n << \"E = \" << E3 << \"\\n\";\nThe above prints the following:
in `GeV` and `c`:\np = 4 GeV/c\nm = 3 GeV/c\u00b2\nE = 5 GeV\n\nin `GeV`:\np = 1.33426e-08 GeV s/m\nm = 3.33795e-17 GeV s\u00b2/m\u00b2\nE = 5 GeV\n\nin SI base units:\np = 2.13771e-18 kg m/s\nm = 5.34799e-27 kg\nE = 8.01088e-10 J\nUsing a concrete unit in the interface often makes a lot of sense. It is especially useful if we store the data internally in the object. In such a case, we have to select a specific unit anyway.
For example, let's consider a simple storage tank:
class StorageTank {\n quantity<horizontal_area[m2]> base_;\n quantity<isq::height[m]> height_;\n quantity<isq::mass_density[kg / m3]> density_ = air_density;\npublic:\n constexpr StorageTank(const quantity<horizontal_area[m2]>& base, const quantity<isq::height[m]>& height) :\n base_(base), height_(height)\n {\n }\n\n // ...\n};\nAs the quantities provided in the function's interface are then stored in the class, there is probably no sense in using generic interfaces here.
"},{"location":"users_guide/framework_basics/generic_interfaces/#the-issues-with-unit-specific-interfaces","title":"The issues with unit-specific interfaces","text":"However, in many cases, using a specific unit in the interface is counterproductive. Let's consider the following function:
quantity<km / h> avg_speed(quantity<km> distance, quantity<h> duration)\n{\n return distance / duration;\n}\nEverything seems fine for now. It also works great if we call it with:
quantity<km / h> s1 = avg_speed(220 * km, 2 * h);\nHowever, if the user starts doing the following:
quantity<mi / h> s2 = avg_speed(140 * mi, 2 * h);\nquantity<m / s> s3 = avg_speed(20 * m, 2 * s);\nsome issues start to be clearly visible:
km/h, another potentially expensive multiplication/division operations must be performed to convert the resulting quantity into a unit being the derived unit of the initial function's arguments.We have to use a floating-point representation type (the quantity class template by default uses double as a representation type) which is considered value-preserving. Trying to use an integral type in this scenario will work only for s1, while s2 and s3 will fail to compile. Failing to compile is a good thing here as the library tries to prevent the user from doing a clearly wrong thing. To make the code compile, the user needs to use dedicated value_cast or force_in like this:
quantity<isq::speed[mi / h]> s2 = avg_speed(value_cast<km>(140 * mi), 2 * h);\nquantity<isq::speed[m / s]> s3 = avg_speed((20 * m).force_in(km), (2 * s).force_in(h));\nbut the above will obviously provide an incorrect behavior (e.g., division by 0 in the evaluation of s3).
A naive solution here would be to implement the function as an unconstrained function template:
auto avg_speed(auto distance, auto duration)\n{\n return distance / duration;\n}\nBeware, this is not a good solution. The above code is too generic. Such a function template accepts everything:
double arguments,std::vector and std::lock_guard will be accepted as well (of course, this will fail in the instantiation of a function's body later in the compilation process).Note
The usage of auto instead of a function parameter type is a C++20 feature. It makes such a code a function template where the type of such a parameter will be deduced during the template instantiation process from the argument type passed by the user.
Much better generic code can be implemented using basic concepts provided with the library:
Original template notationThe shorthand notationTerse notationtemplate<typename Distance, typename Duration>\n requires QuantityOf<Distance, isq::length> && QuantityOf<Duration, isq::time>\nauto avg_speed(Distance distance, Duration duration)\n{\n return isq::speed(distance / duration);\n}\ntemplate<QuantityOf<isq::length> Distance, QuantityOf<isq::time> Duration>\nauto avg_speed(Distance distance, Duration duration)\n{\n return isq::speed(distance / duration);\n}\nauto avg_speed(QuantityOf<isq::length> auto distance,\n QuantityOf<isq::time> auto duration)\n{\n return isq::speed(distance / duration);\n}\nThis explicitly states that the arguments passed by the user must not only satisfy a Quantity concept, but also their quantity specification must be implicitly convertible to isq::length and isq::time accordingly. This no longer leaves room for error while still allowing the compiler to generate the most efficient code.
Tip
Please note that now it is safe just to use integral types all the way which again improves the runtime performance as the multiplication/division operations are often faster on the integral rather than floating-point types.
"},{"location":"users_guide/framework_basics/generic_interfaces/#constraining-function-template-return-type","title":"Constraining function template return type","text":"The above function template resolves all of the issues described before. However, we can do even better here by additionally constraining the return type:
QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto distance,\n QuantityOf<isq::time> auto duration)\n{\n return isq::speed(distance / duration);\n}\nDoing so has two important benefits:
auto, which does not provide any hint about the thing being returned there.If we know precisely what the function does in its internals and if we know the exact argument types passed to such a function, we often know the exact type that will be returned from its invocation.
However, if we care about performance, we should often use the generic interfaces described in this chapter. A side effect is that we sometimes are unsure about the return type. Even if we know it today, it might change a week from now due to some code refactoring.
In such cases, we can again use auto to denote the type:
auto s1 = avg_speed(220 * km, 2 * h);\nauto s2 = avg_speed(140 * mi, 2 * h);\nauto s3 = avg_speed(20 * m, 2 * s);\nor benefit from CTAD:
quantity s1 = avg_speed(220 * km, 2 * h);\nquantity s2 = avg_speed(140 * mi, 2 * h);\nquantity s3 = avg_speed(20 * m, 2 * s);\nIn both cases, it is probably OK to do so as the avg_speed function name explicitly provides the information on what to expect as a result.
In other scenarios where the returned quantity type is not so obvious, it is again helpful to constrain the type with a concept like so:
QuantityOf<isq::speed> auto s1 = avg_speed(220 * km, 2 * h);\nQuantityOf<isq::speed> auto s2 = avg_speed(140 * mi, 2 * h);\nQuantityOf<isq::speed> auto s3 = avg_speed(20 * m, 2 * s);\nThe above explicitly provides additional information about the quantity we are dealing with in the code, and it serves as a unit test checking if the \"thing\" returned from a function is actually what we expected here.
Note
The QuantityOf and QuantityPointOf concepts are probably the most useful, but there are a few more to play with. A list of all the concepts can be found in the Basic Concepts chapter.
The mp-units library decided to use a rather unusual pattern to define entities. Here is how we define metre and second SI base units:
inline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\ninline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\nPlease note that the above reuses the same identifier for a type and its value. The rationale behind this is that:
Important
To improve compiler errors' readability and make it easier to correlate them with a user's written code, a new idiom in the library is to use the same identifier for a type and its instance.
Also, to prevent possible issues in compile-time logic, all of the library's entities must be marked final. This prevents the users to derive own strong types from them, which would prevent expression template simplification of equivalent entities.
Let's look again at the above units definitions. Another important point to notice is that all the types describing entities in the library are short, nicely named identifiers that derive from longer, more verbose class template instantiations. This is really important to improve the user experience while debugging the program or analyzing the compilation error.
Note
Such a practice is rare in the industry. Some popular C++ physical units libraries generate enormously long error messages where even only the first line failed to fit on a slide with a tiny font.
"},{"location":"users_guide/framework_basics/interface_introduction/#entities-composability","title":"Entities composability","text":"Many physical units libraries (in C++ or any other programming language) assign strong types to library entities (e.g., derived units). While metre_per_second as a type may not look too scary, consider, for example, units of angular momentum. If we followed this path, its coherent unit would look like kilogram_metre_sq_per_second. Now, consider how many scaled versions of this unit you would predefine in the library to ensure that all users are happy with your choice? How expensive would it be from the implementation point of view? What about potential future standardization efforts?
This is why in mp-units, we put a strong requirement to make everything as composable as possible. For example, to create a quantity with a unit of speed, one may write:
quantity<si::metre / si::second> q;\nIn case we use such a unit often and would prefer to have a handy helper for it, we can always do something like this:
constexpr auto metre_per_second = si::metre / si::second;\nquantity<metre_per_second> q;\nor choose any shorter identifier of our choice.
Coming back to the angular momentum case, thanks to the composability of units, a user can create such a quantity in the following way:
using namespace mp_units::si::unit_symbols;\nauto q = la_vector{1, 2, 3} * isq::angular_momentum[kg * m2 / s];\nIt is a much better solution. It is terse and easy to understand. Please also notice how easy it is to obtain any scaled version of such a unit (e.g., mg * square(mm) / min) without having to introduce hundreds of types to predefine them.
The mp-units library is based on C++20, significantly improving user experience. One of such improvements is the usage of value-based equations.
As we have learned above, the entities are being used as values in the code, and they compose. Moreover, derived entities can be defined in the library using such value-based equations. This is a huge improvement compared to what we can find in other physical units libraries or what we have to deal with when we want to write some equations for std::ratio.
For example, below are a few definitions of the SI derived units showing the power of C++20 extensions to Non-Type Template Parameters, which allow us to directly pass a result of the value-based unit equation to a class template definition:
inline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\ninline constexpr struct pascal final : named_unit<\"Pa\", newton / square(metre)> {} pascal;\ninline constexpr struct joule final : named_unit<\"J\", newton * metre> {} joule;\nThe previous chapter provided a rationale for not having predefined types for derived entities. In many libraries, such an approach results in long and unreadable compilation errors, as framework-generated types are typically far from being easy to read and understand.
The mp-units library greatly improves the user experience by extensively using expression templates. Such expressions are used consistently throughout the entire library to describe the results of:
derived_dimension<> class templatederived_quantity_spec<> class templatederived_unit<> class templateFor example, if we take the above-defined base units and put the results of their division into the quantity class template like this:
quantity<metre / second> q;\nwe will observe the following type in the debugger
(gdb) ptype q\ntype = class mp_units::quantity<mp_units::derived_unit<metre, mp_units::per<second>>(), double> [with Rep = double] {\nThe same type identifier will be visible in the compilation error (in case it happens).
Important
Expressions templates are extensively used throughout the library to improve the readability of the resulting types.
"},{"location":"users_guide/framework_basics/interface_introduction/#identities","title":"Identities","text":"As mentioned above, equations can be performed on dimensions, quantities, and units. Each such domain must introduce an identity object that can be used in the resulting expressions. Here is the list of identities used in the library:
Domain Concept IdentityDimension dimension_one QuantitySpec dimensionless Unit one In the equations, a user can explicitly refer to an identity object. For example:
constexpr auto my_unit = one / second;\nNote
Another way to achieve the same result is to call an inverse() function:
constexpr auto my_unit = inverse(second);\nBoth cases will result in the same expression template being generated and put into the wrapper class template.
"},{"location":"users_guide/framework_basics/interface_introduction/#supported-operations-and-their-results","title":"Supported operations and their results","text":"There are only a few operations that one can do on such entities, and the result of each of them has its unique representation in the library:
Operation Resulting template expression argumentsA * B A, B B * A A, B A * A power<A, 2> {identity} * A A A * {identity} A A / B A, per<B> A / A {identity} A / {identity} A {identity} / A {identity}, per<A> pow<2>(A) power<A, 2> pow<2>({identity}) {identity} sqrt(A) or pow<1, 2>(A) power<A, 1, 2> sqrt({identity}) or pow<1, 2>({identity}) {identity}"},{"location":"users_guide/framework_basics/interface_introduction/#simplifying-the-resulting-expression-templates","title":"Simplifying the resulting expression templates","text":"To limit the length and improve the readability of generated types, there are many rules to simplify the resulting expression template.
Ordering
The resulting comma-separated arguments of multiplication are always sorted according to a specific predicate. This is why:
static_assert(A * B == B * A);\nstatic_assert(std::is_same_v<decltype(A * B), decltype(B * A)>);\nThis is probably the most important of all the steps, as it allows comparing types and enables the rest of the simplification rules.
Aggregation
In case two of the same identifiers are found next to each other on the argument list they will be aggregated in one entry:
Before AfterA, A power<A, 2> A, power<A, 2> power<A, 3> power<A, 1, 2>, power<A, 2> power<A, 5, 2> power<A, 1, 2>, power<A, 1, 2> A Simplification
In case two of the same identifiers are found in the numerator and denominator argument lists; they are being simplified into one entry:
Before AfterA, per<A> {identity} power<A, 2>, per<A> A power<A, 3>, per<A> power<A, 2> A, per<power<A, 2>> {identity}, per<A> It is important to notice here that only the elements with exactly the same type are being simplified. This means that, for example, m/m results in one, but km/m will not be simplified. The resulting derived unit will preserve both symbols and their relative magnitude. This allows us to properly print symbols of some units or constants that require such behavior. For example, the Hubble constant is expressed in km\u22c5s\u207b\u00b9\u22c5Mpc\u207b\u00b9, where both km and Mpc are units of length.
Also, to prevent possible issues in compile-time logic, all of the library's entities must be marked final. This prevents the users to derive own strong types from them, which would prevent expression template simplification of equivalent entities.
Repacking
In case an expression uses two results of other operations, the components of its arguments are repacked into one resulting type and simplified there.
For example, assuming:
constexpr auto X = A / B;\nthen:
Operation Resulting template expression argumentsX * B A X * A power<A, 2>, per<B> X * X power<A, 2>, per<power<B, 2>> X / X {identity} X / A {identity}, per<B> X / B A, per<power<B, 2>> Thanks to all of the features described above, a user may write the code like this one:
using namespace mp_units::si::unit_symbols;\nquantity speed = 60. * isq::speed[km / h];\nquantity duration = 8 * s;\nquantity acceleration = speed / duration;\nstd::cout << \"acceleration: \" << acceleration << \" (\" << acceleration.in(m / s2) << \")\\n\";\nThe acceleration quantity, being the result of the above code, has the following type (after stripping the mp_units namespace for brevity):
quantity<reference<derived_quantity_spec<isq::speed, per<isq::time>>{}, derived_unit<si::kilo_<si::metre{}>, per<non_si::hour, si::second>>{}>{}, int>\nand the text output presents:
acceleration: 7.5 km h\u207b\u00b9 s\u207b\u00b9 (2.08333 m/s\u00b2)\nquantity is a numeric wrapper","text":"If we think about it, the quantity class template is just a \"smart\" numeric wrapper. It exposes properly constrained set of arithmetic operations on one or two operands.
Important: quantity propagates the underlying interface
Every single arithmetic operator is exposed by the quantity class template only if the underlying representation type provides it as well, and when its implementation has proper semantics (e.g., returns a reasonable type).
For example, in the following code, -a will compile only if MyInt exposes such an operation as well:
quantity a = MyInt{42} * m;\nquantity b = -a;\nAssuming that:
q is our quantity,qi is a quantity implicitly convertible to q,qk is a quantity of the same kind as q,q1 is a quantity of dimension_one with the unit one,qq is any other quantity,number is a value of a type \"compatible\" with q's representation type,here is the list of all the supported operators:
+q-q++qq++--qq--q += qiq -= qiq %= qiq *= numberq *= q1q /= numberq /= q1q + qkq - qkq % qkq * qqq * numbernumber * qq / qqq / numbernumber / qq == qkq <=> qkAs we can see, there are plenty of operations one can do on a value of a quantity type. As most of them are obvious, in the following chapters, we will discuss only the most important or non-trivial aspects of quantity arithmetics.
Quantities can easily be added or subtracted from each other:
static_assert(1 * m + 1 * m == 2 * m);\nstatic_assert(2 * m - 1 * m == 1 * m);\nstatic_assert(isq::height(1 * m) + isq::height(1 * m) == isq::height(2 * m));\nstatic_assert(isq::height(2 * m) - isq::height(1 * m) == isq::height(1 * m));\nThe above uses the same types for LHS, RHS, and the result, but in general, we can add, subtract, or compare the values of any quantity type as long as both quantities are of the same kind. The result of such an operation will be the common type of the arguments:
static_assert(1 * km + 1.5 * m == 1001.5 * m);\nstatic_assert(isq::height(1 * m) + isq::width(1 * m) == isq::length(2 * m));\nstatic_assert(isq::height(2 * m) - isq::distance(0.5 * m) == 1.5 * m);\nstatic_assert(isq::radius(1 * m) - 0.5 * m == isq::radius(0.5 * m));\nNote
Please note that for the compound assignment operators, both arguments have to either be of the same type or the RHS has to be implicitly convertible to the LHS, as the type of LHS is always the result of such an operation:
static_assert((1 * m += 1 * km) == 1001 * m);\nstatic_assert((isq::height(1.5 * m) -= 1 * m) == isq::height(0.5 * m));\nIf we break those rules, the following code will not compile:
static_assert((1 * m -= 0.5 * m) == 0.5 * m); // Compile-time error(1)\nstatic_assert((1 * km += 1 * m) == 1001 * m); // Compile-time error(2)\nstatic_assert((isq::height(1 * m) += isq::length(1 * m)) == 2 * m); // Compile-time error(3)\nMultiplying or dividing a quantity by a number does not change its quantity type or unit. However, its representation type may change. For example:
static_assert(isq::height(3 * m) * 0.5 == isq::height(1.5 * m));\nNote
Unless we use a compound assignment operator, in which case truncating operations are again not allowed:
static_assert((isq::height(3 * m) *= 0.5) == isq::height(1.5 * m)); // Compile-time error(1)\nHowever, suppose we multiply or divide quantities of the same or different types or we divide a raw number by a quantity. In that case, we most probably will end up in a quantity of yet another type:
static_assert(120 * km / (2 * h) == 60 * km / h);\nstatic_assert(isq::width(2 * m) * isq::length(2 * m) == isq::area(4 * m2));\nstatic_assert(50 / isq::time(1 * s) == isq::frequency(50 * Hz));\nNote
An exception from the above rule happens when one of the arguments is a dimensionless quantity. If we multiply or divide by such a quantity, the quantity type will not change. If such a quantity has a unit one, also the unit of a quantity will not change:
static_assert(120 * m / (2 * one) == 60 * m);\nAn interesting special case happens when we divide the same quantity kinds or multiply a quantity by its inverted type. In such a case, we end up with a dimensionless quantity.
static_assert(isq::height(4 * m) / isq::width(2 * m) == 2 * one); // (1)!\nstatic_assert(5 * h / (120 * min) == 0 * one); // (2)!\nstatic_assert(5. * h / (120 * min) == 2.5 * one);\nisq::height / isq::width, which is a quantity of the dimensionless kind.0 * dimensionless[h / min]. To be consistent with the division of different quantity types, we do not convert quantity values to a common unit before the division.Important: Beware of integral division
The physical units library can't do any runtime branching logic for the division operator. All logic must be done at compile-time when the actual values are unknown, and the quantity types can't change at runtime.
If we expect 120 * km / (2 * h) to return 60 km / h, we have to agree with the fact that 5 * km / (24 * h) returns 0 km/h. We can't do a range check at runtime to dynamically adjust scales and types based on the values of provided function arguments.
This is why we often prefer floating-point representation types when dealing with units. Some popular physical units libraries even forbid integer division at all.
"},{"location":"users_guide/framework_basics/quantity_arithmetics/#modulo","title":"Modulo","text":"Now that we know how addition, subtraction, multiplication, and division work, it is time to discuss modulo. What would we expect to be returned from the following quantity equation?
auto q = 5 * h % (120 * min);\nMost of us would probably expect to see 1 h or 60 min as a result. And this is where the problems start.
C++ language defines its / and % operators with the quotient-remainder theorem:
q = a / b;\nr = a % b;\nq * b + r == a;\nThe important property of the modulo operation is that it only works for integral representation types (it is undefined what modulo for floating-point types means). However, as we saw in the previous chapter, integral types are tricky because they often truncate the value.
From the quotient-remainder theorem, the result of modulo operation is r = a - q * b. Let's see what we get from such a quantity equation on integral representation types:
const quantity a = 5 * h;\nconst quantity b = 120 * min;\nconst quantity q = a / b;\nconst quantity r = a - q * b;\n\nstd::cout << \"reminder: \" << r << \"\\n\";\nThe above code outputs:
reminder: 5 h\nAnd now, a tough question needs an answer. Do we really want modulo operation on physical units to be consistent with the quotient-remainder theorem and return 5 h for 5 * h % (120 * min)?
This is exactly why we decided not to follow this hugely surprising path in the mp-units library. The selected approach was also consistent with the feedback from the C++ experts. For example, this is what Richard Smith said about this issue:
Richard Smith
I think the quotient-remainder property is a less important motivation here than other factors -- the constraints on % and / are quite different, so they lack the inherent connection they have for integers. In particular, I would expect that A / B works for all quantities A and B, whereas A % B is only meaningful when A and B have the same dimension. It seems like a nice-to-have for the property to apply in the case where both / and % are defined, but internal consistency of / across all cases seems much more important to me.
I would expect 61 min % 1 h to be 1 min, and 1 h % 59 min to also be 1 min, so my intuition tells me that the result type of A % B, where A and B have the same dimension, should have the smaller unit of A and B (and if the smaller one doesn't divide the larger one, we should either use the gcd / std::common_type of the units of A and B or perhaps just produce an error). I think any other behavior for % is hard to defend.
On the other hand, for division it seems to me that the choice of unit should probably not affect the result, and so if we want that 5 mm / 120 min = 0 mm/min, then 5 h / 120 min == 0 hc (where hc is a dimensionless \"hexaconta\", or 60x, unit). I don't like the idea of taking SI base units into account; that seems arbitrary and like it would do the wrong thing as often as it does the right thing, especially when the units have a multiplier that is very large or small. We could special-case the situation of a dimensionless quantity, but that could lead to problematic overflow pretty easily: a calculation such as 10 s * 5 GHz * 2 uW would overflow an int if it produces a dimensionless quantity for 10 s * 5 GHz, but it could equally produce 50 G * 2 uW = 100 kW without any overflow, and presumably would if the terms were merely reordered.
If people want to use integer-valued quantities, I think it's fundamental that you need to know what the units of the result of an operation will be, and take that into account in how you express computations; the simplest rule for heterogeneous operators like * or / seems to be that the units of the result are determined by applying the operator to the units of the operands -- and for homogeneous operators like + or %, it seems like the only reasonable option is that you get the std::common_type of the units of the operands.
To summarize, the modulo operation on physical units has more in common with addition and division operators than with the quotient-remainder theorem. To avoid surprising results, the operation uses a common unit to do the calculation and provide its result:
static_assert(5 * h / (120 * min) == 0 * one);\nstatic_assert(5 * h % (120 * min) == 60 * min);\nstatic_assert(61 * min % (1 * h) == 1 * min);\nstatic_assert(1 * h % (59 * min) == 1 * min);\nIn our code, we often want to compare the value of a quantity against zero. For example, we do it every time we want to ensure that we deal with a non-zero or positive value.
We could implement such checks in the following way:
if (q1 / q2 != 0 * m / s)\n // ...\nThe above would work (assuming we are dealing with the quantity of speed) but could be suboptimal if the result of q1 / q2 is not expressed in m / s. To eliminate the need for conversion, we need to write:
if (auto q = q1 / q2; q != q.zero())\n // ...\nbut that is a bit inconvenient, and inexperienced users could be unaware of this technique and its reasons.
For the above reasons, the library provides dedicated interfaces to compare against zero that follow the naming convention of named comparison functions in the C++ Standard Library. The mp-units/compare.h header file exposes the following functions:
is_eq_zerois_neq_zerois_lt_zerois_gt_zerois_lteq_zerois_gteq_zeroThanks to them, to save typing and not pay for unneeded conversions, our check could be implemented as follows:
if (is_neq_zero(q1 / q2))\n // ...\nTip
Those functions will work with any type T that exposes zero() member function returning something comparable to T. Thanks to that, we can use them not only with quantities but also with std::chrono::duration or any other type that exposes such an interface.
This chapter scopes only on the quantity type's operators. However, there are many named math functions taking quantities as arguments. Those can be found in the mp-units/math.h header file. Among others, we can find there the following:
pow(), sqrt(), cbrt(),exp(),abs(),epsilon(),fma(), fmod(), remainder(),isfinite(), isinf(), isnan(),floor(), ceil(), round(),inverse(),hypot(),sin(), cos(), tan(),asin(), acos(), atan(), atan2().In the library, we can also find mp-units/random.h header file with all the pseudo-random number generators working on quantity types.
"},{"location":"users_guide/framework_basics/simple_and_typed_quantities/","title":"Simple and Typed Quantities","text":"ISO defines a quantity as:
Quote
property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
After that, it says:
Quote
A reference can be a measurement unit, a measurement procedure, a reference material, or a combination of such.
"},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#quantity-class-template","title":"quantity class template","text":"In the mp-units library, a quantity is represented with the following class template:
template<Reference auto R,\n RepresentationOf<get_quantity_spec(R).character> Rep = double>\nclass quantity;\nThe concept Reference is satisfied by a type that provides all the domain-specific metadata describing a quantity (besides the representation type and its value). Such a type can be either:
si::metre, m / s),Important
All units in the SI system have an associated quantity type.
A reference type is implicitly created as a result of the following expression:
constexpr auto ref = isq::length[m];\nThe above example results in the following type reference<isq::length(), si::metre()> being instantiated.
As we have two alternative options that satisfy the Reference concept in the mp-units library, we also have two modes of dealing with quantities.
The simple mode might be preferred by many developers. It is all about units. Quantities using this mode have shorter type identifiers, resulting in easier-to-understand error messages and better debugging experience.
Here is a simple example showing how to deal with such quantities:
C++ modulesHeader files#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n quantity<si::second> time)\n{\n return dist / time;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n\n const quantity distance = 110 * km;\n const quantity duration = 2 * h;\n const quantity speed = avg_speed(distance, duration);\n\n std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n distance, duration, speed, speed.in(km / h));\n}\n#include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n quantity<si::second> time)\n{\n return dist / time;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n\n const quantity distance = 110 * km;\n const quantity duration = 2 * h;\n const quantity speed = avg_speed(distance, duration);\n\n std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n distance, duration, speed, speed.in(km / h));\n}\nThe code above prints:
A car driving 110 km in 2 h has an average speed of 15.28 m/s (55 km/h)\nTry it on Compiler Explorer
"},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#user-provided-unit-wrappers","title":"User-provided unit wrappers","text":"Sometimes it might be awkward to type some derived units:
quantity speed = 60 * km / h;\nIn case such a unit is used a lot in the project, a user can easily provide a nicely named wrapper for it with:
constexpr auto kmph = km / h;\nquantity speed = 60 * kmph;\nIn case a user makes an error in a quantity equation and the result of the calculation will not match the function return type, the compiler will detect such an issue at compile-time.
For example, in case we will make the following error:
constexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n quantity<si::second> time)\n{\n return dist * time; // (1)!\n}\nthe following compilation error message will be provided:
error: no viable conversion from returned value of type\n 'quantity<mp_units::derived_unit<mp_units::si::metre, mp_units::si::second>{{{}}}, [...]>'\n to function return type\n 'quantity<mp_units::derived_unit<mp_units::si::metre, mp_units::per<mp_units::si::second>>{{{}}}, [...]>'\n 10 | return dist * time;\n | ^~~~~~~~~~~\nSimple mode is all about and just about units. In case we care about a specific quantity type, typed quantities should be preferred. With this mode, for example, we can specify if we deal with width, height, or radius and ensure we will not assign one to another by accident.
The previous example can be re-typed using typed quantities in the following way:
C++ modulesHeader files#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr quantity<isq::speed[si::metre / si::second]> avg_speed(quantity<isq::length[si::metre]> dist,\n quantity<isq::time[si::second]> time)\n{\n return dist / time;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n\n const quantity distance = isq::distance(110 * km);\n const quantity duration = isq::time(2 * h);\n const quantity speed = avg_speed(distance, duration);\n\n std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n distance, duration, speed, speed.in(km / h));\n}\n#include <mp-units/format.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr quantity<isq::speed[si::metre / si::second]> avg_speed(quantity<isq::length[si::metre]> dist,\n quantity<isq::time[si::second]> time)\n{\n return dist / time;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n\n const quantity distance = isq::distance(110 * km);\n const quantity duration = isq::time(2 * h);\n const quantity speed = avg_speed(distance, duration);\n\n std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n distance, duration, speed, speed.in(km / h));\n}\nA car driving 110 km in 2 h has an average speed of 15.28 m/s (55 km/h)\nTry it on Compiler Explorer
In case we will accidentally make the same calculation error as before, this time, we will get a bit longer error message, this time also containing information about the quantity type:
error: no viable conversion from returned value of type\n 'quantity<reference<get_quantity_spec(metre{}) * struct time{{{}}}, metre{} * second{{}}>{}, [...]>'\n to function return type\n 'quantity<reference<speed{}, derived_unit<metre, per<second>>{}>{}, [...]>'\n 12 | return dist * time;\n | ^~~~~~~~~~~\nAs we can see above, the compilation error is longer but still relatively easy to understand.
"},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#additional-type-safety-with-typed-quantities","title":"Additional type safety with typed quantities","text":"Based on the previous example, it might seem that typed quantities are not that useful, more to type and provide harder-to-understand error messages. It might be true in some cases, but there are scenarios where they offer additional level of safety.
Let's see another example:
C++ modulesHeader files SimpleTyped#include <numbers>\nimport mp_units;\n\nusing namespace mp_units;\n\nclass StorageTank {\n quantity<square(si::metre)> base_;\n quantity<si::metre> height_;\npublic:\n constexpr StorageTank(const quantity<square(si::metre)>& base,\n const quantity<si::metre>& height) :\n base_(base), height_(height)\n {\n }\n\n // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n constexpr CylindricalStorageTank(const quantity<si::metre>& radius,\n const quantity<si::metre>& height) :\n StorageTank(std::numbers::pi * pow<2>(radius), height)\n {\n }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n constexpr RectangularStorageTank(const quantity<si::metre>& length,\n const quantity<si::metre>& width,\n const quantity<si::metre>& height) :\n StorageTank(length * width, height)\n {\n }\n};\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n auto tank = RectangularStorageTank(1'000 * mm, 500 * mm, 200 * mm);\n // ...\n}\n#include <numbers>\nimport mp_units;\n\nusing namespace mp_units;\n\n// add a custom quantity type of kind isq::length\ninline constexpr struct horizontal_length final :\n quantity_spec<isq::length> {} horizontal_length;\n\n// add a custom derived quantity type of kind isq::area\n// with a constrained quantity equation\ninline constexpr struct horizontal_area final :\n quantity_spec<isq::area, horizontal_length * isq::width> {} horizontal_area;\n\nclass StorageTank {\n quantity<horizontal_area[square(si::metre)]> base_;\n quantity<isq::height[si::metre]> height_;\npublic:\n constexpr StorageTank(const quantity<horizontal_area[square(si::metre)]>& base,\n const quantity<isq::height[si::metre]>& height) :\n base_(base), height_(height)\n {\n }\n\n // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n constexpr CylindricalStorageTank(const quantity<isq::radius[si::metre]>& radius,\n const quantity<isq::height[si::metre]>& height) :\n StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n height)\n {\n }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n constexpr RectangularStorageTank(const quantity<horizontal_length[si::metre]>& length,\n const quantity<isq::width[si::metre]>& width,\n const quantity<isq::height[si::metre]>& height) :\n StorageTank(length * width, height)\n {\n }\n};\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n isq::width(500 * mm),\n isq::height(200 * mm));\n // ...\n}\n#include <mp-units/math.h>\n#include <mp-units/systems/si.h>\n#include <numbers>\n\nusing namespace mp_units;\n\nclass StorageTank {\n quantity<square(si::metre)> base_;\n quantity<si::metre> height_;\npublic:\n constexpr StorageTank(const quantity<square(si::metre)>& base,\n const quantity<si::metre>& height) :\n base_(base), height_(height)\n {\n }\n\n // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n constexpr CylindricalStorageTank(const quantity<si::metre>& radius,\n const quantity<si::metre>& height) :\n StorageTank(std::numbers::pi * pow<2>(radius), height)\n {\n }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n constexpr RectangularStorageTank(const quantity<si::metre>& length,\n const quantity<si::metre>& width,\n const quantity<si::metre>& height) :\n StorageTank(length * width, height)\n {\n }\n};\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n auto tank = RectangularStorageTank(1'000 * mm, 500 * mm, 200 * mm);\n // ...\n}\n#include <mp-units/math.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <numbers>\n\nusing namespace mp_units;\n\n// add a custom quantity type of kind isq::length\ninline constexpr struct horizontal_length final :\n quantity_spec<isq::length> {} horizontal_length;\n\n// add a custom derived quantity type of kind isq::area\n// with a constrained quantity equation\ninline constexpr struct horizontal_area final :\n quantity_spec<isq::area, horizontal_length * isq::width> {} horizontal_area;\n\nclass StorageTank {\n quantity<horizontal_area[square(si::metre)]> base_;\n quantity<isq::height[si::metre]> height_;\npublic:\n constexpr StorageTank(const quantity<horizontal_area[square(si::metre)]>& base,\n const quantity<isq::height[si::metre]>& height) :\n base_(base), height_(height)\n {\n }\n\n // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n constexpr CylindricalStorageTank(const quantity<isq::radius[si::metre]>& radius,\n const quantity<isq::height[si::metre]>& height) :\n StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n height)\n {\n }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n constexpr RectangularStorageTank(const quantity<horizontal_length[si::metre]>& length,\n const quantity<isq::width[si::metre]>& width,\n const quantity<isq::height[si::metre]>& height) :\n StorageTank(length * width, height)\n {\n }\n};\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n isq::width(500 * mm),\n isq::height(200 * mm));\n // ...\n}\nIn the above example, the highlighted call doesn't look that safe anymore in the case of simple quantities, right? Suppose someone, either by mistake or due to some refactoring, will call the function with an invalid order of arguments. In that case, the program will compile fine but not work as expected.
Let's see what will happen if we reorder the arguments in the case of typed quantities:
auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n isq::height(200 * mm),\n isq::width(500 * mm));\nThis time, a compiler provides the following compilation error:
<source>:53:15: error: no matching constructor for initialization of 'RectangularStorageTank'\n 53 | auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n 54 | isq::height(200 * mm),\n | ~~~~~~~~~~~~~~~~~~~~~~\n 55 | isq::width(500 * mm));\n | ~~~~~~~~~~~~~~~~~~~~\n<source>:43:13: note: candidate constructor not viable: no known conversion from\n 'quantity<mp_units::reference<mp_units::isq::height{{{{{}}}}},\n mp_units::si::milli_<mp_units::si::metre{{}}>{{{{}}}}>{}, int>' to\n 'const quantity<reference<width{}, metre{}>{}, (default) double>' for 2nd argument\n 43 | constexpr RectangularStorageTank(const quantity<horizontal_length[m]>& length,\n | ^\n 44 | const quantity<isq::width[m]>& width,\n | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nWhat about derived quantities? In the above example, you probably noticed that we also defined a custom horizontal_area quantity of kind isq::area. This quantity has the unique property of being implicitly constructible only from the result of the multiplication of quantities of horizontal_area and isq::width or the ones that implicitly convert to them.
Based on the above error message, we already know that a quantity of isq::height is not implicitly constructible to the quantity of isq::width. This property is transitively passed to derived quantities using them. If by accident, we will try to create a StorageTank base class in the following way:
class RectangularStorageTank : public StorageTank {\npublic:\n constexpr RectangularStorageTank(const quantity<horizontal_length[m]>& length,\n const quantity<isq::width[m]>& width,\n const quantity<isq::height[m]>& height) :\n StorageTank(length * height, height)\n {\n }\n};\nwe will again get a compilation error message like this one:
error: no matching constructor for initialization of 'StorageTank'\n 46 | StorageTank(length * height, height)\n | ^ ~~~~~~~~~~~~~~~~~~~~~~~\n<source>:22:13: note: candidate constructor not viable: no known conversion from\n 'quantity<mp_units::reference<mp_units::derived_quantity_spec<horizontal_length, mp_units::isq::height>{{}, {{}}},\n mp_units::derived_unit<mp_units::power<mp_units::si::metre, 2>>{{{}}}>{}, [...]>' to\n 'const quantity<reference<horizontal_area{}, derived_unit<power<metre, 2>>{}>{}, [...]>' for 1st argument\n 22 | constexpr StorageTank(const quantity<horizontal_area[m2]>& base,\n | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nTip
If you need to use various quantities of the same kind, consider using typed quantities to bring an additional level of safety to your project.
"},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#quantity_cast-to-force-unsafe-conversions","title":"quantity_cast() to force unsafe conversions","text":"Did you notice the quantity_cast() usage in the other child class?
class CylindricalStorageTank : public StorageTank {\npublic:\n constexpr CylindricalStorageTank(const quantity<isq::radius[m]>& radius,\n const quantity<isq::height[m]>& height) :\n StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n height)\n {\n }\n};\nAs isq::radius is not convertible to horizontal_length, the derived quantity of pow<2>(radius) can't be converted to horizontal_area as well. It would be unsafe to allow such a conversion as not all of the circles lie flat on the ground, right?
In such a case, the user has to explicitly force such an unsafe conversion with the help of a quantity_cast(). This function name is easy to spot in code reviews or while searching the project for problems if something goes sideways. In case of unexpected quantities-related issues, this should be the first function to look for.
Tip
Do not overuse quantity_cast(). Use it only when necessary and ensure that the requested conversion is exactly what you need in this case.
We have good news for you if you wonder which mode you should choose for your project. Simple and typed quantity modes can be freely mixed with each other. When you use different quantities of the same kind (e.g., radius, wavelength, altitude, ...), you should probably reach for typed quantities to bring additional safety for those cases. Otherwise, just use simple mode for the remaining quantities. The mp-units library will do its best to protect your project based on the information provided.
Tip
You can easily mix simple and typed quantities in your project.
"},{"location":"users_guide/framework_basics/systems_of_quantities/","title":"Systems of Quantities","text":"The physical units libraries on the market typically only scope on modeling one or more systems of units. However, this is not the only system kind to model. Another, and maybe even more important, system kind is a system of quantities.
Info
Please note that the mp-units is probably the first library on the Open Source market (in any programming language) that models the ISQ with all its definitions provided in ISO 80000. Please provide feedback if something looks odd or could be improved.
"},{"location":"users_guide/framework_basics/systems_of_quantities/#dimension-is-not-enough-to-describe-a-quantity","title":"Dimension is not enough to describe a quantity","text":"Most of the products on the market are aware of physical dimensions. However, a dimension is not enough to describe a quantity. For example, let's see the following implementation:
class Box {\n area base_;\n length height_;\npublic:\n Box(length l, length w, length h) : base_(l * w), height_(h) {}\n // ...\n};\n\nBox my_box(2 * m, 3 * m, 1 * m);\nHow do you like such an interface? It turns out that in most existing strongly-typed libraries this is often the best we can do
Another typical question many users ask is how to deal with work and torque. Both of those have the same dimension but are different quantities.
A similar issue is related to figuring out what should be the result of:
auto res = 1 * Hz + 1 * Bq + 1 * Bd;\nwhere:
Hz (hertz) - unit of frequencyBq (becquerel) - unit of activityBd (baud) - unit of modulation rateAll of those quantities have the same dimension, namely \\(\\mathsf{T}^{-1}\\), but probably it is not wise to allow adding, subtracting, or comparing them, as they describe vastly different physical properties.
If the above example seems too abstract, let's consider a fuel consumption (fuel volume divided by distance, e.g., 6.7 l/km) and an area. Again, both have the same dimension \\(\\mathsf{L}^{2}\\), but probably it wouldn't be wise to allow adding, subtracting, or comparing a fuel consumption of a car and the area of a football field. Such an operation does not have any physical sense and should fail to compile.
Important
More than one quantity may be defined for the same dimension:
It turns out that the above issues can't be solved correctly without proper modeling of a system of quantities.
"},{"location":"users_guide/framework_basics/systems_of_quantities/#quantities-of-the-same-kind","title":"Quantities of the same kind","text":"ISO 80000-1
The above quotes from ISO 80000 provide answers to all the issues above. Two quantities can't be added, subtracted, or compared unless they belong to the same kind. As frequency, activity, and modulation rate are different kinds, the expression provided above should not compile.
"},{"location":"users_guide/framework_basics/systems_of_quantities/#system-of-quantities-is-not-only-about-kinds","title":"System of quantities is not only about kinds","text":"ISO 80000 specify hundreds of different quantities. There are plenty of different kinds provided and often each kind contains more than one quantity. In fact, it turns out that such quantities form a hierarchy of quantities of the same kind.
For example, here are all quantities of the kind length provided in the ISO 80000:
flowchart TD\n length --- width[width, breadth]\n length --- height[height, depth, altitude]\n width --- thickness\n width --- diameter\n width --- radius\n length --- path_length\n path_length --- distance\n distance --- radial_distance\n length --- wavelength\n length --- position_vector[\"position_vector\\n{vector}\"]\n length --- displacement[\"displacement\\n{vector}\"]\n radius --- radius_of_curvatureEach of the above quantities expresses some kind of length, and each can be measured with si::metre. However, each of them has different properties, usage, and sometimes even requires a different representation type (notice that position_vector and displacement are vector quantities).
Such a hierarchy helps us in defining arithmetics and conversion rules for various quantities of the same kind.
"},{"location":"users_guide/framework_basics/systems_of_quantities/#defining-quantities","title":"Defining quantities","text":"In the mp-units library all the information about the quantity is provided with the quantity_spec class template. In order to define a specific quantity a user should inherit a strong type from such an instantiation.
Tip
Quantity specification definitions benefit from an explicit object parameter added in C++23 to remove the need for CRTP idiom, which significantly simplifies the code. However, as C++23 is far from being mainstream today, a portability macro QUANTITY_SPEC() is provided and used consistently through the library to allow the code to compile with C++20 compilers, thanks to the CRTP usage under the hood.
See more in the C++ compiler support chapter.
For example, here is how the above quantity kind tree can be modeled in the library:
C++23C++20Portableinline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct width final : quantity_spec<length> {} width;\ninline constexpr auto breadth = width;\ninline constexpr struct height final : quantity_spec<length> {} height;\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\ninline constexpr struct thickness final : quantity_spec<width> {} thickness;\ninline constexpr struct diameter final : quantity_spec<width> {} diameter;\ninline constexpr struct radius final : quantity_spec<width> {} radius;\ninline constexpr struct radius_of_curvature final : quantity_spec<radius> {} radius_of_curvature;\ninline constexpr struct path_length final : quantity_spec<length> {} path_length;\ninline constexpr auto arc_length = path_length;\ninline constexpr struct distance final : quantity_spec<path_length> {} distance;\ninline constexpr struct radial_distance final : quantity_spec<distance> {} radial_distance;\ninline constexpr struct wavelength final : quantity_spec<length> {} wavelength;\ninline constexpr struct position_vector final : quantity_spec<length, quantity_character::vector> {} position_vector;\ninline constexpr struct displacement final : quantity_spec<length, quantity_character::vector> {} displacement;\ninline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct width final : quantity_spec<width, length> {} width;\ninline constexpr auto breadth = width;\ninline constexpr struct height final : quantity_spec<height, length> {} height;\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\ninline constexpr struct thickness final : quantity_spec<thickness, width> {} thickness;\ninline constexpr struct diameter final : quantity_spec<diameter, width> {} diameter;\ninline constexpr struct radius final : quantity_spec<radius, width> {} radius;\ninline constexpr struct radius_of_curvature final : quantity_spec<radius_of_curvature, radius> {} radius_of_curvature;\ninline constexpr struct path_length final : quantity_spec<path_length, length> {} path_length;\ninline constexpr auto arc_length = path_length;\ninline constexpr struct distance final : quantity_spec<distance, path_length> {} distance;\ninline constexpr struct radial_distance final : quantity_spec<radial_distance, distance> {} radial_distance;\ninline constexpr struct wavelength final : quantity_spec<wavelength, length> {} wavelength;\ninline constexpr struct position_vector final : quantity_spec<position_vector, length, quantity_character::vector> {} position_vector;\ninline constexpr struct displacement final : quantity_spec<displacement, length, quantity_character::vector> {} displacement;\nQUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(width, length);\ninline constexpr auto breadth = width;\nQUANTITY_SPEC(height, length);\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\nQUANTITY_SPEC(thickness, width);\nQUANTITY_SPEC(diameter, width);\nQUANTITY_SPEC(radius, width);\nQUANTITY_SPEC(radius_of_curvature, radius);\nQUANTITY_SPEC(path_length, length);\ninline constexpr auto arc_length = path_length;\nQUANTITY_SPEC(distance, path_length);\nQUANTITY_SPEC(radial_distance, distance);\nQUANTITY_SPEC(wavelength, length);\nQUANTITY_SPEC(position_vector, length, quantity_character::vector);\nQUANTITY_SPEC(displacement, length, quantity_character::vector);\nNote
More information on how to define a system of quantities can be found in the \"International System of Quantities (ISQ)\" chapter.
"},{"location":"users_guide/framework_basics/systems_of_quantities/#comparing-adding-and-subtracting-quantities","title":"Comparing, adding, and subtracting quantities","text":"ISO 80000 explicitly states that width and height are quantities of the same kind, and as such they:
If we take the above for granted, the only reasonable result of 1 * width + 1 * height is 2 * length, where the result of length is known as a common quantity type. A result of such an equation is always the first common node in a hierarchy tree of the same kind. For example:
static_assert(common_quantity_spec(isq::width, isq::height) == isq::length);\nstatic_assert(common_quantity_spec(isq::thickness, isq::radius) == isq::width);\nstatic_assert(common_quantity_spec(isq::distance, isq::path_length) == isq::path_length);\nBased on the same hierarchy of quantities of kind length, we can define quantity conversion rules.
Implicit conversions
static_assert(implicitly_convertible(isq::width, isq::length));\nstatic_assert(implicitly_convertible(isq::radius, isq::width));\nstatic_assert(implicitly_convertible(isq::radius, isq::length));\nExplicit conversions
static_assert(!implicitly_convertible(isq::length, isq::width));\nstatic_assert(!implicitly_convertible(isq::width, isq::radius));\nstatic_assert(!implicitly_convertible(isq::length, isq::radius));\nstatic_assert(explicitly_convertible(isq::length, isq::width));\nstatic_assert(explicitly_convertible(isq::width, isq::radius));\nstatic_assert(explicitly_convertible(isq::length, isq::radius));\nExplicit casts
static_assert(!implicitly_convertible(isq::height, isq::width));\nstatic_assert(!explicitly_convertible(isq::height, isq::width));\nstatic_assert(castable(isq::height, isq::width));\nNo conversion
static_assert(!implicitly_convertible(isq::time, isq::length));\nstatic_assert(!explicitly_convertible(isq::time, isq::length));\nstatic_assert(!castable(isq::time, isq::length));\nDerived quantity equations often do not automatically form a hierarchy tree. This is why it is sometimes not obvious what such a tree should look like. Also, ISO explicitly states:
ISO/IEC Guide 99
The division of \u2018quantity\u2019 according to \u2018kind of quantity\u2019 is, to some extent, arbitrary.
The below presents some arbitrary hierarchy of derived quantities of kind energy:
flowchart TD\n energy[\"energy\\n(mass * length<sup>2</sup> / time<sup>2</sup>)\"]\n energy --- mechanical_energy\n mechanical_energy --- potential_energy\n potential_energy --- gravitational_potential_energy[\"gravitational_potential_energy\\n(mass * acceleration_of_free_fall * height)\"]\n potential_energy --- elastic_potential_energy[\"elastic_potential_energy\\n(spring_constant * amount_of_compression<sup>2</sup>)\"]\n mechanical_energy --- kinetic_energy[\"kinetic_energy\\n(mass * speed<sup>2</sup>)\"]\n energy --- enthalpy\n enthalpy --- internal_energy[internal_energy, thermodynamic_energy]\n internal_energy --- Helmholtz_energy[Helmholtz_energy, Helmholtz_function]\n enthalpy --- Gibbs_energy[Gibbs_energy, Gibbs_function]\n energy --- active_energyNotice, that even though all of those quantities have the same dimension and can be expressed in the same units, they have different quantity equations that can be used to create them implicitly:
energy is the most generic one and thus can be created from base quantities of mass, length, and time. As those are also the roots of quantities of their kinds and all other quantities from their trees are implicitly convertible to them (we agreed on that \"every width is a length\" already), it means that an energy can be implicitly constructed from any quantity of mass, length, and time:
static_assert(implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time), isq::energy));\nstatic_assert(implicitly_convertible(isq::mass * pow<2>(isq::height) / pow<2>(isq::time), isq::energy));\nmechanical energy is a more \"specialized\" quantity than energy (not every energy is a mechanical energy). It is why an explicit cast is needed to convert from either energy or the results of its quantity equation:
static_assert(!implicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n isq::mechanical_energy));\ngravitational potential energy is not only even more specialized one but additionally, it is special in a way that it provides its own \"constrained\" quantity equation. Maybe not every mass * pow<2>(length) / pow<2>(time) is a gravitational potential energy, but every mass * acceleration_of_free_fall * height is.
static_assert(!implicitly_convertible(isq::energy, gravitational_potential_energy));\nstatic_assert(explicitly_convertible(isq::energy, gravitational_potential_energy));\nstatic_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n gravitational_potential_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n gravitational_potential_energy));\nstatic_assert(implicitly_convertible(isq::mass * isq::acceleration_of_free_fall * isq::height,\n gravitational_potential_energy));\nIn the physical units library, we also need an abstraction describing an entire family of quantities of the same kind. Such quantities have not only the same dimension but also can be expressed in the same units.
To annotate a quantity to represent its kind (and not just a hierarchy tree's root quantity) we introduced a kind_of<> specifier. For example, to express any quantity of length, we need to type kind_of<isq::length>.
Important
isq::length and kind_of<isq::length> are two different things.
Such an entity behaves as any quantity of its kind. This means that it is implicitly convertible to any quantity in a tree.
static_assert(!implicitly_convertible(isq::length, isq::height));\nstatic_assert(implicitly_convertible(kind_of<isq::length>, isq::height));\nAdditionally, the result of operations on quantity kinds is also a quantity kind:
static_assert(same_type<kind_of<isq::length> / kind_of<isq::time>, kind_of<isq::length / isq::time>>);\nHowever, if at least one equation's operand is not a quantity kind, the result becomes a \"strong\" quantity where all the kinds are converted to the hierarchy tree's root quantities:
static_assert(!same_type<kind_of<isq::length> / isq::time, kind_of<isq::length / isq::time>>);\nstatic_assert(same_type<kind_of<isq::length> / isq::time, isq::length / isq::time>);\nInfo
Only a root quantity from the hierarchy tree or the one marked with is_kind specifier in the quantity_spec definition can be put as a template parameter to the kind_of specifier. For example, kind_of<isq::width> will fail to compile. However, we can call get_kind(q) to obtain a kind of any quantity:
static_assert(get_kind(isq::width) == kind_of<isq::length>);\nModeling a system of units is probably the most important feature and a selling point of every physical units library. Thanks to that, the library can protect users from performing invalid operations on quantities and provide automated conversion factors between various compatible units.
Probably all the libraries in the wild model the SI and many of them provide support for additional units belonging to various other systems (e.g., imperial, cgs, etc).
"},{"location":"users_guide/framework_basics/systems_of_units/#systems-of-units-are-based-on-systems-of-quantities","title":"Systems of Units are based on Systems of Quantities","text":"Systems of quantities specify a set of quantities and equations relating to those quantities. Those equations do not take any unit or a numerical representation into account at all. To create a quantity, we need to add those missing pieces of information. This is where a system of units kicks in.
The SI is explicitly stated to be based on the ISQ. Among others, it defines 7 base units, one for each base quantity. In the mp-units this is expressed by associating a quantity kind (that we discussed in detail in the previous chapter) with a unit that is used to express it:
inline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\nImportant
The kind_of<isq::length> above states explicitly that this unit has an associated quantity kind. In other words, si::metre (and scaled units based on it) can be used to express the amount of any quantity of kind length.
One of the most vital points of the SI system is that its units compose. This allows providing thousands of different units for hundreds of various quantities with a tiny set of predefined units and prefixes.
The same is modeled in the mp-units library, which also allows composing predefined units to create a nearly infinite number of different derived units. For example, one can write:
quantity<si::metre / si::second> q;\nto express a quantity of speed. The resulting quantity type is implicitly inferred from the unit equation by repeating the same operations on the associated quantity kinds.
"},{"location":"users_guide/framework_basics/systems_of_units/#many-shades-of-the-same-unit","title":"Many shades of the same unit","text":"The SI provides the names for 22 common coherent units of 22 derived quantities.
Each such named derived unit is a result of a specific predefined unit equation. For example, a unit of power quantity is defined in the library as:
inline constexpr struct watt final : named_unit<\"W\", joule / second> {} watt;\nHowever, a power quantity can be expressed in other units as well. For example, the following:
auto q1 = 42 * W;\nstd::cout << q1 << \"\\n\";\nstd::cout << q1.in(J / s) << \"\\n\";\nstd::cout << q1.in(N * m / s) << \"\\n\";\nstd::cout << q1.in(kg * m2 / s3) << \"\\n\";\nprints:
42 W\n42 J/s\n42 N m/s\n42 kg m\u00b2/s\u00b3\nAll of the above quantities are equivalent and mean exactly the same.
"},{"location":"users_guide/framework_basics/systems_of_units/#constraining-a-derived-unit-to-work-only-with-a-specific-derived-quantity","title":"Constraining a derived unit to work only with a specific derived quantity","text":"Some derived units are valid only for specific derived quantities. For example, SI specifies both hertz and becquerel derived units with the same unit equation 1 / s. However, it also explicitly states:
SI Brochure
The hertz shall only be used for periodic phenomena and the becquerel shall only be used for stochastic processes in activity referred to a radionuclide.
The above means that the usage of becquerel as a unit of a frequency quantity is an error.
The library allows constraining such units to work only with quantities of a specific kind in the following way:
inline constexpr struct hertz final : named_unit<\"Hz\", one / second, kind_of<isq::frequency>> {} hertz;\ninline constexpr struct becquerel final : named_unit<\"Bq\", one / second, kind_of<isq::activity>> {} becquerel;\nWith the above, hertz can only be used with frequencies, while becquerel should only be used with quantities of activity. This means that the following equation will not compile:
auto q = 1 * Hz + 1 * Bq; // Fails to compile\nThis is exactly what we wanted to achieve to improve the type-safety of the library.
"},{"location":"users_guide/framework_basics/systems_of_units/#prefixed-units","title":"Prefixed units","text":"Besides named units, the SI specifies also 24 prefixes (all being a power of 10) that can be prepended to all named units to obtain various scaled versions of them.
Implementation of std::ratio provided by all major compilers is able to express only 16 of them. This is why, in the mp-units, we had to find an alternative way to represent unit magnitude in a more flexible way.
Each prefix is implemented similarly to the following:
template<PrefixableUnit U> struct quecto_ : prefixed_unit<\"q\", mag_power<10, -30>, U{}> {};\ntemplate<PrefixableUnit auto U> inline constexpr quecto_<decltype(U)> quecto;\nand then a PrefixableUnit can be prefixed in the following way:
inline constexpr auto qm = quecto<metre>;\nThe usage of mag_power not only enables providing support for SI prefixes, but it can also efficiently represent any rational magnitude. For example, IEC 80000 prefixes used in the IT industry can be implemented as:
template<PrefixableUnit U> struct yobi_ : prefixed_unit<\"Yi\", mag_power<2, 80>, U{}> {};\ntemplate<PrefixableUnit auto U> inline constexpr yobi_<decltype(U)> yobi;\nIn the SI, all units are either base or derived units or prefixed versions of those. However, those are only some of the options possible.
For example, there is a list of off-system units accepted for use with SI. Those are scaled versions of the SI units with ratios that can't be explicitly expressed with predefined SI prefixes. Those include units like minute, hour, or electronvolt:
inline constexpr struct minute final : named_unit<\"min\", mag<60> * si::second> {} minute;\ninline constexpr struct hour final : named_unit<\"h\", mag<60> * minute> {} hour;\ninline constexpr struct electronvolt final : named_unit<\"eV\", mag_ratio<1'602'176'634, 1'000'000'000> * mag_power<10, -19> * si::joule> {} electronvolt;\nAlso, units of other systems of units are often defined in terms of scaled versions of the SI units. For example, the international yard is defined as:
inline constexpr struct yard final : named_unit<\"yd\", mag_ratio<9'144, 10'000> * si::metre> {} yard;\nFor some units, a magnitude might also be irrational. The best example here is a degree which is defined using a floating-point magnitude having a factor of the number \u03c0 (Pi):
inline constexpr struct mag_pi final : magnitude<std::numbers::pi_v<long double>> {} mag_pi;\ninline constexpr struct degree final : named_unit<{u8\"\u00b0\", \"deg\"}, mag_pi / mag<180> * si::radian> {} degree;\nBesides providing dimensional analysis and unit conversions, the library also tries hard to print any quantity in the most user-friendly way. We can print the entire quantity or its selected parts (numerical value, unit, or dimension).
Note
The library does not provide a text output for quantity points. The quantity stored inside is just an implementation detail of this type. It is a vector from a specific origin. Without the knowledge of the origin, the vector by itself is useless as we can't determine which point it describes.
In the current library design, point origin does not provide any text in its definition. Even if we could add such information to the point's definition, we would not know how to output it in the text. There may be many ways to do it. For example, should we prepend or append the origin part to the quantity text?
For example, the text output of 42 m for a quantity point may mean many things. It may be an offset from the mountain top, sea level, or maybe the center of Mars. Printing 42 m AMSL for altitudes above mean sea level is a much better solution, but the library does not have enough information to print it that way by itself.
Please let us know if you have a good idea of how to solve this issue.
"},{"location":"users_guide/framework_basics/text_output/#predefined-symbols","title":"Predefined symbols","text":"The definitions of dimensions, units, prefixes, and constants require assigning text symbols for each entity. Those symbols will be composed by the library's framework to express dimensions and units of derived quantities.
DimensionsUnitsPrefixesConstantsinline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct dim_mass final : base_dimension<\"M\"> {} dim_mass;\ninline constexpr struct dim_time final : base_dimension<\"T\"> {} dim_time;\ninline constexpr struct dim_electric_current final : base_dimension<\"I\"> {} dim_electric_current;\ninline constexpr struct dim_thermodynamic_temperature final : base_dimension<{u8\"\u0398\", \"O\"}> {} dim_thermodynamic_temperature;\ninline constexpr struct dim_amount_of_substance final : base_dimension<\"N\"> {} dim_amount_of_substance;\ninline constexpr struct dim_luminous_intensity final : base_dimension<\"J\"> {} dim_luminous_intensity;\ninline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\ninline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\ninline constexpr struct gram final : named_unit<\"g\", kind_of<isq::mass>> {} gram;\ninline constexpr auto kilogram = kilo<gram>;\n\ninline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\ninline constexpr struct joule final : named_unit<\"J\", newton * metre> {} joule;\ninline constexpr struct watt final : named_unit<\"W\", joule / second> {} watt;\ninline constexpr struct coulomb final : named_unit<\"C\", ampere * second> {} coulomb;\ninline constexpr struct volt final : named_unit<\"V\", watt / ampere> {} volt;\ninline constexpr struct farad final : named_unit<\"F\", coulomb / volt> {} farad;\ninline constexpr struct ohm final : named_unit<{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\ntemplate<PrefixableUnit U> struct micro_ : prefixed_unit<{u8\"\u00b5\", \"u\"}, mag_power<10, -6>, U{}> {};\ntemplate<PrefixableUnit U> struct milli_ : prefixed_unit<\"m\", mag_power<10, -3>, U{}> {};\ntemplate<PrefixableUnit U> struct centi_ : prefixed_unit<\"c\", mag_power<10, -2>, U{}> {};\ntemplate<PrefixableUnit U> struct deci_ : prefixed_unit<\"d\", mag_power<10, -1>, U{}> {};\ntemplate<PrefixableUnit U> struct deca_ : prefixed_unit<\"da\", mag_power<10, 1>, U{}> {};\ntemplate<PrefixableUnit U> struct hecto_ : prefixed_unit<\"h\", mag_power<10, 2>, U{}> {};\ntemplate<PrefixableUnit U> struct kilo_ : prefixed_unit<\"k\", mag_power<10, 3>, U{}> {};\ntemplate<PrefixableUnit U> struct mega_ : prefixed_unit<\"M\", mag_power<10, 6>, U{}> {};\ninline constexpr struct hyperfine_structure_transition_frequency_of_cs final : named_unit<{u8\"\u0394\u03bd_Cs\", \"dv_Cs\"}, mag<9'192'631'770> * hertz> {} hyperfine_structure_transition_frequency_of_cs;\ninline constexpr struct speed_of_light_in_vacuum final : named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\ninline constexpr struct planck_constant final : named_unit<\"h\", mag_ratio<662'607'015, 100'000'000> * mag_power<10, -34> * joule * second> {} planck_constant;\ninline constexpr struct elementary_charge final : named_unit<\"e\", mag_ratio<1'602'176'634, 1'000'000'000> * mag_power<10, -19> * coulomb> {} elementary_charge;\ninline constexpr struct boltzmann_constant final : named_unit<\"k\", mag_ratio<1'380'649, 1'000'000> * mag_power<10, -23> * joule / kelvin> {} boltzmann_constant;\ninline constexpr struct avogadro_constant final : named_unit<\"N_A\", mag_ratio<602'214'076, 100'000'000> * mag_power<10, 23> / mole> {} avogadro_constant;\ninline constexpr struct luminous_efficacy final : named_unit<\"K_cd\", mag<683> * lumen / watt> {} luminous_efficacy;\nImportant
Two symbols always have to be provided if the primary symbol contains characters outside of the basic literal character set. The first must be provided as a UTF-8 literal and may contain any Unicode characters. The second one must provide an alternative spelling and only use characters from within of basic literal character set.
Note
Unicode provides only a minimal set of characters available as subscripts, which are often used to differentiate various constants and quantities of the same kind. To workaround this issue, mp-units uses the '_' character to specify that the following characters should be considered a subscript of the symbol.
Tip
For older compilers, it might be required to specify a symbol_text class explicitly template name to initialize it with two symbols:
inline constexpr struct ohm final : named_unit<symbol_text{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\ntext_encoding","text":"ISQ and SI standards always specify symbols using Unicode encoding. This is why it is a default and primary target for text output. However, in some applications or environments, a standard ASCII-like text output using only the characters from the basic literal character set can be preferred by users.
This is why the library provides an option to change the default encoding to the ASCII one with:
enum class text_encoding : std::int8_t {\n unicode, // \u00b5s; m\u00b3; L\u00b2MT\u207b\u00b3\n ascii, // us; m^3; L^2MT^-3\n default_encoding = unicode\n};\ndimension_symbol_formatting","text":"dimension_symbol_formatting is a data type describing the configuration of the symbol generation algorithm.
struct dimension_symbol_formatting {\n text_encoding encoding = text_encoding::default_encoding;\n};\ndimension_symbol()","text":"Returns a std::string_view with the symbol of a dimension for the provided configuration:
template<dimension_symbol_formatting fmt = dimension_symbol_formatting{}, typename CharT = char, Dimension D>\n[[nodiscard]] consteval std::string_view dimension_symbol(D);\nFor example:
static_assert(dimension_symbol<{.encoding = text_encoding::ascii}>(isq::power.dimension) == \"L^2MT^-3\");\nNote
std::string_view is returned only when C++23 is available. Otherwise, an instance of a basic_fixed_string is being returned.
dimension_symbol_to()","text":"Inserts the generated dimension symbol into the output text iterator at runtime.
template<typename CharT = char, std::output_iterator<CharT> Out, Dimension D>\nconstexpr Out dimension_symbol_to(Out out, D d, dimension_symbol_formatting fmt = dimension_symbol_formatting{});\nFor example:
std::string txt;\ndimension_symbol_to(std::back_inserter(txt), isq::power.dimension, {.encoding = text_encoding::ascii});\nstd::cout << txt << \"\\n\";\nThe above prints:
L^2MT^-3\nunit_symbol_formatting","text":"unit_symbol_formatting is a data type describing the configuration of the symbol generation algorithm. It contains three orthogonal fields, each with a default value.
enum class unit_symbol_solidus : std::int8_t {\n one_denominator, // m/s; kg m\u207b\u00b9 s\u207b\u00b9\n always, // m/s; kg/(m s)\n never, // m s\u207b\u00b9; kg m\u207b\u00b9 s\u207b\u00b9\n default_denominator = one_denominator\n};\n\nenum class unit_symbol_separator : std::int8_t {\n space, // kg m\u00b2/s\u00b2\n half_high_dot, // kg\u22c5m\u00b2/s\u00b2 (valid only for unicode encoding)\n default_separator = space\n};\n\nstruct unit_symbol_formatting {\n text_encoding encoding = text_encoding::default_encoding;\n unit_symbol_solidus solidus = unit_symbol_solidus::default_denominator;\n unit_symbol_separator separator = unit_symbol_separator::default_separator;\n};\nunit_symbol_solidus impacts how the division of unit symbols is being presented in the text output. By default, the '/' will be printed if only one unit component is in the denominator. Otherwise, the exponent syntax will be used.
unit_symbol_separator specifies how multiple multiplied units should be separated from each other. By default, the space (' ') will be used as a separator.
unit_symbol()","text":"Returns a std::string_view with the symbol of a unit for the provided configuration:
template<unit_symbol_formatting fmt = unit_symbol_formatting{}, typename CharT = char, Unit U>\n[[nodiscard]] consteval std::string_view unit_symbol(U);\nFor example:
static_assert(unit_symbol<{.solidus = unit_symbol_solidus::never,\n .separator = unit_symbol_separator::half_high_dot}>(kg * m / s2) == \"kg\u22c5m\u22c5s\u207b\u00b2\");\nNote
std::string_view is returned only when C++23 is available. Otherwise, an instance of a basic_fixed_string is being returned. See more in the C++ compiler support chapter.
unit_symbol_to()","text":"Inserts the generated unit symbol into the output text iterator at runtime.
template<typename CharT = char, std::output_iterator<CharT> Out, Unit U>\nconstexpr Out unit_symbol_to(Out out, U u, unit_symbol_formatting fmt = unit_symbol_formatting{});\nFor example:
std::string txt;\nunit_symbol_to(std::back_inserter(txt), kg * m / s2,\n {.solidus = unit_symbol_solidus::never, .separator = unit_symbol_separator::half_high_dot});\nstd::cout << txt << \"\\n\";\nThe above prints:
kg\u22c5m\u22c5s\u207b\u00b2\nspace_before_unit_symbol customization point","text":"The SI Brochure says:
SI Brochure
The numerical value always precedes the unit and a space is always used to separate the unit from the number. ... The only exceptions to this rule are for the unit symbols for degree, minute and second for plane angle, \u00b0, \u2032 and \u2033, respectively, for which no space is left between the numerical value and the unit symbol.
There are more units with such properties. For example, percent (%) and per mille(\u2030).
To support the above and other similar cases, the library exposes space_before_unit_symbol customization point. By default, its value is true for all the units, so the space between a number and a unit will be inserted in the output text. To change this behavior, we have to provide a partial specialization for a specific unit:
template<>\ninline constexpr bool space_before_unit_symbol<non_si::degree> = false;\nNote
The above works only for the default formatting or for the format strings that use %? placement field (std::format(\"{}\", q) is equivalent to std::format(\"{:%N%?%U}\", q)).
In case a user provides custom format specification (e.g., std::format(\"{:%N %U}\", q)), the library will always obey this specification for all the units (no matter what the actual value of the space_before_unit_symbol customization point is) and the separating space will always be used in this case.
Tip
The output streaming support is opt-in and can be enabled by including the <mp-units/ostream.h> header file.
The easiest way to print a dimension, unit, or quantity is to provide its object to the output stream:
const QuantityOf<isq::speed> auto v1 = avg_speed(220. * km, 2 * h);\nconst QuantityOf<isq::speed> auto v2 = avg_speed(140. * mi, 2 * h);\nstd::cout << v1 << '\\n'; // 110 km/h\nstd::cout << v2 << '\\n'; // 70 mi/h\nstd::cout << v2.unit << '\\n'; // mi/h\nstd::cout << v2.dimension << '\\n'; // LT\u207b\u00b9\nThe text output will always print the value using the default formatting for this entity.
Important: Don't assume a unit
Remember that when we deal with a quantity of an \"unknown\" (e.g., auto) type, it is a good practice to always convert the unit to the expected one before passing it to the text output:
std::cout << v1.in(km / h) << '\\n'; // 110 km/h\nstd::cout << v1.force_in(m / s) << '\\n'; // 30.5556 m/s\nOnly basic formatting can be applied to output streams. It includes control over width, fill, and alignment.
The numerical value of the quantity will be printed according to the current stream state and standard manipulators may be used to customize that (assuming that the underlying representation type respects them).
std::cout << \"|\" << std::setw(10) << 123 * m << \"|\\n\"; // | 123 m|\nstd::cout << \"|\" << std::setw(10) << std::left << 123 * m << \"|\\n\"; // |123 m |\nstd::cout << \"|\" << std::setw(10) << std::setfill('*') << 123 * m << \"|\\n\"; // |123 m*****|\nNote
To have more control over the formatting of the quantity that is printed with the output stream just use std::cout << std::format(...).
The library provides custom formatters for std::format facility, which allows fine-grained control over what and how it is being printed in the text output.
Tip
The text formatting facility support is opt-in and can be enabled by including the <mp-units/format.h> header file.
Formatting grammar for all the entities provides control over width, fill, and alignment. The C++ standard grammar tokens fill-and-align and width are being used. They treat the entity as a contiguous text to be aligned. For example, here are a few examples of the quantity numerical value and symbol formatting:
std::println(\"|{:0}|\", 123 * m); // |123 m|\nstd::println(\"|{:10}|\", 123 * m); // | 123 m|\nstd::println(\"|{:<10}|\", 123 * m); // |123 m |\nstd::println(\"|{:>10}|\", 123 * m); // | 123 m|\nstd::println(\"|{:^10}|\", 123 * m); // | 123 m |\nstd::println(\"|{:*<10}|\", 123 * m); // |123 m*****|\nstd::println(\"|{:*>10}|\", 123 * m); // |*****123 m|\nstd::println(\"|{:*^10}|\", 123 * m); // |**123 m***|\nIt is important to note that in the second line above, the quantity text is aligned to the right by default, which is consistent with the formatting of numeric types. Units and dimensions behave as text and, thus, are aligned to the left by default.
Note
std::println is a C++23 facility. In case we do not have access to C++23, we can obtain the same output with:
std::cout << std::format(\"<format-string>\\n\", <format-args>);\ndimension-format-spec = [fill-and-align], [width], [dimension-spec];\ndimension-spec = [text-encoding];\ntext-encoding = 'U' | 'A';\nIn the above grammar:
fill-and-align and width tokens are defined in the format.string.std chapter of the C++ standard specification,text-encoding token specifies the symbol text encoding:U (default) uses the Unicode symbols defined by [@ISO80000] (e.g., LT\u207b\u00b2),A forces non-standard ASCII-only output (e.g., LT^-2).Dimension symbols of some quantities are specified to use Unicode signs by the ISQ (e.g., \u0398 symbol for the thermodynamic temperature dimension). The library follows this by default. From the engineering point of view, sometimes Unicode text might not be the best solution, as terminals of many (especially embedded) devices can output only letters from the basic literal character set. In such a case, the dimension symbol can be forced to be printed using such characters thanks to text-encoding token:
std::println(\"{}\", isq::dim_thermodynamic_temperature); // \u0398\nstd::println(\"{:A}\", isq::dim_thermodynamic_temperature); // O\nstd::println(\"{}\", isq::power.dimension); // L\u00b2MT\u207b\u00b3\nstd::println(\"{:A}\", isq::power.dimension); // L^2MT^-3\nunit-format-spec = [fill-and-align], [width], [unit-spec];\nunit-spec = [text-encoding], [unit-symbol-solidus], [unit-symbol-separator], [L]\n | [text-encoding], [unit-symbol-separator], [unit-symbol-solidus], [L]\n | [unit-symbol-solidus], [text-encoding], [unit-symbol-separator], [L]\n | [unit-symbol-solidus], [unit-symbol-separator], [text-encoding], [L]\n | [unit-symbol-separator], [text-encoding], [unit-symbol-solidus], [L]\n | [unit-symbol-separator], [unit-symbol-solidus], [text-encoding], [L];\nunit-symbol-solidus = '1' | 'a' | 'n';\nunit-symbol-separator = 's' | 'd';\nIn the above grammar:
fill-and-align and width tokens are defined in the format.string.std chapter of the C++ standard specification,unit-symbol-solidus token specifies how the division of units should look like:/ only when there is only one unit in the denominator, otherwise negative exponents are printed (e.g., m/s, kg m\u207b\u00b9 s\u207b\u00b9)m/s, kg/(m s))m s\u207b\u00b9, kg m\u207b\u00b9 s\u207b\u00b9)unit-symbol-separator token specifies how multiplied unit symbols should be separated:kg m\u00b2/s\u00b2)\u22c5) as a separator (e.g., kg\u22c5m\u00b2/s\u00b2) (requires the Unicode encoding)Note
The above grammar intended that the elements of unit-spec can appear in any order as they have unique characters. Users shouldn't have to remember the order of those tokens to control the formatting of a unit symbol.
Unit symbols of some quantities are specified to use Unicode signs by the SI (e.g., \u03a9 symbol for the resistance quantity). The library follows this by default. From the engineering point of view, Unicode text might not be the best solution sometimes, as terminals of many (especially embedded) devices can output only letters from the basic literal character set. In such a case, the unit symbol can be forced to be printed using such characters thanks to text-encoding token:
std::println(\"{}\", si::ohm); // \u03a9\nstd::println(\"{:A}\", si::ohm); // ohm\nstd::println(\"{}\", us); // \u00b5s\nstd::println(\"{:A}\", us); // us\nstd::println(\"{}\", m / s2); // m/s\u00b2\nstd::println(\"{:A}\", m / s2); // m/s^2\nAdditionally, both ISO 80000 and SI leave some freedom on how to print unit symbols. This is why two additional tokens were introduced.
unit-symbol-solidus specifies how the division of units should look like. By default, / will be used only when the denominator contains only one unit. However, with the 'a' or 'n' options, we can force the facility to print the / character always (even when there are more units in the denominator), or never, in which case a parenthesis will be added to enclose all denominator units.
std::println(\"{}\", m / s); // m/s\nstd::println(\"{}\", kg / m / s2); // kg m\u207b\u00b9 s\u207b\u00b2\nstd::println(\"{:a}\", m / s); // m/s\nstd::println(\"{:a}\", kg / m / s2); // kg/(m s\u00b2)\nstd::println(\"{:n}\", m / s); // m s\u207b\u00b9\nstd::println(\"{:n}\", kg / m / s2); // kg m\u207b\u00b9 s\u207b\u00b2\nAlso, there are a few options to separate the units being multiplied. ISO 80000 (part 1) says:
ISO 80000-1
When symbols for quantities are combined in a product of two or more quantities, this combination is indicated in one of the following ways: ab, a b, a \u00b7 b, a \u00d7 b
NOTE 1 In some fields, e.g., vector algebra, distinction is made between a \u2219 b and a \u00d7 b.
The library supports a b and a \u00b7 b only. Additionally, we decided that the extraneous space in the latter case makes the result too verbose, so we decided just to use the \u00b7 symbol as a separator.
Note
Please let us know if you require more formatting options here.
The unit-symbol-separator token allows us to obtain the following outputs:
std::println(\"{}\", kg * m2 / s2); // kg m\u00b2/s\u00b2\nstd::println(\"{:d}\", kg * m2 / s2); // kg\u22c5m\u00b2/s\u00b2\nNote
'd' requires the Unicode encoding to be set.
"},{"location":"users_guide/framework_basics/text_output/#quantity-formatting","title":"Quantity formatting","text":"quantity-format-spec = [fill-and-align], [width], [quantity-specs], [defaults-specs];\nquantity-specs = conversion-spec;\n | quantity-specs, conversion-spec;\n | quantity-specs, literal-char;\nliteral-char = ? any character other than '{', '}', or '%' ?;\nconversion-spec = '%', placement-type;\nplacement-type = subentity-id | '?' | '%';\ndefaults-specs = ':', default-spec-list;\ndefault-spec-list = default-spec;\n | default-spec-list, default-spec;\ndefault-spec = subentity-id, '[' format-spec ']';\nsubentity-id = 'N' | 'U' | 'D';\nformat-spec = ? as specified by the formatter for the argument type ?;\nIn the above grammar:
fill-and-align and width tokens are defined in the format.string.std chapter of the C++ standard specification,placement-type token specifies which entity should be put and where:space_before_unit_symbol for this unit,defaults-specs token allows overwriting defaults for the underlying formatters with the custom format string. Each override starts with a subentity identifier ('N', 'U', or 'D') followed by the format string enclosed in square brackets.To format quantity values, the formatting facility uses quantity-format-spec. If left empty, the default formatting is applied. The same default formatting is also applied to the output streams. This is why the following code lines produce the same output:
std::cout << \"Distance: \" << 123 * km << \"\\n\";\nstd::cout << std::format(\"Distance: {}\\n\", 123 * km);\nstd::cout << std::format(\"Distance: {:%N%?%U}\\n\", 123 * km);\nNote
For some quantities, the {:%N %U} format may provide a different output than the default one, as some units have space_before_unit_symbol customization point explicitly set to false (e.g., % and \u00b0).
Thanks to the grammar provided above, the user can easily decide to either:
print a whole quantity:
std::println(\"Speed: {}\", 120 * km / h);\nSpeed: 120 km/h\nprovide custom quantity formatting:
std::println(\"Speed: {:%N in %U}\", 120 * km / h);\nSpeed: 120 in km/h\nprovide custom formatting for components:
std::println(\"Speed: {::N[.2f]U[n]}\", 100. * km / (3 * h));\nSpeed: 33.33 km h\u207b\u00b9\nprint only specific components (numerical value, unit, or dimension):
std::println(\"Speed:\\n- number: {0:%N}\\n- unit: {0:%U}\\n- dimension: {0:%D}\", 120 * km / h);\nSpeed:\n- number: 120\n- unit: km/h\n- dimension: LT\u207b\u00b9\nThe representation type used as a numerical value of a quantity must provide its own formatter specialization. It will be called by the quantity formatter with the format-spec provided by the user in the N defaults specification.
In case we use C++ fundamental arithmetic types with our quantities the standard formatter specified in format.string.std will be used. The rest of this chapter assumes that it is the case and provides some usage examples.
sign token allows us to specify how the value's sign is being printed:
std::println(\"{0},{0::N[+]},{0::N[-]},{0::N[ ]}\", 1 * m); // 1 m,+1 m,1 m, 1 m\nstd::println(\"{0},{0::N[+]},{0::N[-]},{0::N[ ]}\", -1 * m); // -1 m,-1 m,-1 m,-1 m\nwhere:
+ indicates that a sign should be used for both non-negative and negative numbers,- indicates that a sign should be used for negative numbers and negative zero only (this is the default behavior),<space> indicates that a leading space should be used for non-negative numbers other than negative zero, and a minus sign for negative numbers and negative zero.precision token is allowed only for floating-point representation types:
std::println(\"{::N[.0]}\", 1.2345 * m); // 1 m\nstd::println(\"{::N[.1]}\", 1.2345 * m); // 1 m\nstd::println(\"{::N[.2]}\", 1.2345 * m); // 1.2 m\nstd::println(\"{::N[.3]}\", 1.2345 * m); // 1.23 m\nstd::println(\"{::N[.0f]}\", 1.2345 * m); // 1 m\nstd::println(\"{::N[.1f]}\", 1.2345 * m); // 1.2 m\nstd::println(\"{::N[.2f]}\", 1.2345 * m); // 1.23 m\ntype specifies how a value of the representation type is being printed. For integral types:
std::println(\"{::N[b]}\", 42 * m); // 101010 m\nstd::println(\"{::N[B]}\", 42 * m); // 101010 m\nstd::println(\"{::N[d]}\", 42 * m); // 42 m\nstd::println(\"{::N[o]}\", 42 * m); // 52 m\nstd::println(\"{::N[x]}\", 42 * m); // 2a m\nstd::println(\"{::N[X]}\", 42 * m); // 2A m\nThe above can be printed in an alternate version thanks to the # token:
std::println(\"{::N[#b]}\", 42 * m); // 0b101010 m\nstd::println(\"{::N[#B]}\", 42 * m); // 0B101010 m\nstd::println(\"{::N[#o]}\", 42 * m); // 052 m\nstd::println(\"{::N[#x]}\", 42 * m); // 0x2a m\nstd::println(\"{::N[#X]}\", 42 * m); // 0X2A m\nFor floating-point values, the type token works as follows:
std::println(\"{::N[a]}\", 1.2345678 * m); // 1.3c0ca2a5b1d5dp+0 m\nstd::println(\"{::N[.3a]}\", 1.2345678 * m); // 1.3c1p+0 m\nstd::println(\"{::N[A]}\", 1.2345678 * m); // 1.3C0CA2A5B1D5DP+0 m\nstd::println(\"{::N[.3A]}\", 1.2345678 * m); // 1.3C1P+0 m\nstd::println(\"{::N[e]}\", 1.2345678 * m); // 1.234568e+00 m\nstd::println(\"{::N[.3e]}\", 1.2345678 * m); // 1.235e+00 m\nstd::println(\"{::N[E]}\", 1.2345678 * m); // 1.234568E+00 m\nstd::println(\"{::N[.3E]}\", 1.2345678 * m); // 1.235E+00 m\nstd::println(\"{::N[g]}\", 1.2345678 * m); // 1.23457 m\nstd::println(\"{::N[g]}\", 1.2345678e8 * m); // 1.23457e+08 m\nstd::println(\"{::N[.3g]}\", 1.2345678 * m); // 1.23 m\nstd::println(\"{::N[.3g]}\", 1.2345678e8 * m); // 1.23e+08 m\nstd::println(\"{::N[G]}\", 1.2345678 * m); // 1.23457 m\nstd::println(\"{::N[G]}\", 1.2345678e8 * m); // 1.23457E+08 m\nstd::println(\"{::N[.3G]}\", 1.2345678 * m); // 1.23 m\nstd::println(\"{::N[.3G]}\", 1.2345678e8 * m); // 1.23E+08 m\nThe affine space has two types of entities:
In the following subchapters, we will often refer to displacement vectors simply as vectors for brevity.
Note
The displacement vector described here is specific to the affine space theory and is not the same thing as the quantity of a vector character that we discussed in the \"Scalars, vectors, and tensors\" chapter (although, in some cases, those terms may overlap).
"},{"location":"users_guide/framework_basics/the_affine_space/#operations-in-the-affine-space","title":"Operations in the affine space","text":"Here are the primary operations one can do in the affine space:
Important
It is not possible to:
Point abstractions should be used more often in the C++ software. They are not only about temperature or time. Points are everywhere around us and should become more popular in the products we implement. They can be used to implement:
Improving the affine space's Points intuition will allow us to write better and safer software.
"},{"location":"users_guide/framework_basics/the_affine_space/#displacement-vector-is-modeled-by-quantity","title":"Displacement vector is modeled byquantity","text":"Up until now, each time we used a quantity in our code, we were modeling some kind of a difference between two things:
As we already know, a quantity type provides all operations required for a displacement vector abstraction in the affine space. It can be constructed with:
delta<Reference> construction helper (e.g., delta<isq::height[m]>(42), delta<deg_C>(3)),Note
The multiply syntax support is disabled for units that provide a point origin in their definition (i.e., units of temperature like K, deg_C, and deg_F).
quantity_point and PointOrigin","text":"In the mp-units library, the Point abstraction is modelled by:
PointOrigin concept that specifies measurement origin, andquantity_point class template that specifies a Point relative to a specific predefined origin.quantity_point","text":"The quantity_point class template specifies an absolute quantity measured from a predefined origin:
template<Reference auto R,\n PointOriginFor<get_quantity_spec(R)> auto PO = default_point_origin(R),\n RepresentationOf<get_quantity_spec(R).character> Rep = double>\nclass quantity_point;\nAs we can see above, the quantity_point class template exposes one additional parameter compared to quantity. The PO parameter satisfies a PointOriginFor concept and specifies the origin of our measurement scale.
Each quantity_point internally stores a quantity object, which represents a displacement vector from the predefined origin. Thanks to this, an instantiation of a quantity_point can be considered as a model of a vector space from such an origin.
Forcing the user to manually predefine an origin for every domain may be cumbersome and discourage users from using such abstractions at all. This is why, by default, the PO template parameter is initialized with the default_point_origin(R) that provides the quantity points' scale zeroth point using the following rules:
zeroth_point_origin<QuantitySpec> is being used which provides a well-established zeroth point for a specific quantity type.Quantity points with default point origins may be constructed with the absolute construction helper or forcing an explicit conversion from the quantity:
// quantity_point qp1 = 42 * m; // Compile-time error\n// quantity_point qp2 = 42 * K; // Compile-time error\n// quantity_point qp3 = delta<deg_C>(42); // Compile-time error\nquantity_point qp4(42 * m);\nquantity_point qp5(42 * K);\nquantity_point qp6(delta<deg_C>(42));\nquantity_point qp7 = absolute<m>(42);\nquantity_point qp8 = absolute<K>(42);\nquantity_point qp9 = absolute<deg_C>(42);\nTip
The quantity_point definition can be found in the mp-units/quantity_point.h header file.
zeroth_point_origin<QuantitySpec>","text":"zeroth_point_origin<QuantitySpec> is meant to be used in cases where the specific domain has a well-established, non-controversial, and unique zeroth point on the measurement scale. This saves the user from the need to write a boilerplate code that would predefine such a type for this domain.
quantity_point<isq::distance[si::metre]> qp1(100 * m);\nquantity_point<isq::distance[si::metre]> qp2 = absolute<m>(120);\n\nassert(qp1.quantity_from_zero() == 100 * m);\nassert(qp2.quantity_from_zero() == 120 * m);\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\n\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\n\n// auto res = qp1 + qp2; // Compile-time error\nIn the above code 100 * m and 120 * m still create two quantities that serve as displacement vectors here. Quantity point objects can be explicitly constructed from such quantities only when their origin is an instantiation of the zeroth_point_origin<QuantitySpec>.
It is really important to understand that even though we can use .quantity_from_zero() to obtain the displacement vector of a point from the origin, the point by itself does not represent or have any associated physical value. It is just a point in some space. The same point can be expressed with different displacement vectors from different origins.
It is also worth mentioning that simplicity comes with a safety cost here. For some users, it might be surprising that the usage of zeroth_point_origin<QuantitySpec> makes various quantity point objects compatible as long as quantity types used in the origin and reference are compatible:
quantity_point<si::metre> qp1{isq::distance(100 * m)};\nquantity_point<si::metre> qp2 = absolute<isq::height[m]>(120);\n\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\nIn cases where we want to implement an isolated independent space in which points are not compatible with other spaces, even of the same quantity type, we should manually predefine an absolute point origin.
inline constexpr struct origin final : absolute_point_origin<isq::distance> {} origin;\n\n// quantity_point<si::metre, origin> qp1{100 * m}; // Compile-time error\n// quantity_point<si::metre, origin> qp2{delta<m>(120)}; // Compile-time error\nquantity_point<si::metre, origin> qp1 = origin + 100 * m;\nquantity_point<si::metre, origin> qp2 = 120 * m + origin;\n\n// assert(qp1.quantity_from_zero() == 100 * m); // Compile-time error\n// assert(qp2.quantity_from_zero() == 120 * m); // Compile-time error\nassert(qp1.quantity_from(origin) == 100 * m);\nassert(qp2.quantity_from(origin) == 120 * m);\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\n\nassert(qp1 - origin == 100 * m);\nassert(qp2 - origin == 120 * m);\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\n\nassert(origin - qp1 == -100 * m);\nassert(origin - qp2 == -120 * m);\n\n// assert(origin - origin == 0 * m); // Compile-time error\nWe can't construct a quantity point directly from the quantity anymore when a custom, named origin is used. To prevent potential safety and maintenance issues, we always need to explicitly provide both a compatible origin and a quantity measured from it to construct a quantity point.
Said otherwise, a quantity point defined in terms of a specific origin is the result of adding the origin and the displacement vector measured from it to the point we create.
Info
A rationale for this longer construction syntax can be found in the Why can't I create a quantity by passing a number to a constructor? chapter.
Similarly to creation of a quantity, if someone does not like the operator-based syntax to create a quantity_point, the same results can be achieved with a two-parameter constructor:
quantity_point qp1{100 * m, origin};\nAgain, CTAD always helps to use precisely the type we need in a current case.
Additionally, if a quantity point is defined in terms of a custom, named origin, then we can't use a quantity_from_zero() member function anymore. This is to prevent surprises, as our origin may not necessarily be perceived as an absolute zero in the domain we model. Also, as we will learn soon, we can define several related origins in one space, and then it gets harder to understand which one is the \"zero\" one. This is why, to be specific and always correct about the points we use, a quantity_from(QP) member function can be used (where QP can either be an origin or another quantity point).
Finally, please note that it is not allowed to subtract two point origins defined in terms of absolute_point_origin (e.g., origin - origin) as those do not contain information about the unit, so we cannot determine a resulting quantity type.
Absolute point origins are also perfect for establishing independent spaces even if the same quantity type and unit is being used:
inline constexpr struct origin1 final : absolute_point_origin<isq::distance> {} origin1;\ninline constexpr struct origin2 final : absolute_point_origin<isq::distance> {} origin2;\n\nquantity_point qp1 = origin1 + 100 * m;\nquantity_point qp2 = origin2 + 120 * m;\n\nassert(qp1.quantity_from(origin1) == 100 * m);\nassert(qp2.quantity_from(origin2) == 120 * m);\n\nassert(qp1 - origin1 == 100 * m);\nassert(qp2 - origin2 == 120 * m);\nassert(origin1 - qp1 == -100 * m);\nassert(origin2 - qp2 == -120 * m);\n\n// assert(qp2 - qp1 == 20 * m); // Compile-time error\n// assert(qp1 - origin2 == 100 * m); // Compile-time error\n// assert(qp2 - origin1 == 120 * m); // Compile-time error\n// assert(qp2.quantity_from(qp1) == 20 * m); // Compile-time error\n// assert(qp1.quantity_from(origin2) == 100 * m); // Compile-time error\n// assert(qp2.quantity_from(origin1) == 120 * m); // Compile-time error\nWe often do not have only one ultimate \"zero\" point when we measure things. Often, we have one common scale, but we measure various quantities relative to different points and expect those points to be compatible. There are many examples here, but probably the most common are temperatures, timestamps, and altitudes.
For such cases, relative point origins should be used:
inline constexpr struct A final : absolute_point_origin<isq::distance> {} A;\ninline constexpr struct B final : relative_point_origin<A + 10 * m> {} B;\ninline constexpr struct C final : relative_point_origin<B + 10 * m> {} C;\ninline constexpr struct D final : relative_point_origin<A + 30 * m> {} D;\n\nquantity_point qp1 = C + 100 * m;\nquantity_point qp2 = D + 120 * m;\n\nassert(qp1.quantity_ref_from(qp1.point_origin) == 100 * m);\nassert(qp2.quantity_ref_from(qp2.point_origin) == 120 * m);\n\nassert(qp2.quantity_from(qp1) == 30 * m);\nassert(qp1.quantity_from(qp2) == -30 * m);\nassert(qp2 - qp1 == 30 * m);\nassert(qp1 - qp2 == -30 * m);\n\nassert(qp1.quantity_from(A) == 120 * m);\nassert(qp1.quantity_from(B) == 110 * m);\nassert(qp1.quantity_from(C) == 100 * m);\nassert(qp1.quantity_from(D) == 90 * m);\nassert(qp1 - A == 120 * m);\nassert(qp1 - B == 110 * m);\nassert(qp1 - C == 100 * m);\nassert(qp1 - D == 90 * m);\n\nassert(qp2.quantity_from(A) == 150 * m);\nassert(qp2.quantity_from(B) == 140 * m);\nassert(qp2.quantity_from(C) == 130 * m);\nassert(qp2.quantity_from(D) == 120 * m);\nassert(qp2 - A == 150 * m);\nassert(qp2 - B == 140 * m);\nassert(qp2 - C == 130 * m);\nassert(qp2 - D == 120 * m);\n\nassert(B - A == 10 * m);\nassert(C - A == 20 * m);\nassert(D - A == 30 * m);\nassert(D - C == 10 * m);\n\nassert(B - B == 0 * m);\n// assert(A - A == 0 * m); // Compile-time error\nNote
Even though we can't subtract two absolute point origins from each other, it is possible to subtract relative ones or relative and absolute ones.
"},{"location":"users_guide/framework_basics/the_affine_space/#converting-between-different-representations-of-the-same-point","title":"Converting between different representations of the same point","text":"As we might represent the same point with displacement vectors from various origins, the library provides facilities to convert the same point to the quantity_point class templates expressed in terms of different origins.
For this purpose, we can use either:
A converting constructor:
quantity_point<si::metre, C> qp2C = qp2;\nassert(qp2C.quantity_ref_from(qp2C.point_origin) == 130 * m);\nA dedicated conversion interface:
quantity_point qp2B = qp2.point_for(B);\nquantity_point qp2A = qp2.point_for(A);\n\nassert(qp2B.quantity_ref_from(qp2B.point_origin) == 140 * m);\nassert(qp2A.quantity_ref_from(qp2A.point_origin) == 150 * m);\nIt is important to understand that all such translations still describe exactly the same point (e.g., all of them compare equal):
assert(qp2 == qp2C);\nassert(qp2 == qp2B);\nassert(qp2 == qp2A);\nImportant
It is only allowed to convert between various origins defined in terms of the same absolute_point_origin. Even if it is possible to express the same point as a displacement vector from another absolute_point_origin, the library will not provide such a conversion. A custom user-defined conversion function will be needed to add such a functionality.
Said another way, in the library, there is no way to spell how two distinct absolute_point_origin types relate to each other.
Support for temperature quantity points is probably one of the most common examples of relative point origins in action that we use in daily life.
The SI definition in the library provides a few predefined point origins for this purpose:
namespace si {\n\ninline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr auto zeroth_kelvin = absolute_zero;\n\ninline constexpr struct ice_point final : relative_point_origin<absolute<milli<kelvin>>(273'150)}> {} ice_point;\ninline constexpr auto zeroth_degree_Celsius = ice_point;\n\n}\n\nnamespace usc {\n\ninline constexpr struct zeroth_degree_Fahrenheit final :\n relative_point_origin<absolute<mag_ratio<5, 9> * si::degree_Celsius>(-32)> {} zeroth_degree_Fahrenheit;\n\n}\nThe above is a great example of how point origins can be stacked on top of each other:
usc::zeroth_degree_Fahrenheit is defined relative to si::zeroth_degree_Celsiussi::zeroth_degree_Celsius is defined relative to si::zeroth_kelvin.Note
Notice that while stacking point origins, we can use different representation types and units for origins and a point. In the above example, the relative point origin for degree Celsius is defined in terms of si::kelvin, while the quantity point for it will use si::degree_Celsius as a unit.
The temperature point origins defined above are provided explicitly in the respective units' definitions:
namespace si {\n\ninline constexpr struct kelvin final :\n named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\ninline constexpr struct degree_Celsius final :\n named_unit<{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\n\n}\n\nnamespace usc {\n\ninline constexpr struct degree_Fahrenheit final :\n named_unit<{u8\"\u2109\", \"`F\"}, mag_ratio<5, 9> * si::degree_Celsius,\n zeroth_degree_Fahrenheit> {} degree_Fahrenheit;\n\n}\nAs it was described above, default_point_origin(R) returns a zeroth_point_origin<QuantitySpec> when a unit does not provide any origin in its definition. As of today, the units of temperature are the only ones in the entire mp-units library that provide such origins.
Now, let's see how we can benefit from the above definitions. We have quite a few alternatives to choose from here. Depending on our needs or tastes, we can:
be explicit about the unit and origin:
quantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q1 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q2{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q3{delta<deg_C>(20.5)};\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q4 = absolute<deg_C>(20.5);\nspecify a unit and use its zeroth point origin implicitly:
quantity_point<si::degree_Celsius> q5 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point<si::degree_Celsius> q6{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point<si::degree_Celsius> q7{delta<deg_C>(20.5)};\nquantity_point<si::degree_Celsius> q8 = absolute<deg_C>(20.5);\nbenefit from CTAD:
quantity_point q9 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point q10{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point q11{delta<deg_C>(20.5)};\nquantity_point q12 = absolute<deg_C>(20.5);\nIn all of the above cases, we end up with the quantity_point of the same type and value.
To play a bit more with temperatures, we can implement a simple room AC temperature controller in the following way:
constexpr struct room_reference_temp final : relative_point_origin<absolute<deg_C>(21)> {} room_reference_temp;\nusing room_temp = quantity_point<isq::Celsius_temperature[deg_C], room_reference_temp>;\n\nconstexpr auto step_delta = delta<isq::Celsius_temperature<deg_C>>(0.5);\nconstexpr int number_of_steps = 6;\n\nroom_temp room_ref{};\nroom_temp room_low = room_ref - number_of_steps * step_delta;\nroom_temp room_high = room_ref + number_of_steps * step_delta;\n\nstd::println(\"Room reference temperature: {} ({}, {::N[.2f]})\\n\",\n room_ref.quantity_from_zero(),\n room_ref.in(usc::degree_Fahrenheit).quantity_from_zero(),\n room_ref.in(si::kelvin).quantity_from_zero());\n\nstd::println(\"| {:<18} | {:^18} | {:^18} | {:^18} |\",\n \"Temperature delta\", \"Room reference\", \"Ice point\", \"Absolute zero\");\nstd::println(\"|{0:=^20}|{0:=^20}|{0:=^20}|{0:=^20}|\", \"\");\n\nauto print_temp = [&](std::string_view label, auto v) {\n std::println(\"| {:<14} | {:^18} | {:^18} | {:^18:N[.2f]} |\", label,\n v - room_reference_temp, (v - si::ice_point).in(deg_C), (v - si::absolute_zero).in(deg_C));\n};\n\nprint_temp(\"Lowest\", room_low);\nprint_temp(\"Default\", room_ref);\nprint_temp(\"Highest\", room_high);\nThe above prints:
Room reference temperature: 21 \u2103 (69.8 \u2109, 294.15 K)\n\n| Temperature delta | Room reference | Ice point | Absolute zero |\n|====================|====================|====================|====================|\n| Lowest | -3 \u2103 | 18 \u2103 | 291.15 \u2103 |\n| Default | 0 \u2103 | 21 \u2103 | 294.15 \u2103 |\n| Highest | 3 \u2103 | 24 \u2103 | 297.15 \u2103 |\nThe library does not provide a text output for quantity points. The quantity stored inside is just an implementation detail of this type. It is a vector from a specific origin. Without the knowledge of the origin, the vector by itself is useless as we can't determine which point it describes.
In the current library design, point origin does not provide any text in its definition. Even if we could add such information to the point's definition, we would not know how to output it in the text. There may be many ways to do it. For example, should we prepend or append the origin part to the quantity text?
For example, the text output of 42 m for a quantity point may mean many things. It may be an offset from the mountain top, sea level, or maybe the center of Mars. Printing 42 m AMSL for altitudes above mean sea level is a much better solution, but the library does not have enough information to print it that way by itself.
The following operations are not allowed in the affine space:
quantity_point objectsquantity_point from a quantityquantity_point with a scalar2 * DEN airport location?quantity_point with a quantityquantity_point objectsquantity_points of different quantity kindsquantity_points of inconvertible quantitiesquantity_points of convertible quantities but with unrelated originsImportant: The affine space improves safety
The usage of quantity_point and affine space types, in general, improves expressiveness and type-safety of the code we write.
auto q1 = 5 * km;\nstd::cout << q1.in(m) << '\\n';\nquantity<si::metre, int> q2 = q1;\nThe second line above converts the current quantity to the one expressed in meters and prints its contents. The third line converts the quantity expressed in kilometers into the one measured in meters.
In case a user would like to perform an opposite transformation:
auto q1 = 5 * m;\nstd::cout << q1.in(km) << '\\n';\nquantity<si::kilo<si::metre>, int> q2 = q1;\nBoth conversions will fail to compile.
There are two ways to make the above work. The first solution is to use a floating-point representation type:
auto q1 = 5. * m;\nstd::cout << q1.in(km) << '\\n';\nquantity<si::kilo<si::metre>> q2 = q1;\nor
auto q1 = 5 * m;\nstd::cout << value_cast<double>(q1).in(km) << '\\n';\nquantity<si::kilo<si::metre>> q2 = q1; // double by default\nImportant
The mp-units library follows std::chrono::duration logic and treats floating-point types as value-preserving.
The second solution is to force a truncating conversion:
auto q1 = 5 * m;\nstd::cout << value_cast<km>(q1) << '\\n';\nquantity<si::kilo<si::metre>, int> q2 = q1.force_in(km);\nThis explicit cast makes it clear that something unsafe is going on. It is easy to spot in code reviews or while chasing a bug in the source code.
Note
q.force_in(U) is just a shortcut to run value_cast<U>(q). There is no difference in behavior between those two interfaces. q.force_in(U) was added for consistency with q.in(U) and q.force_numerical_value_in(U).
Another place where this cast is useful is when a user wants to convert a quantity with a floating-point representation to the one using an integral one. Again, this is a truncating conversion, so an explicit cast is needed:
quantity<si::metre, int> q3 = value_cast<int>(3.14 * m);\nInfo
It is often OK to use an integral as a representation type, but in general, floating-point types provide better precision and are privileged in the library as they are considered to be value-preserving.
In some cases, a unit and a representation type should be changed simultaneously. Moreover, sometimes, the order of doing those operations matters. In such cases, the library provides the value_cast<U, Rep>(q) which always returns the most precise result:
inline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\ninline constexpr struct currency final : quantity_spec<dim_currency> {} currency;\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n} // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\ninline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\ninline constexpr struct currency final : quantity_spec<currency, dim_currency> {} currency;\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n} // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\ninline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\nQUANTITY_SPEC(currency, dim_currency);\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n} // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\nusing namespace unit_symbols;\nPrice price{12.95 * USD};\nScaled spx = value_cast<USD_s, std::int64_t>(price);\nAs a shortcut, instead of providing a unit and a representation type to value_cast, you may also provide a Quantity type directly, from which unit and representation type are taken. However, value_cast<Quantity>, still only allows for changes in unit and representation type, but not changing the type of the quantity. For that, you will have to use a quantity_cast instead.
Overloads are also provided for instances of quantity_point. All variants of value_cast<...>(q) that apply to instances of quantity have a corresponding version applicable to quantity_point, where the point_origin remains untouched, and the cast changes how the \"offset\" from the origin is represented. Specifically, for any quantity_point instance qp, all of the following equivalences hold:
static_assert(value_cast<Rep>(qp) == quantity_point{value_cast<Rep>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<U>(qp) == quantity_point{value_cast<U>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<U, Rep>(qp) == quantity_point{value_cast<U, Rep>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<Q>(qp) == quantity_point{value_cast<Q>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nFurthermore, there is one additional overload value_cast<ToQP>(qp). This overload permits to additionally replace the point_origin with another compatible one, while still representing the same point in the affine space. Thus, it is roughly equivalent to value_cast<ToQP::unit, ToQP::rep>(qp).point_for(ToQP::point_origin). In contrast to a separate value_cast followed by point_for (or vice-versa), the combined value_cast tries to choose the order of the individual conversion steps in a way to avoid both overflow and unnecessary loss of precision. Overflow is a risk because the change of origin point may require an addition of a potentially large offset (the difference between the origin points), which may well be outside the range of one or both quantity types.
The table below provides all the value conversions functions that may be run on x being the instance of either quantity or quantity_point:
u x.in(u) No T Same x.in<T>() No T u x.in<T>(u) Yes Same u x.force_in(u) value_cast<u>(x) Yes T Same x.force_in<T>() value_cast<T>(x) Yes T u x.force_in<T>(u) value_cast<u, T>(x)"},{"location":"users_guide/systems/strong_angular_system/","title":"Strong Angular System","text":""},{"location":"users_guide/systems/strong_angular_system/#some-background-information","title":"Some background information","text":"As per today's SI, both radian and steradian are dimensionless. This forces the convention to set the angle 1 radian equal to the number 1 within equations (similar to what natural units system does for c constant).
Following Wikipedia:
Wikipedia: Radian - Dimensional analysis
Giacomo Prando says \"the current state of affairs leads inevitably to ghostly appearances and disappearances of the radian in the dimensional analysis of physical equations.\" For example, a mass hanging by a string from a pulley will rise or drop by \\(y=r\u03b8\\) centimeters, where \\(r\\) is the radius of the pulley in centimeters and \\(\u03b8\\) is the angle the pulley turns in radians. When multiplying \\(r\\) by \\(\u03b8\\) the unit of radians disappears from the result. Similarly in the formula for the angular velocity of a rolling wheel, \\(\u03c9=v/r\\), radians appear in the units of \\(\u03c9\\) but not on the right hand side. Anthony French calls this phenomenon \"a perennial problem in the teaching of mechanics\". Oberhofer says that the typical advice of ignoring radians during dimensional analysis and adding or removing radians in units according to convention and contextual knowledge is \"pedagogically unsatisfying\".
At least a dozen scientists have made proposals to treat the radian as a base unit of measure defining its own dimension of \"angle\", as early as 1936 and as recently as 2022. This would bring the advantages of a physics-based, consistent, and logically-robust unit system, with unambiguous units for all physical quantities. At the same time the only notable changes for typical end-users would be: improved units for the quantities torque, angular momentum, and moment of inertia.
Paul Quincey in his proposal \"Angles in the SI: a detailed proposal for solving the problem\" states:
Paul Quincey: Angles in the SI: a detailed proposal for solving the problem
The familiar units assigned to some angular quantities are based on equations that have adopted the radian convention, and so are missing rads that would be present if the complete equation is used. The physically-correct units are those with the rads reinstated. Numerical values would not change, and the physical meanings of all quantities would also be unaffected.
He proposes the following changes:
The SI units for
The option to omit the radian from the SI units for angle, angular velocity, angular frequency, angular acceleration, and angular wavenumber would be removed, the only correct SI units being \\(rad\\), \\(rad/s\\), \\(rad/s\\), \\(rad/s^2\\) and \\(rad/m\\) respectively.
Paul Quincey summarizes that with the above in action:
Paul Quincey: Angles in the SI: a detailed proposal for solving the problem
However, the physical clarity this would build into the SI should be recognised very quickly. The units would tell us that \\(torque \\times angle = energy\\), and \\(angular\\:momentum \\times angle = action\\), for example, in the same way that they do for \\(force \\times distance = energy\\), \\(linear\\:momentum \\times distance = action\\), and \\(radiant\\:intensity \\times solid\\:angle = radiant\\:flux\\). Dimensional analysis could be used to its full extent. Software involving angular quantities would be rationalised. Arguments about the correct units for frequency and angular frequency, and the meaning of the unit \\(Hz\\), could be left behind. The explanation of these changes would be considerably easier and more rewarding than explaining how a kilogram-sized mass can be measured in terms of the Planck constant.
"},{"location":"users_guide/systems/strong_angular_system/#angular-quantities-in-the-si","title":"Angular quantities in the SI","text":"Even though the SI somehow ignores the dimensionality of angle:
SI Brochure
Plane and solid angles, when expressed in radians and steradians respectively, are in effect also treated within the SI as quantities with the unit one. The symbols \\(rad\\) and \\(sr\\) are written explicitly where appropriate, in order to emphasize that, for radians or steradians, the quantity being considered is, or involves the plane angle or solid angle respectively. For steradians it emphasizes the distinction between units of flux and intensity in radiometry and photometry for example. However, it is a long-established practice in mathematics and across all areas of science to make use of \\(rad = 1\\) and \\(sr = 1\\). For historical reasons the radian and steradian are treated as derived units.
It also explicitly states:
SI Brochure
The SI unit of frequency is hertz, the SI unit of angular velocity and angular frequency is radian per second, and the SI unit of activity is becquerel, implying counts per second. Although it is formally correct to write all three of these units as the reciprocal second, the use of the different names emphasizes the different nature of the quantities concerned. It is especially important to carefully distinguish frequencies from angular frequencies, because by definition their numerical values differ by a factor of \\(2\\pi\\). Ignoring this fact may cause an error of \\(2\\pi\\). Note that in some countries, frequency values are conventionally expressed using \u201ccycle/s\u201d or \u201ccps\u201d instead of the SI unit \\(Hz\\), although \u201ccycle\u201d and \u201ccps\u201d are not units in the SI. Note also that it is common, although not recommended, to use the term frequency for quantities expressed in \\(rad/s\\). Because of this, it is recommended that quantities called \u201cfrequency\u201d, \u201cangular frequency\u201d, and \u201cangular velocity\u201d always be given explicit units of \\(Hz\\) or \\(rad/s\\) and not \\(s^{-1}\\).
"},{"location":"users_guide/systems/strong_angular_system/#strong-angular-extensions-in-the-library","title":"Strong Angular extensions in the library","text":"The mp-units library strives to define physically-correct quantities and their units to provide maximum help to its users. As treating angle as a dimensional quantity can lead to many \"trivial\" mistakes in dimensional analysis and calculation, it was decided to provide additional experimental systems of quantities and units that follow the above approach and treat angle as a base quantity with a base unit of radian and solid angle as its derived quantity.
As those (at least for now) are not a part of SI, the plain angle and solid angle definitions can be found in a dedicated angular system. Those definitions are also used in the isq_angle system of quantities to make the recipes for angle-based quantities like torque or angular velocity physically correct:
using namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\nusing mp_units::angular::unit_symbols::deg;\nusing mp_units::angular::unit_symbols::rad;\n\nconst quantity lever = isq_angle::position_vector(20 * cm);\nconst quantity force = isq_angle::force(500 * N);\nconst quantity angle = isq_angle::angular_measure(90. * deg);\nconst quantity torque = isq_angle::torque(lever * force * angular::sin(angle) / (1 * isq_angle::cotes_angle));\n\nstd::cout << \"Applying a perpendicular force of \" << force << \" to a \" << lever << \" long lever results in \"\n << torque.in(N * m / rad) << \" of torque.\\n\";\nThe above program prints:
Applying a perpendicular force of 500 N to a 20 cm long lever results in 100 N m/rad of torque.\nNote
cotes_angle is a constant which represents an angle with the value of exactly 1 radian. You can find more information about this constant in Quincey.
Try it on Compiler Explorer
"},{"location":"users_guide/use_cases/interoperability_with_other_libraries/","title":"Interoperability with Other Libraries","text":"mp-units makes it easy to cooperate with similar entities of other libraries. No matter if we want to provide interoperability with a simple home-grown strongly typed wrapper type (e.g., Meter, Timestamp, ...) or with a feature-rich quantities and units library, we have to provide specializations of:
quantity_like_traits for external quantity-like type,quantity_point_like_traits for external quantity_point-like type.Before we delve into the template specialization details, let's first decide if we want the conversions to happen implicitly or if explicit ones would be a better choice. Or maybe the conversion should be implicit in one direction only (e.g., into mp-units abstractions) while the explicit conversions in the other direction should be preferred?
There is no one unified answer to the above questions. Everything depends on the use case.
Typically, the implicit conversions are allowed in cases where:
In all other scenarios, we should probably enforce explicit conversions.
The kinds of inter-library conversions can be easily configured in partial specializations of conversion traits in the mp-units library. To require an explicit conversion, the return type of the conversion function should be wrapped in convert_explicitly<T>. Otherwise, convert_implicitly<T> should be used.
For example, let's assume that some company has its own Meter strong-type wrapper:
struct Meter {\n int value;\n};\nAs every usage of Meter is at least as good and safe as the usage of quantity<si::metre, int>, and as there is no significant runtime performance penalty, we would like to allow the conversion to mp_units::quantity to happen implicitly.
On the other hand, the quantity type is much safer than the Meter, and that is why we would prefer to see the opposite conversions stated explicitly in our code.
To enable such interoperability, we must define a partial specialization of the quantity_like_traits<T> type trait. Such specialization should provide:
reference that provides the quantity reference (e.g., unit),rep type that specifies the underlying storage type,to_numerical_value(T) static member function returning a quantity's raw value of rep type packed in either convert_explicitly or convert_implicitly wrapper.from_numerical_value(rep) static member function returning T packed in either convert_explicitly or convert_implicitly wrapper.For example, for our Meter type, we could provide the following:
template<>\nstruct mp_units::quantity_like_traits<Meter> {\n static constexpr auto reference = si::metre;\n using rep = decltype(Meter::value);\n static constexpr convert_implicitly<rep> to_numerical_value(Meter m) { return m.value; }\n static constexpr convert_explicitly<Meter> from_numerical_value(rep v) { return Meter{v}; }\n};\nAfter that, we can check that the QuantityLike concept is satisfied:
static_assert(mp_units::QuantityLike<Meter>);\nand we can write the following:
void print(Meter m) { std::cout << m.value << \" m\\n\"; }\n\nint main()\n{\n using namespace mp_units;\n using namespace mp_units::si::unit_symbols;\n\n Meter height{42};\n\n // implicit conversions\n quantity h1 = height;\n quantity<isq::height[m], int> h2 = height;\n\n std::cout << h1 << \"\\n\";\n std::cout << h2 << \"\\n\";\n\n // explicit conversions\n print(Meter(h1));\n print(Meter(h2));\n}\nNote
No matter if we decide to use implicit or explicit conversions, the mp-units will not allow unsafe operations to happen.
If we extend the above example with unsafe conversions, the code will not compile, and we will have to fix the issues first before the conversion may be performed:
UnsafeFixedquantity<isq::height[m]> h3 = height;\nquantity<isq::height[mm], int> h4 = height;\nquantity<isq::height[km], int> h5 = height; // Compile-time error (1)\n\nstd::cout << h3 << \"\\n\";\nstd::cout << h4 << \"\\n\";\nstd::cout << h5 << \"\\n\";\n\nprint(Meter(h3)); // Compile-time error (2)\nprint(Meter(h4)); // Compile-time error (3)\nprint(Meter(h5));\ndouble to int is not value-preserving.quantity<isq::height[m]> h3 = height;\nquantity<isq::height[mm], int> h4 = height;\nquantity<isq::height[km], int> h5 = quantity{height}.force_in(km);\n\nstd::cout << h3 << \"\\n\";\nstd::cout << h4 << \"\\n\";\nstd::cout << h5 << \"\\n\";\n\nprint(Meter(value_cast<int>(h3)));\nprint(Meter(h4.force_in(m)));\nprint(Meter(h5));\nTo play with quantity point conversions, let's assume that we have a Timestamp strong type in our codebase, and we would like to start using mp-units to work with this abstraction.
struct Timestamp {\n int seconds;\n};\nAs we described in The Affine Space chapter, timestamps should be modeled as quantity points rather than regular quantities.
To allow the conversion between our custom Timestamp type and the quantity_point class template we need to provide the following in the partial specialization of the quantity_point_like_traits<T> type trait:
reference that provides the quantity point reference (e.g., unit),point_origin that specifies the absolute point, which is the beginning of our measurement scale for our points,rep type that specifies the underlying storage type,to_numerical_value(T) static member function returning a raw value of the quantity being the offset of the point from the origin packed in either convert_explicitly or convert_implicitly wrapper.from_numerical_value(rep) static member function returning T packed in either convert_explicitly or convert_implicitly wrapper.For example, for our Timestamp type, we could provide the following:
template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n static constexpr auto reference = si::second;\n static constexpr auto point_origin = default_point_origin(reference);\n using rep = decltype(Timestamp::seconds);\n static constexpr convert_implicitly<rep> to_numerical_value(Timestamp ts) { return ts.seconds; }\n static constexpr convert_explicitly<Timestamp> from_numerical_value(rep v) { return Timestamp(v); }\n};\nAfter that, we can check that the QuantityPointLike concept is satisfied:
static_assert(mp_units::QuantityPointLike<Timestamp>);\nand we can write the following:
void print(Timestamp ts) { std::cout << ts.seconds << \" s\\n\"; }\n\nint main()\n{\n using namespace mp_units;\n using namespace mp_units::si::unit_symbols;\n\n Timestamp ts{42};\n\n // implicit conversion\n quantity_point qp = ts;\n\n std::cout << qp.quantity_from_zero() << \"\\n\";\n\n // explicit conversion\n print(Timestamp(qp));\n}\nIn the C++ standard library, we have two types that handle quantities and model the affine space. Those are:
std::chrono::duration - specifies quantities of time,std::chrono::time_point - specifies quantity points of time.The mp-units library comes with built-in interoperability with those types. It is enough to include the mp-units/systems/si/chrono.h file to benefit from it. This file provides:
quantity_like_traits and quantity_point_like_traits that provide support for implicit conversions between std and mp_units types in both directions,chrono_point_origin<Clock> point origin for std clocks,to_chrono_duration and to_chrono_time_point dedicated conversion functions that result in types exactly representing mp-units abstractions.Important
Only a quantity_point that uses chrono_point_origin<Clock> as its origin can be converted to the std::chrono abstractions:
inline constexpr struct ts_origin final : relative_point_origin<chrono_point_origin<system_clock> + 1 * h> {} ts_origin;\ninline constexpr struct my_origin final : absolute_point_origin<isq::time> {} my_origin;\n\nquantity_point qp1 = sys_seconds{1s};\nauto tp1 = to_chrono_time_point(qp1); // OK\n\nquantity_point qp2 = chrono_point_origin<system_clock> + 1 * s;\nauto tp2 = to_chrono_time_point(qp2); // OK\n\nquantity_point qp3 = ts_origin + 1 * s;\nauto tp3 = to_chrono_time_point(qp3); // OK\n\nquantity_point qp4 = my_origin + 1 * s;\nauto tp4 = to_chrono_time_point(qp4); // Compile-time Error (1)\n\nquantity_point qp5{1 * s};\nauto tp5 = to_chrono_time_point(qp5); // Compile-time Error (2)\nmy_origin is not defined in terms of chrono_point_origin<Clock>.zeroth_point_origin is not defined in terms of chrono_point_origin<Clock>.Here is an example of how interoperability described in this chapter can be used in practice:
using namespace std::chrono;\n\nsys_seconds ts_now = floor<seconds>(system_clock::now());\n\nquantity_point start_time = ts_now;\nquantity speed = 925. * km / h;\nquantity distance = 8111. * km;\nquantity flight_time = distance / speed;\nquantity_point exp_end_time = start_time + flight_time;\n\nsys_seconds ts_end = value_cast<int>(exp_end_time.in(s));\n\nauto curr_time = zoned_time(current_zone(), ts_now);\nauto mst_time = zoned_time(\"America/Denver\", ts_end);\n\nstd::cout << \"Takeoff: \" << curr_time << \"\\n\";\nstd::cout << \"Landing: \" << mst_time << \"\\n\";\nThe above may print the following output:
Takeoff: 2023-11-18 13:20:54 UTC\nLanding: 2023-11-18 15:07:01 MST\nThe mp-units allows us to implement nice and terse code targeting a specific C++ version and configuration. Such code is easy to write and understand but might not be portable to some older environments.
However, sometimes, we want to develop code that can be compiled on a wide range of various compilers and configurations. This is why the library also exposes and uses special preprocessor macros that can be used to ensure the wide compatibility of our code.
Note
Those macros are used in our short example applications as those are meant to be built on all of the supported compilers. Some still do not support std::format, C++ modules, or C++ versions newer than C++20.
Depending on your compiler's conformance, you can choose to use any of the below styles to write your code using mp-units:
C++23C++20C++20 with header filesC++20 with header files + libfmtWide Compatibility#include <format>\n#include <iostream>\nimport mp_units;\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n#include <format>\n#include <iostream>\nimport mp_units;\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <format>\n#include <iostream>\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <fmt/format.h>\n#include <iostream>\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << fmt::format(...) << \"\\n\";\n#include <iostream>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_MODULES\n#include <mp-units/compat_macros.h>\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n\n// ...\n\nQUANTITY_SPEC(horizontal_length, isq::length);\n\n// ...\n\nstd::cout << MP_UNITS_STD_FMT::format(...) << \"\\n\";\nTip
Depending on your preferences, you can either write:
This chapter describes only the most essential tools the mp-units users need. All the compatibility macros can be found in the mp-units/compat_macros.h header file.
Tip
The mp-units/compat_macros.h header file is implicitly included when we use \"legacy\" headers in our translation units. However, it has to be explicitly included when we use C++20 modules, as those do not propagate preprocessor macros.
"},{"location":"users_guide/use_cases/wide_compatibility/#QUANTITY_SPEC","title":"QUANTITY_SPEC(name, ...)","text":"Quantity specification definitions benefit from an explicit object parameter added in C++23 to remove the need for CRTP idiom, which significantly simplifies the code.
This macro benefits from the new C++23 feature if available. Otherwise, it uses the CRTP idiom under the hood.
"},{"location":"users_guide/use_cases/wide_compatibility/#mp_units_std_fmt","title":"MP_UNITS_STD_FMT","text":"Some of the supported compilers do not support std::format and related tools. Also, despite using a conformant compiler, some projects still choose to use fmtlib as their primary formatting facility (e.g., to benefit from additional features provided with the library).
This macro resolves to either the std or fmt namespace, depending on the value of MP_UNITS_API_STD_FORMAT CMake option.
To include the header files of the underlying text formatting framework, the following include should be used:
#include <mp-units/ext/format.h>\nThe mp-units library internally does contract checking by default. It can be disabled with a Conan or CMake option. However, when enabled, it can use either gsl-lite or ms-gsl. To write a code that is independent from the underlying framework, the following preprocessor macros are exposed:
MP_UNITS_EXPECTS(expr)MP_UNITS_EXPECTS_DEBUG(expr)MP_UNITS_ASSERT(expr)MP_UNITS_ASSERT_DEBUG(expr)Their meaning is consistent with respective gsl-lite.
Also, to include the header files of the underlying framework, the following include should be used:
#include <mp-units/ext/contracts.h>\nIn case we are working with a legacy/unsafe interface, we may need to extract the numerical value of a quantity and pass it to some third-party legacy unsafe interfaces.
In such situations we can use .numerical_value_in(Unit) member function:
void legacy_check_speed_limit(int speed_in_km_per_h);\nlegacy_check_speed_limit((180 * km / (2 * h)).numerical_value_in(km / h));\nSuch a getter will explicitly enforce the usage of a correct unit required by the underlying interface, which reduces a significant number of safety-related issues.
The above code will not compile in case value truncation may happen. To solve the issue, we need to either use a value-preserving representation type or force the truncating conversion with .force_numerical_value_in(Unit):
legacy_check_speed_limit((140 * mi / (2 * h)).force_numerical_value_in(km / h));\nThe getters mentioned above always return by value as a quantity value conversion may be required to adjust it to the target unit. In case a user needs a reference to the underlying storage .numerical_value_ref_in(Unit) should be used:
void legacy_set_speed_limit(int* speed_in_km_per_h) { *speed_in_km_per_h = 100; }\nquantity<km / h, int> speed_limit;\nlegacy_set_speed_limit(&speed_limit.numerical_value_ref_in(km / h));\nThis member function again requires a target unit to enforce safety. This overload does not participate in overload resolution if the provided unit has a different scaling factor than the current one.
"},{"location":"blog/archive/2024/","title":"2024","text":""},{"location":"blog/archive/2023/","title":"2023","text":""},{"location":"blog/category/wg21/","title":"WG21","text":""},{"location":"blog/category/releases/","title":"Releases","text":""},{"location":"users_guide/examples/tags_index/","title":"Tags Index","text":"Note
mp-units usage example applications are meant to be built on all of the supported compilers. This is why they benefit from the Wide Compatibility mode.
Tip
All usage examples in this chapter are categorized with appropriate tags to simplify navigation and search of relevant code. You can either read all the examples one-by-one in the order provided by the documentation authors or, thanks to the tagging system, jump straight to the example that is the most interesting for you.
"},{"location":"users_guide/examples/tags_index/#cgs-system","title":"CGS System","text":"mp-units is a compile-time enabled feature-rich Modern C++ modular/header-only library that provides compile-time dimensional analysis and unit/quantity manipulation. Its key strengths include safety, performance, and developer experience.
The library source code is hosted on GitHub with a permissive MIT license.
Supported compilersThis library tries to provide the best user experience possible with the C++ language. To achieve that, it extensively uses the latest C++ language features.
Even though the library benefits from the latest C++ versions (if available), C++20 is enough to compile and use all of the library's functionality.
Please refer to C++ compiler support chapter for more details.
C++ modulesHeader files#include <iostream>\n#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\ninline constexpr struct smoot final : named_unit<\"smoot\", mag<67> * usc::inch> {} smoot;\n\nint main()\n{\n constexpr quantity dist = 364.4 * smoot;\n std::println(\"Harvard Bridge length = {::N[.1f]} ({::N[.1f]}, {::N[.2f]}) \u00b1 1 \u03b5ar\",\n dist, dist.in(usc::foot), dist.in(si::metre));\n}\n#include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <mp-units/systems/usc.h>\n#include <print>\n\nusing namespace mp_units;\n\ninline constexpr struct smoot final : named_unit<\"smoot\", mag<67> * usc::inch> {} smoot;\n\nint main()\n{\n constexpr quantity dist = 364.4 * smoot;\n std::println(\"Harvard Bridge length = {::N[.1f]} ({::N[.1f]}, {::N[.2f]}) \u00b1 1 \u03b5ar\",\n dist, dist.in(usc::foot), dist.in(si::metre));\n}\nOutput:
Harvard Bridge length = 364.4 smoot (2034.6 ft, 620.14 m) \u00b1 1 \u03b5ar\nTry it on Compiler Explorer
What issmoot? The smoot (/\u02c8smu\u02d0t/) is a nonstandard unit of length created as part of an MIT fraternity prank. It is named after Oliver R. Smoot, a fraternity pledge to Lambda Chi Alpha, who, in October 1958, lay on the Harvard Bridge (between Boston and Cambridge, Massachusetts) and was used by his fraternity brothers to measure the length of the bridge.
One smoot equals Oliver Smoot's height at the time of the prank (five feet and seven inches). The bridge's length was measured to be 364.4 smoots plus or minus one ear, with the \"plus or minus\" intended to express the measurement uncertainty.
Oliver Smoot graduated from MIT with the class of 1962, became a lawyer, and later became chairman of the American National Standards Institute (ANSI) and president of the International Organization for Standardization (ISO).
More on the smoot unit of length can be found at https://en.wikipedia.org/wiki/Smoot.
Important: Help needed!
The mp-units library might be the subject of ISO standardization for C++29. More on this can be found in the following ISO C++ proposals:
We are actively looking for parties interested in field-trialing the library.
"},{"location":"release_notes/","title":"Release Notes","text":""},{"location":"release_notes/#mp-units","title":"mp-units","text":""},{"location":"release_notes/#2.3.0","title":"2.3.0 WIP","text":"delta and absolute construction helpershas_unit_symbol support removedcore.h removedfinalfma, isfinite, isinf, and isnan math function added by @NAThompsonfma for quantity points addedquantity_point support added for quantity_cast and value_castvalue_cast<Unit, Representation> addedvalue_cast<Quantity>(q), value_cast<Quantity>(qp) and value_cast<QuantityPoint>(qp) added by @burnpanckinterconvertible(QuantitySpec, QuantitySpec) addedqp.quantity_from_zero() addedvalue_type type trait addedpercent or per_milleppm parts per million added by @nebkatatan2 2-argument arctangent added by @nebkatfmod floating-point division remainder added by @nebkatremainder IEEE division remainder added by @nebkatstd::format support added() in references, prefixes, and kind_ofzero_Fahrenheit renamed to zeroth_degree_Fahrenheitsi subnamespacemath.h header file broke up to smaller piecesfixed_string interface refactoredReferenceOf does not take a dimension anymoreunit_symbol_solidus::one_denominatorget_kind() now returns kind_ofcompat_macros.hfixed_string refactored to reflect the latest changes to P3094R2basic_symbol_text renamed to symbol_textratio hidden as an implementation detail behind mag_ratioframework.h introducedabsolute_point_origin does not use CRTP anymorefinalsi_quantities.h added to improve compile-timesvalidate_ascii_string refactored to is_basic_literal_character_setunderlying_type split to wrapped_type and value_type and used in code<ranges> header and switch to use an iterator-based copy algorithmterminate replaced with abort and a header file addedstd::remove_const_t removed and some replaced with the GCC-specific workaroundremove_reference_t and remove_cvref_t removedquantity and quantity_point are now hidden friendsQuantityLike conversions required Q::rep instead of using one provided by quantity_like_traitsQuantitySpec[Unit] replaced with make_reference in value_castice_point is now defined with the integral offset from absolute_zerosudo_cast fixedversion header file added to hacks.hquantity_cast to accept lvalue references (thanks @burnpanck)value_cast with lvalue references to quantity_point (thanks @burnpanck)smoot unit example added to the main pageMP_UNITS_AS_SYSTEM_HEADERS renamed to MP_UNITS_BUILD_AS_SYSTEM_HEADERSMP_UNITS_BUILD_LA and MP_UNITS_IWYU CMake options now have _DEV_ in the namecheck_cxx_feature_supported addedCMAKE_EXPORT_COMPILE_COMMANDS flag enabled for the developer's buildgenerate() now set cache_variablescan_run check added before running testsclang-tidy CI addedthis parameter support fixedinverse() support added for dimensions, quantity_spec, units, and references (1 / s will now create quantity and not a Unit)quantity_point does not provide zero() anymorequantity_spec and its kind should not compare equalfixed_stringcommon_type with a raw value is not needed anymore as for a long time now raw values are not convertible to the dimensionless quantitiessymbol_text definition simplifiedbasic_fixed_string(const CharT*, std::integral_constant<std::size_t, N>) constructor addedisq::activity added and becquerel definition updated to benefit from itgray and sievert now have correct associated quantity kindsUnitCompatibleWith concept added and applied to in(U) and force_in(U) functionsMagnitude / Unit operator addedderived_dimension)zero_Fahrenheit point origin addedunit_symbol<fmt>(U) signature refactored and the resulting text can now also be used at runtimemake_xxx factory functions replaced with two-parameter constructorsunit_symbol changed to constevalin(U) and force_in(U) now return auto to provide better diagnostics on clangquantity operators constraints refactoredfixed_string definitionunit_symbol_formatting enums now use std::int8_t as a representation typeunit_symbolCommonlyInvocableQuantities was overconstrained for the current library designare_ingredients_convertible now mandates explicit conversion for To dimensionless quantitiesquantity_point::point_for(PO) constraints fixedlatitude and longitude fixed to include 0 for N and E respectivelyCameCase concept identifiers FAQ addedgravitational_potential_energy equation fixed on a graphunits namespace renamed to mp_units (#317)<mp-units/...> rather then in <units/...> (#317)quantity_point (#414)quantity_spec to store not only dimension but also additional information about quantities (#405)quantity now takes reference object, which aggregates quantity_spec and a unit and a representation typefmtquantity_kind removed.in(Unit), .force_in(Unit) for quantity and quantity_spec.numerical_value_in(Unit) and .force_numerical_value_in(Unit)quantity can no longer be constructed with a raw value (#434)quantity_point can no longer be constructed with just a quantity and an explicit PointOrigin is always neededceil and floor are dangerous (#432)common_quantity, common_quantity_for, common_quantity_point, common_quantity_kind, and common_quantity_point_kind removednamed_derived_unit removed as it was not usedderived_unit renamed to derived_scaled_unitunit renamed to derived_unitU::is_named removed from the unit types and replaced with NamedUnit conceptPrefixFamily support removedmi(naut) renamed to nmiknot unit helper renamed to kn in FPSknot text symbol changed from \"knot\" to \"kn\"quantity op+() and op-() reimplemented in terms of reference rather then quantity typesglide_computer now use dimensionless quantities with ranged_representation as repfloor(), ceil(), and round() support added (thanks @hofbi)std::format support for compliant compilers addedmp-units to std::chrono types addedquantity_point to std::chrono::time_point addednautical_mile_per_hour and knot added to si::international systemquantity_point::origin, like std::chrono::time_point::clockhectare definition fixed to be a prefixed version of are + other unitsquantity_point_cast's constraintfmt algorithms were overconstrained with forward_iteratorderived_ratio calculationfill_t assignment operator fixedradioactivity header compilation fixedsi::hep::dim_momentum duplicated definition fixedfps can now coexist with international systemCMAKE_BUILD_TYPE in the conan_toolchain.cmake anymoreconanfile.py refactored to be Conan 2.0 readyvalidate() replaced with configure() to raise errors during conan install in Conan 1.Xlinear-algebra Conan repo is no needed anymoremp-units-systemCITATION.cff file addedCONTRIBUTING.md updatedScalableNumber renamed to Representationunits/quantity_io.h header filequantity::count() renamed to quantity::number()data system renamed to isq::iec80000 (quantity names renamed too)*deduced_unit renamed to *derived_unitnoble_derived_unitquantityquantity and quantity_cast refactoredabs() definition refactored to be more explicit about the return typestd::chrono::duration and other units librariesmodulation_rate support added (thanks @go2sh)isq::iec80000 support added (thanks @go2sh)UNITS_NO_LITERALS preprocessor definequantity_cast() generates less assembly instructionsquantity::op<<()equivalent trait usageexp() has sense only for dimensionless quantitiesdim_torque now properly divides by an angle (instead of multiply) + default unit name changequantity_cast() fixed to work correctly with representation types not convertible from std::intmax_tfoot_pound_force and foot_pound_force_per_secondBUILD_DOCS CMake option renamed to UNITS_BUILD_DOCScmake_find_package_multiquantity_point support added (thanks @johelegp)si::angular_velocity support added (thanks @mikeford3)exp(quantity)q_* UDL renamed to _q_**p* to *_per_*ratio changed to the NTTP kindexp and Exp renamed to exponent and ExponentScalar concept renamed to ScalableNumberquantity typemath.h function signatures refactored to use a Quantity concept (thanks @kwikius)[[nodiscard]] added to many functionssi::day unit symbol fixed to d (thanks @komputerwiz)si::mole unit symbol fixed to mol (thanks @mikeford3)ratio refactored to contain Exp template parameter (thanks a lot @oschonrock!)q_ prefix applied to all the UDLs (thanks @kwikius)unknown_unit renamed to unknown_coherent_unitstd::experimental::math support addedalias_unit (thanks @yasamoka)physical namespaceMany thanks to GitHub users @oschonrock, @kwikius, and @i-ky for their support in drafting a new library design.
"},{"location":"release_notes/#0.4.0","title":"0.4.0 Nov 17, 2019","text":"exp addedpow() and sqrt() operations on quantitiesunits removed from a std::experimental namespacebase_dimension class templatebase_dimension and derived unitsoperator<< on quantityfmt support addedupcasting_traits renamed to downcasting_traitsDimension template parameter removed from quantityunits moved to a std::experimental namespacemeter renamed to metreoperator* addeddimension_ prefix removed from names of derived dimensionsbase_dimension is a value provided as const& to the exp typeQuantityOf concept introducedquantity_cast<U, Rep>() support addedstd::remove_cvref_t, down with typename, std::type_identity)type_list, common_ratio, ratio, conditional_t)Note
The ISO terms provided below are only a few of many defined in the ISO/IEC Guide 99.
quantity kind of quantity, kind system of quantities base quantity derived quantity International System of Quantities, ISQ quantity dimension, dimension of a quantity, dimension Symbols representing the dimensions of the base quantities in the ISQ are:
Base quantity Symbol for dimension length \\(\\mathsf{L}\\) mass \\(\\mathsf{M}\\) time \\(\\mathsf{T}\\) electric current \\(\\mathsf{I}\\) thermodynamic temperature \\(\\mathsf{\u0398}\\) amount of substance \\(\\mathsf{N}\\) luminous intensity \\(\\mathsf{J}\\)Thus, the dimension of a quantity \\(Q\\) is denoted by \\(\\textsf{dim }Q = \\mathsf{L}^\u03b1\\mathsf{M}^\u03b2\\mathsf{T}^\u03b3\\mathsf{I}^\u03b4\\mathsf{\u0398}^\u03b5\\mathsf{N}^\u03b6\\mathsf{J}^\u03b7\\) where the exponents, named dimensional exponents, are positive, negative, or zero.
quantity of dimension one, dimensionless quantity measurement unit, unit of measurement, unit base unit derived unit coherent derived unit system of units coherent system of units off-system measurement unit, off-system unit International System of Units, SI quantity value, value of a quantity, value numerical quantity value, numerical value of a quantity, numerical value quantity equation unit equation numerical value equation, numerical quantity value equation Info
The below terms extend the official ISO glossary and are commonly referred to by the mp-units library.
base dimension derived dimension dimension equation quantity kind hierarchy, quantity hierarchy quantity character, character of a quantity, character ISO 80000-1_2009
In deriving the dimension of a quantity, no account is taken of its scalar, vector, or tensor character.
quantity specification, quantity_spec unit with an associated quantity, associated unit quantity reference, reference canonical representation of a unit, canonical unit reference unit See canonical representation of a unit
absolute quantity point origin, absolute point origin relative quantity point origin, relative point origin quantity point origin, point origin quantity point, absolute quantity ISO80000 ISO 80000-1:2009(E) \"Quantities and units \u2014 Part 1: General\", International Organization for Standardization.
Quincey \"Angles in the SI: a detailed proposal for solving the problem, Quincey, Paul (1 October 2021). SIBrochure The International System of Units (SI), International Bureau of Weights and Measures (20 May 2019), ISBN 978-92-822-2272-0.
"},{"location":"blog/","title":"Blog","text":""},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/","title":"What's new in mp-units 2.0?","text":"After a year of hard work, we've just released mp-units 2.0.0. It can be obtained from GitHub and Conan.
The list of the most significant changes introduced by the new version can be found in our Release Notes. We will also describe some of them in this post.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#why-20-if-10-was-never-released","title":"Why 2.0 if 1.0 was never released?","text":"Version 2 of the mp-units project is a huge change and a new quality for the users. We did not want to pretend that 2.0 is an evolutionary upgrade of the previous version of the project. It feels like a different product.
We could start a new repo named \"mp-units-v2\" similarly to range-v3 but we decided not to go this path. We kept the same repo and made the scope of the changes and potential breakage explicit with a drastic bump in the project version.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#what-has-changed","title":"What has changed?","text":"The answer is \"nearly everything\". The whole library and its documentation were rewritten nearly from scratch.
Here are the significant changes that the users can observe:
Repository name
If you didn't notice, the repository name was changed from \"mpusz/units\" to \"mpusz/mp-units\".
Header files content and layout
Previously, all the header files resided in the include/units directory. Now, they can be found in include/mp-units. The project file tree was significantly changed as well. Many files were moved to different subdirectories or renamed.
Namespace
Previously, all the definitions were provided in the units namespace, and now they are in the mp_units one.
Abstractions, interfaces, definitions
The interfaces of all of the types were refactored. We got unit symbols and a new way to construct a quantity and quantity_point. The readability of the generated types was improved thanks to the introduction of expression templates. Nearly all of the template arguments are now passed by values thanks to class NTTP extensions in C++20. As a result, unit definitions are much easier and terser. Also, the V2 has a powerful ability to model systems of quantities and provides definitions for many ISQ quantities.
Conan 2.0
Also, now we support Conan 2.0, which provides an updated way of handling dependencies.
Some cornerstones of the initial design did not prove in practice and were removed while we moved to version 2.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#the-downcasting-facility","title":"The downcasting facility","text":"The first and the most important of such features was removing the downcasting facility. This feature is still a powerful metaprogramming technique that allows users to map long class template instantiations to nicely named, short, and easy-to-understand user's strong types.
Such mapping works perfectly fine for 1-to-1 relationships. However, we often deal with N-to-1 connections in the quantities and units domain. Here are only a few such examples:
In the above examples, multiple entities \"wanted\" to register different names for identical class template instantiations, resulting in compile-time errors. We had to invent some hacks and workarounds to make it work, but we were never satisfied with the outcome.
Additionally, this facility could easily lead to ODR violations or provide different results depending on which header files were included in the translation units. This was too vulnerable to be considered a good practice here.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#no-udls-anymore","title":"No UDLs anymore","text":"Over the years, we have learned that UDLs are not a good solution. More information on this subject can be found in the Why don't we use UDLs to create quantities? chapter.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#no-construction-of-a-quantity-from-a-raw-value","title":"No construction of aquantity from a raw value","text":"To improve safety, we no longer allow the construction of quantities from raw values. In the new design, we always need to explicitly specify a unit to create a quantity:
quantity q1 = 42 * m;\nquantity<si::metre> = 2 * km;\nquantity q3(42, si::metre);\nThe previous approach was reported to be error-prone under maintenance. More on this subject can be found in the Why can't I create a quantity by passing a number to a constructor? chapter.
"},{"location":"blog/2023/09/24/whats-new-in-mp-units-20/#new-look-and-feel","title":"New look and feel","text":"Here is a concise example showing you the new look and feel of the library:
#include <mp-units/format.h>\n#include <mp-units/systems/isq/isq.h>\n#include <mp-units/systems/si/si.h>\n#include <format>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity<isq::speed[m / s]> avg_speed(quantity<si::metre> d,\n quantity<si::second> t)\n{ return d / t; }\n\nint main()\n{\n auto speed = avg_speed(220 * km, 2 * h);\n std::println(\"{}\", speed); // 30.5556 m/s\n}\nAll of the changes we provided, although breaking ones, resulted in much better, easier, and safer abstractions. These offer a new quantity on the market and hopefully will be appreciated by our users.
Please check our new documentation to learn about the latest version of the project and find out how to benefit from all the new cool stuff we have here.
"},{"location":"blog/2023/12/09/mp-units-210-released/","title":"mp-units 2.1.0 released!","text":"A new product version can be obtained from GitHub and Conan.
The list of the most significant changes introduced by the new version can be found in our Release Notes. We will also describe the most important of them in this post.
"},{"location":"blog/2023/12/09/mp-units-210-released/#no-more-parenthesis-while-creating-quantities-with-derived-units","title":"No more parenthesis while creating quantities with derived units","text":"The V2 design introduced a way to create a quantity by multiplying a raw value and a unit:
quantity q1 = 42 * m;\nHowever, this meant that when we wanted to create a quantity having a derived unit, we had to put parenthesis around the unit equation or create a custom value of the named unit:
quantity q2 = 60 * (km / h);\n\nconstexpr auto kmph = km / h;\nquantity q3 = 60 * kmph;\n\nquantity q4 = 50 * (1 / s);\nWith the new version, we removed this restriction, and now we can type:
quantity q5 = 60 * km / h;\nquantity q6 = 50 / s;\nAs a side effect, we introduced a breaking change . We can't use the following definition of hertz anymore:
inline constexpr struct hertz : named_unit<\"Hz\", 1 / second, kind_of<isq::frequency>> {} hertz;\nand have to type either:
inline constexpr struct hertz : named_unit<\"Hz\", one / second, kind_of<isq::frequency>> {} hertz;\nor
inline constexpr struct hertz : named_unit<\"Hz\", inverse(second), kind_of<isq::frequency>> {} hertz;\nTo be consistent, we applied the same change to the dimensions and quantity specifications definitions. Now, to define a frequency we have to type:
C++23C++20Portableinline constexpr struct frequency : quantity_spec<inverse(period_duration)> {} frequency;\ninline constexpr struct frequency : quantity_spec<frequency, inverse(period_duration)> {} frequency;\nQUANTITY_SPEC(frequency, inverse(period_duration));\nmake_xxx factory functions replaced with two-parameter constructors","text":"In the initial version of the V2 framework, if someone did not like the multiply syntax to create a quantity we provided the make_quantity() factory function. A similar approach was used for quantity_point creation.
This version removes those ( breaking change ) and introduces two parameter constructors:
quantity q(42, si::metre);\nquantity_point qp(q, mean_sea_level);\nThe above change encourages a better design and results in a terser code.
"},{"location":"blog/2023/12/09/mp-units-210-released/#improved-definitions-of-becquerel-gray-and-sievert","title":"Improved definitions of becquerel, gray, and sievert","text":"In the initial V2 version, we lacked the definitions of the atomic and nuclear physics quantities, which resulted in simplified and unsafe definitions of becquerel, gray, and sievert units. We still do not model most of the quantities from this domain, but we've added the ones that are necessary for the definition of those units.
Thanks to the above, the following expressions will not compile:
quantity q1 = 1 * Hz + 1 * Bq;\nquantity<si::sievert> q2 = 42 * Gy;\nAnother significant improvement in this version was redesigning the way we provide compatibility with other similar libraries. The interfaces of quantity_like_traits and quantity_point_like_traits were changed and extended to provide conversion not only from but also to entities from other libraries ( breaking change ).
We've also introduced an innovative approach that allows us to specify if such conversions should happen implicitly or if they need to be forced explicitly.
More on this subject can be found in the Interoperability with Other Libraries chapter.
"},{"location":"blog/2023/12/09/mp-units-210-released/#point-origins-can-now-be-derived-from-each-other","title":"Point origins can now be derived from each other","text":"Previously, each class derived from absolute_point_origin was considered a unique independent point origin. On the other hand, it was OK to derive multiple classes from the same relative_point_origin, and those were specifying the same point in the domain. We found this confusing and limiting. This is why, in this version, the absolute_point_origin uses a CRTP idiom to be able to detect between points that should be considered different from the ones that should be equivalent.
If we derive from the same instantiation of absolute_point_origin we end up with an equivalent point origin. This change allows us to provide different names for the same temperature points:
inline constexpr struct absolute_zero : absolute_point_origin<absolute_zero, isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr struct zeroth_kelvin : decltype(absolute_zero) {} zeroth_kelvin;\n\ninline constexpr struct ice_point : relative_point_origin<absolute_zero + 273.15 * kelvin> {} ice_point;\ninline constexpr struct zeroth_degree_Celsius : decltype(ice_point) {} zeroth_degree_Celsius;\nPlease note that this is a breaking change as well.
"},{"location":"blog/2023/12/09/mp-units-210-released/#unit-symbol-text-can-now-be-properly-used-at-runtime","title":"Unit symbol text can now be properly used at runtime","text":"The interface of the previous definition of unit_symbol function allowed the use of the returned buffer only at compile-time. This was too limiting as users often want to use unit symbols at runtime (e.g., print them to the console). The new version redesigned the interface of this function ( breaking change ) to return a buffer that can be properly used at both compilation and runtime:
std::string_view unit1 = unit_symbol(m / s);\nstd::cout << unit1 << \"\\n\"; // m/s\nstd::string_view unit2 = unit_symbol<{.solidus = unit_symbol_solidus::never}>(m / s);\nstd::cout << unit2 << \"\\n\"; // m s\u207b\u00b9\nA new product version can be obtained from GitHub and Conan.
Among other features, this release provides long-awaited support for C++20 modules, redesigns and enhances text output formatting, and greatly simplifies quantity point usage. This post describes those and a few other smaller interesting improvements, while a much longer list of the most significant changes introduced by the new version can be found in our Release Notes.
"},{"location":"blog/2024/06/14/mp-units-220-released/#c20-modules-and-project-structure-cleanup","title":"C++20 modules and project structure cleanup","text":"GitHub Issue #7 was our oldest open issue before this release. Not anymore. After 4.5 years, we finally closed it, even though the C++ modules' support is still really limited.
Info
To benefit from C++ modules, we need at least:
In the upcoming months, hopefully, the situation will improve with the bug fixes in CMake, gcc-14, and MSVC.
Note
More requirements for C++ modules support can be found in the CMake's documentation.
To enable the compilation and distribution of C++ modules, a cxx_modules Conan or MP_UNITS_BUILD_CXX_MODULES CMake option has to be enabled.
With the above, the following C++ modules will be provided:
flowchart TD\n mp_units --- mp_units.systems --- mp_units.coremp_units.core mp-units::core Core library framework and systems-independent utilities mp_units.systems mp-units::systems All the systems of quantities and units mp_units mp-units::mp-units Core + Systems The easiest way to use them is just to import mp_units; at the beginning of your translation unit (see the Quick Start chapter for some usage examples).
Note
C++20 modules support still have some issues when imported from the installed CMake target. See the following GitLab issue for more details.
In this release, we also highly limited the number of CMake targets ( breaking change ). Now, they correspond exactly to the C++ modules they provide. This means that many smaller partial targets were removed. We also merged text output targets with the core library's definition.
The table below specifies where we can now find the contents of previously available CMake targets:
Before Nowmp-units::utility mp-units::core mp-units::core-io mp-units::core mp-units::core-fmt mp-units::core mp-units::{system_name} mp-units::systems While we were enabling C++ modules, we also had to refactor our header files slightly ( breaking change ). Some had to be split into smaller pieces (e.g., math.h), while others had to be moved to a different subdirectory (e.g., chrono.h).
In version 2.2, the following headers have a new location or contents:
Header File C++ Module Contents mp-units/math.hmp_units.core System-independent functions only mp-units/systems/si/math.h mp_units.systems Trigonometric functions using si::radian mp-units/systems/angular/math.h mp_units.systems Trigonometric functions using angular::radian mp-units/systems/si/chrono.h mp_units.systems std::chrono compatibility traits Benefiting from this opportunity, we also cleaned up core and systems definitions ( breaking change ).
Regarding the library's core, we removed core.h and exposed only one header framework.h that provides all of the library's framework so the user does not have to enumerate files like unit.h, quantity.h, and quantity_point.h anymore. Those headers are not gone, they were put to the mp-units/framework subheader. So they are still there if you really need them.
Regarding the changes in systems definitions, we moved the wrapper header files with the entire system definition to the mp-units/systems subdirectory. Additionally, they now also include framework.h, so a system include is enough to use the library. Thanks to that our users don't have to write tedious code like the below anymore:
#include <mp-units/systems/cgs.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n\n// ...\n#include <mp-units/quantity_point.h>\n#include <mp-units/systems/cgs/cgs.h>\n#include <mp-units/systems/international/international.h>\n#include <mp-units/systems/isq/isq.h>\n#include <mp-units/systems/si/si.h>\n\n// ...\nAdditionally, we merged all of the compatibility-related macros into one header file mp-units/compat_macros.h. This header file should be explicitly included before importing C++ modules if we want to benefit from the Wide Compatibility tools.
With this release, nearly all of the Conan and CMake build options were refactored with the intent of providing better control over the library's API.
Previously, the library used the latest available feature set supported by a specific compiler. For example, quantity_spec definitions would use CRTP on an older compiler or provide a simpler API on a newer one thanks to the C++23 this deduction feature. This could lead to surprising results where the same code written by the user would compile fine on one compiler but not the other.
From this release, all API extensions have their corresponding configuration options in Conan and CMake. With this, a user has full control over the API exposed by the library. Those options expose three values:
True - The feature is always enabled (the configuration error will happen if the compiler does not support this feature)False - The feature is disabled, and an older alternative is always used.Auto - The feature is automatically enabled if the compiler supports it (old behavior).Additionally, some CMake options were renamed to better express the impact on our users ( breaking change ). For example, now CMake options include:
MP_UNITS_API_* - options affecting the library's API,MP_UNITS_BUILD_* - options affecting the build process,MP_UNITS_DEV_* - options primarily useful for the project developers or people who want to compile our unit tests and examples.Before this release, the library always depended on gsl-lite to perform runtime contract and asserts checking. In this release we introduced new options to control if contract checking should be based on gsl-lite, ms-gsl, or may be completely disabled.
"},{"location":"blog/2024/06/14/mp-units-220-released/#freestanding-support","title":"Freestanding support","text":"From this release it is possible to configure the library in the freestanding mode. This limits the functionality and interface of the library to be compatible with the freestanding implementations.
Info
To learn more, please refer to the Build options chapter.
"},{"location":"blog/2024/06/14/mp-units-220-released/#simplified-quantity-point-support","title":"Simplified quantity point support","text":"This release significantly simplifies the usage of quantity points and affine space abstractions in general.
Previously, the user always had to define an explicit point origin even if the domain being modeled does not have such an explicit origin. Now, in such cases, we can benefit from the implicit point origins. For example:
NowBeforequantity_point price_usd{100 * USD};\nconstexpr struct zero final : absolute_point_origin<currency> {} zero;\n\nquantity_point price_usd = zero + 100 * USD;\nAs we can see above, the new design allows direct-initializing quantity_point class template from a quantity, but only if the former one is defined in terms of the implicit point origin. Otherwise, an explicit origin still always has to be provided during initialization.
Also, we introduced the possibility of specifying a default point origin in the unit definition. With that, we could provide proper temperature scales without forcing the user to always use the origins explicitly. Also, a new member function, .quantity_from_zero(), was introduced that always returns the quantity from the unit's specific point origin or from the implicit point origin otherwise.
quantity_point temp{20 * deg_C};\nstd::cout << \"Temperature: \" << temp << \" (\"\n << temp.in(deg_F).quantity_from_zero() << \", \"\n << temp.in(K).quantity_from_zero() << \")\\n\";\nquantity_point temp = si::zeroth_degree_Celsius + 20 * deg_C;\nstd::cout << \"Temperature: \" << temp << \" (\"\n << temp.in(deg_F).quantity_from(usc::zeroth_degree_Fahrenheit) << \", \"\n << temp.in(K).quantity_from(si::zeroth_kelvin) << \")\\n\";\nMore information about the new design can be found in The Affine Space chapter.
"},{"location":"blog/2024/06/14/mp-units-220-released/#unified-temperature-point-origins-names","title":"Unified temperature point origins names","text":"By omission, we had the following temperature point origins in the library:
si::zero_kelvin (for si::kelvin),si::zeroth_degree_Celsius (for si::degree_Celsius),usc::zero_Fahrenheit (for usc::degree_Fahrenheit).With this release, the last one was renamed to usc::zeroth_degree_Fahrenheit to be consistently named with its corresponding unit and with the si::zeroth_degree_Celsius ( breaking change ).
There were several known issues when units were deriving from each other (e.g., #512 and #537). We could either highly complicate the framework to allow these which could result in much longer compilation times or disallow inheriting from units at all. We chose the second option.
With this release all of of the units must be marked as final. To enforce this we have changed the definition of the Unit<T> concept, which now requires type T to be final ( breaking change ).
WG21 Study Group 16 (Unicode) raised concerns about potential ABI issues when different translation units are compiled with different ordinary literal encodings. Those issues were resolved with a change to units definitions ( breaking change ). It affects only units that specify both Unicode and ASCII symbols. The new design requires the Unicode symbol to be provided as a UTF-8 literal.
This also means that the basic_symbol_text has fixed character types for both symbols. This is why it was renamed to symbol_text ( breaking change ).
inline constexpr struct ohm final : named_unit<symbol_text{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\ninline constexpr struct ohm : named_unit<basic_symbol_text{\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\nNote
On C++20-compliant compilers it should be enough to type the following in the unit's definition:
inline constexpr struct ohm final : named_unit<{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\nSimilarly to units, now also all dimensions, quantity specifications, and point origins have to be marked final ( breaking change ).
inline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct length final : quantity_spec<dim_length> {} length;\n\ninline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr auto zeroth_kelvin = absolute_zero;\ninline constexpr struct kelvin final : named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\n\ninline constexpr struct ice_point final : relative_point_origin<quantity_point{273'150 * milli<kelvin>}> {} ice_point;\ninline constexpr auto zeroth_degree_Celsius = ice_point;\ninline constexpr struct degree_Celsius final : named_unit<symbol_text{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\ninline constexpr struct dim_length : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct length : quantity_spec<dim_length> {} length;\n\ninline constexpr struct absolute_zero : absolute_point_origin<absolute_zero, isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr struct zeroth_kelvin : decltype(absolute_zero) {} zeroth_kelvin;\ninline constexpr struct kelvin : named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\n\ninline constexpr struct ice_point : relative_point_origin<quantity_point{273'150 * milli<kelvin>}> {} ice_point;\ninline constexpr struct zeroth_degree_Celsius : decltype(ice_point) {} zeroth_degree_Celsius;\ninline constexpr struct degree_Celsius : named_unit<symbol_text{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\nPlease also note, that the absolute_point_origin does not use CRTP idiom anymore ( breaking change ).
With this release, we can print not only whole quantities but also just their units or dimensions. Also, we fixed the std::format support so users can now enjoy full C++20 compatibility and don't have to use fmtlib anymore.
We have also changed the grammar for quantities formatting ( breaking change ). It introduces the composition of underlying formatters that finally allows us to properly format user-defined representation types (assuming they have std::format support). Additionally, thanks to a new %? token, we can provide a custom format string that will properly print quantity of any unit.
Here is a small preview of what is now available:
using namespace mp_units::si::unit_symbols;\nusing namespace mp_units::international::unit_symbols;\nquantity q = (90. * km / h).in(mph);\n\nstd::cout << \"Number: \" << q.numerical_value_in(mph) << \"\\n\";\nstd::cout << \"Unit: \" << q.unit << \"\\n\";\nstd::cout << \"Dimension: \" << q.dimension << \"\\n\";\nstd::println(\"{::N[.2f]}\", q);\nstd::println(\"{:.4f} in {} of {}\", q.numerical_value_in(mph), q.unit, q.dimension);\nstd::println(\"{:%N in %U of %D:N[.4f]}\", q);\nNumber: 55.9234\nUnit: mi/h\nDimension: LT\u207b\u00b9\n55.92 mi/h\n55.9234 in mi/h of LT\u207b\u00b9\n55.9234 in mi/h of LT\u207b\u00b9\nMore on this subject can be found in the updated Text Output chapter.
"},{"location":"blog/2024/06/14/mp-units-220-released/#improved-casts","title":"Improved casts","text":"We added a new conversion function. value_cast<Unit, Representation> forces the conversion of both a unit and representation type in one step and always ensures that the best precision is provided.
Also, we have finally added proper implementations of value_cast and quantity_cast for quantity points.
This release made a few small refactorings that, without changing the user-facing API, allowed us to improve the readability of the generated types that can be observed in the compilation errors.
Example 1 (clang):
NowBeforeerror: no matching function for call to 'time_to_goal'\n 26 | const quantity ttg = time_to_goal(half_marathon_distance, pace);\n | ^~~~~~~~~~~~\nnote: candidate template ignored: constraints not satisfied [with distance:auto = quantity<kilo_<metre>{}, double>,\n speed:auto = quantity<derived_unit<second, per<kilo_<metre>>>{}, double>]\n 13 | QuantityOf<isq::time> auto time_to_goal(QuantityOf<isq::length> auto distance,\n | ^\nnote: because 'QuantityOf<quantity<derived_unit<si::second, per<si::kilo_<si::metre> > >{{{}}}>, isq::speed>' evaluated to false\n 14 | QuantityOf<isq::speed> auto speed)\n | ^\nnote: because 'QuantitySpecOf<std::remove_const_t<decltype(quantity<derived_unit<second, per<kilo_<metre> > >{{{}}}, double>::quantity_spec)>, struct speed{{{}}}>' evaluated to false\n 61 | concept QuantityOf = Quantity<Q> && QuantitySpecOf<std::remove_const_t<decltype(Q::quantity_spec)>, QS>;\n | ^\nnote: because 'implicitly_convertible(kind_of_<derived_quantity_spec<isq::time, per<isq::length> > >{}, struct speed{{{}}})' evaluated to false\n 147 | QuantitySpec<T> && QuantitySpec<decltype(QS)> && implicitly_convertible(T{}, QS) &&\n | ^\n1 error generated.\nCompiler returned: 1\nerror: no matching function for call to 'time_to_goal'\n 26 | const quantity ttg = time_to_goal(half_marathon_distance, pace);\n | ^~~~~~~~~~~~\nnote: candidate template ignored: constraints not satisfied [with distance:auto = quantity<kilo_<metre{{}}>{}, double>,\n speed:auto = quantity<derived_unit<second, per<kilo_<metre{{}}>>>{}, double>]\n 13 | QuantityOf<isq::time> auto time_to_goal(QuantityOf<isq::length> auto distance,\n | ^\nnote: because 'QuantityOf<quantity<derived_unit<si::second, per<si::kilo_<si::metre{{}}> > >{{{}}}>, isq::speed>' evaluated to false\n 14 | QuantityOf<isq::speed> auto speed)\n | ^\nnote: because 'QuantitySpecOf<std::remove_const_t<decltype(quantity<derived_unit<second, per<kilo_<metre{{}}> > >{{{}}}, double>::quantity_spec)>, struct speed{{{}}}>' evaluated to false\n 61 | concept QuantityOf = Quantity<Q> && QuantitySpecOf<std::remove_const_t<decltype(Q::quantity_spec)>, QS>;\n | ^\nnote: because 'implicitly_convertible(kind_of_<derived_quantity_spec<isq::time, per<isq::length> >{{}, {{}}}>{}, struct speed{{{}}})' evaluated to false\n 147 | QuantitySpec<T> && QuantitySpec<decltype(QS)> && implicitly_convertible(T{}, QS) &&\n | ^\n1 error generated.\nCompiler returned: 1\nExample 2 (gcc):
NowBeforeerror: no matching function for call to 'Box::Box(quantity<reference<isq::height, si::metre>(), int>, quantity<reference<horizontal_length, si::metre>(), int>,\n quantity<reference<isq::width, si::metre>(), int>)'\n 27 | Box my_box(isq::height(1 * m), horizontal_length(2 * m), isq::width(3 * m));\n | ^\nnote: candidate: 'Box::Box(quantity<reference<horizontal_length, si::metre>()>, quantity<reference<isq::width, si::metre>()>,\n quantity<reference<isq::height, si::metre>()>)'\n 19 | Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n | ^~~\nnote: no known conversion for argument 1 from 'quantity<reference<isq::height, si::metre>(),int>'\n to 'quantity<reference<horizontal_length, si::metre>(),double>'\n 19 | Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^\nerror: no matching function for call to 'Box::Box(quantity<reference<isq::height(), si::metre()>(), int>, quantity<reference<horizontal_length(), si::metre()>(), int>,\n quantity<reference<isq::width(), si::metre()>(), int>)'\n 27 | Box my_box(isq::height(1 * m), horizontal_length(2 * m), isq::width(3 * m));\n | ^\nnote: candidate: 'Box::Box(quantity<reference<horizontal_length(), si::metre()>()>, quantity<reference<isq::width(), si::metre()>()>,\n quantity<reference<isq::height(), si::metre()>()>)'\n 19 | Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n | ^~~\nnote: no known conversion for argument 1 from 'quantity<reference<isq::height(), si::metre()>(),int>'\n to 'quantity<reference<horizontal_length(), si::metre()>(),double>'\n 19 | Box(quantity<horizontal_length[m]> l, quantity<isq::width[m]> w, quantity<isq::height[m]> h):\n | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^\nThis release provided lots of changes to the mp_units/math.h header file.
First, we got several outstanding contributions:
fma, isfinite, isinf, and isnan math functions were added by @NAThompson,ppm, atan2, fmod, and remainder were added by @nebkat.Thanks!
Additionally, we changed the namespace for trigonometric functions using SI units. Now they are inside of the mp_units::si subnamespace and not in mp_units::isq like it was the case before ( breaking change ).
Also, the header itself was split into smaller pieces that improve C++20 modules definitions.
"},{"location":"blog/2024/06/14/mp-units-220-released/#ratio-made-an-implementation-detail-of-the-library","title":"ratio made an implementation detail of the library","text":"We decided not to expose ratio and associated interfaces in the public part of the library ( breaking change ). Standardization of it could be problematic as we have std::ratio already.
Alternatively, as in the public interface it was always only used with mag, we introduced a new helper called mag_ratio to provide the magnitude of the unit defined in terms of a rational conversion factor. Here is a comparison of the code with previous and current definitions:
inline constexpr struct yard final : named_unit<\"yd\", mag_ratio<9'144, 10'000> * si::metre> {} yard;\ninline constexpr struct foot final : named_unit<\"ft\", mag_ratio<1, 3> * yard> {} foot;\ninline constexpr struct yard : named_unit<\"yd\", mag<ratio{9'144, 10'000}> * si::metre> {} yard;\ninline constexpr struct foot : named_unit<\"ft\", mag<ratio{1, 3}> * yard> {} foot;\nSeveral groups in the ISO C++ Committee reviewed the P1935: A C++ Approach to Physical Units proposal in Belfast 2019 and Prague 2020. All those groups expressed interest in the potential standardization of such a library and encouraged further work. The authors also got valuable initial feedback that highly influenced the design of the V2 version of the mp-units library.
In the following years, we scoped on getting more feedback from the production and design. This resulted in version 2 of the mp-units library that resolved many issues the users and Committee members raised. The features and interfaces of this version are close to being the best we can get with the current version of the C++ language standard.
We submitted three new proposals related to the standardization of the quantities and units library for the last ISO C++ Committee meeting:
std::quantity as a numeric type.Those were reviewed and briefly discussed in several groups: Numerics (SG6), Safety & Security (SG23), and Library Evolution Working Group (LEWG). Most of the feedback was positive, and the Committee is interested in spending more time on such proposals.
The following poll was taken by the LEWG:
LEWG POLL: Given that our time is limited, more time should be promised for a quantities and units library
Strongly in Favor In favor Neutral Against Strongly Against 10 13 4 0 0Attendance: 22 + 6
Number of Authors: 4
Authors\u2019 position: 4x SF
Outcome: Strong consensus in favor
Additionally, some concerns were raised about the large scope of the proposal. We were encouraged to return with more details and design rationale in a unified paper. This is what we are working on now for the next Committee meeting that will happen in mid-March 2024 in Tokyo.
"},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/","title":"Report from the St. Louis 2024 ISO C++ Committee meeting","text":"We made significant progress in the standardization of this library during the ISO C++ Committee meeting in St. Louis.
"},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/#p30942r3-stdbasic_fixed_string","title":"P30942R3:std::basic_fixed_string","text":"First, the fixed_string was unanimously forwarded from the SG18 LEWG Incubator to the Library Evolution Working Group (LEWG). The group suggested a few minor changes to the paper, which resulted in the R3 version of the proposal.
The paper is in excellent shape, and the entire wording is ready as well. Hopefully it will progress quickly through the remaining groups in the Committee.
"},{"location":"blog/2024/07/02/report-from-the-st-louis-2024-iso-c-committee-meeting/#p3045r1-quantities-and-units-library","title":"P3045R1: Quantities and units library","text":"In the SG6 (Numerics), we had a really efficient discussion about the recently raised usability issues with temperatures and the Minimal Viable Product (MVP) scope.
The following polls were taken:
POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, and quantity kinds. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
Strongly in Favor In favor Neutral Against Strongly Against 7 4 7 0 0POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, quantity kinds, and quantities of the same kind. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
Strongly in Favor In favor Neutral Against Strongly Against 5 2 5 2 0POLL: If WG21 adds anything to the standard to provide units or quantities, then such a solution must at least include the necessary abstractions for units, dimensions, quantity kinds, and affine spaces. (It does not have to provide system definitions, e.g. ISQ/SI definitions.)
Strongly in Favor In favor Neutral Against Strongly Against 5 0 8 1 0As we can see, there are no controversies about the first poll that states that the MVP should include at least:
The next polls add either:
quantity_point).SG6 considered those less important, but no one was strongly against including those in the MVP. We were asked to return with better motivation and usage examples for those features.
If you are depending on quantities of the same kind or quantity points in your project and you would like to see them in the std library, please let us know about your use cases.
Besides SG6, we spent six hours in the SG18 LEWG Incubator discussing the details of the library design. The proposal was very well received, and we got a few valuable comments and suggestions that we will apply to the next version of the paper.
"},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/","title":"Report from the Tokyo 2024 ISO C++ Committee meeting","text":"The Tokyo 2024 meeting was a very important step in the standardization of this library. Several WG21 groups reviewed proposals, and the feedback was really good.
"},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/#p3045r0-quantities-and-units-library","title":"P3045R0: Quantities and units library","text":"The Study Group 6 (Numerics) discussed the proposal for several hours. The initial feedback was positive. There were some concerns related to the description and design of the affine space abstractions in the library. Besides that, the people in the room liked what they saw.
We run a few polls in SG6 as well:
POLL: The syntax number * unit is the right solution for constructing quantities. Not allowing reordering the operands is correct.
POLL: Not defining any UDLs is the right solution.
No objection to unanimous consent.
The paper was also briefly discussed in SG18 LEWG Incubator, and the initial feedback was also positive. No polls were taken.
SG16 Unicode does not meet during ISO C++ Committee F2F meetings. Still, the text output chapter paper was also reviewed by it during an online meeting before Tokyo. We got good feedback and are expected to return with the updated version. No polls were taken.
"},{"location":"blog/2024/04/15/report-from-the-tokyo-2024-iso-c-committee-meeting/#p30942r1-stdbasic_fixed_string","title":"P30942R1:std::basic_fixed_string","text":"In the SG18 LEWG Incubator, before we started to talk about P3045R0, we spent a few hours discussing the design of the std::basic_fixed_string, which is proposed for C++26. The group gave excellent feedback, and if the R2 version addresses it properly, the paper is expected to progress to LEWG (Library Evolution Working Group) in St. Louis.
Plenty of polls were taken:
POLL: We should promise more committee time to pursuing std::basic_fixed_string, knowing that our time is scarce and this will leave less time for other work.
POLL: Should the constructor from a string literal be consteval?
POLL: Do we want to add .view()?
POLL: Do we want the .size member to be an integral_constant<size_t, N> (and .empty to be bool_constant<N==0>)?
POLL: Should the index operator[] return a reference to const?
POLL: Should the constructor from a string literal have a precondition that txt[N] == 0?
Info
mp-units library tries to provide the best user experience possible with the C++ language. To achieve that, it extensively uses the latest C++ language features.
Even though the library benefits from the latest C++ versions (if available), C++20 is enough to compile and use all of the library's functionality. Newer features can be hidden behind some preprocessor macros providing a backward-compatible way to use them.
The table below provides the minimum compiler version required to compile the code using a specific C++ feature:
C++ Feature C++ version gcc clang apple-clang MSVC Minimum support 20 12 16 15 Nonestd::format 20 13 17 None None C++ modules 20 None 17 None None Static constexpr variables in constexpr functions 23 13 17 None None Explicit this parameter 23 14 18 None None Important
Enabling/disabling features listed above may influence the API of the library and the ABI of the customers' projects.
"},{"location":"getting_started/cpp_compiler_support/#stdformat","title":"std::format","text":"std::format yet (even when the compiler supports it).__cpp_lib_format feature test macro.Note
More requirements for C++ modules support can be found in the CMake's documentation.
"},{"location":"getting_started/cpp_compiler_support/#static-constexpr-variables-in-constexpr-functions","title":"Staticconstexpr variables in constexpr functions","text":"std::string_view from the unit_symbol() and dimension_symbol() functionsstd::string_view type has a reference semantics so it has to point to a storage with a longer lifetime.mp_units::basic_fixed_string<CharT, N> instead.__cpp_constexpr >= 202211L feature test macro.this parameter","text":"quantity_spec definitions.__cpp_explicit_this_parameter feature test macro.metre instead of meter?","text":"This is how the BIPM defines it in the SI Brochure (British English spelling by default).
"},{"location":"getting_started/faq/#why-dont-we-use-udls-to-create-quantities","title":"Why don't we use UDLs to create quantities?","text":"Many reasons make UDLs a poor choice for a physical units library:
Typical implementations of UDLs tend to always use the widest representation type available. In the case of std::chrono::duration, the following is true:
using namespace std::chrono_literals;\nauto d1 = 42s;\nauto d2 = 42.s;\nstatic_assert(std::is_same_v<decltype(d1)::rep, std::int64_t>);\nstatic_assert(std::is_same_v<decltype(d2)::rep, long double>);\nWhen such UDL is intermixed in arithmetics with any quantity type of a shorter representation type, it will always expand it to the longest one. In other words, such long type spreads until all types use it everywhere.
While increasing the coverage for the library, we learned that many unit symbols conflict with built-in types or numeric extensions. A few of those are: F (farad), J (joule), W (watt), K (kelvin), d (day), l or L (litre), erg, ergps. Usage of the _ prefix would make it work for mp-units, but in case the library is standardized, those naming collisions would be a big issue. This is why we came up with the _q_ prefix that would become q_ after standardization (e.g., 42q_s), which is not that nice anymore.
UDLs with the same identifiers defined in different namespace can't be disambiguated in the C++ language. If both SI and CGS systems define _q_s UDL for a second unit, then it would not be possible to specify which one to use in case both namespaces are \"imported\" with using directives.
Another bad property of UDLs is that they do not compose. A coherent unit of angular momentum would have a UDL specified as _q_kg_m2_per_s. Now imagine that we want to make every possible user happy. How many variations of that unit would we predefine for differently scaled versions of all unit ingredients?
UDLs are also really expensive to define and specify. Typically, for each unit, we need two definitions. One for integral and another one for floating-point representation. Before the V2 framework, the coherent unit of angular momentum was defined as:
constexpr auto operator\"\" _q_kg_m2_per_s(unsigned long long l)\n{\n gsl_Expects(std::in_range<std::int64_t>(l));\n return angular_momentum<kilogram_metre_sq_per_second, std::int64_t>(static_cast<std::int64_t>(l));\n}\n\nconstexpr auto operator\"\" _q_kg_m2_per_s(long double l)\n{\n return angular_momentum<kilogram_metre_sq_per_second, long double>(l);\n}\nA quantity class template in the mp-units library has no publicly available constructor taking a raw value. Such support is provided by the std::chrono::duration and was pointed out to us as a red flag safety issue by a few parties already.
Consider the following structure and a code using it:
struct X {\n std::vector<std::chrono::milliseconds> vec;\n // ...\n};\nX x;\nx.vec.emplace_back(42);\nEverything works fine for years until, at some point, someone changes the structure to:
struct X {\n std::vector<std::chrono::microseconds> vec;\n // ...\n};\nThe code continues to compile just fine, but all the calculations are off now. This is why we decided to not follow this path.
In the mp-units library, both a number and a unit have to always be explicitly provided in order to form a quantity.
Note
The same applies to the construction of quantity_point using an explicit point origin. To prevent similar safety issues during maintenance, the initialization always requires providing both a quantity and a PointOrigin that we use as a reference point.
In the initial design of this library, the resulting type of division of two quantities was their common representation type:
static_assert(std::is_same_v<decltype(10 * km / (5 * km)), int>);\nFirst of all, this was consistent with std::chrono::duration behavior. Additional reasoning behind it was not providing a false impression of a strong quantity type for something that looks and feels like a regular number. Also, all of the mathematic and trigonometric functions were working fine out of the box with such representation types, so we did not have to rewrite sin(), cos(), exp(), and others.
However, the feedback we got from the production usage was that such an approach is really bad for generic programming. It is hard to handle the result of the two quantities' division (or multiplication) as it might be either a quantity or a fundamental type. If we want to raise such a result to some power, we must use units::pow or std::pow depending on the resulting type. Those are only a few issues related to such an approach.
Moreover, suppose we divide quantities of the same dimension but with units of significantly different magnitudes. In that case, we may end up with a really small or a huge floating-point value, which may result in losing lots of precision. Returning a dimensionless quantity from such cases allows us to benefit from all the properties of scaled units and is consistent with the rest of the library.
Note
More information on the current design can be found in the Dimensionless Quantities chapter.
"},{"location":"getting_started/faq/#why-do-the-identifiers-for-concepts-in-the-library-use-camelcase","title":"Why do the identifiers for concepts in the library useCamelCase?","text":"Initially, C++20 was meant to use CamelCase for all the concept identifiers. All the concepts from the std::ranges library were merged with such names into the standard document draft. Frustratingly, CamelCase concepts got dropped from the C++ standard at the last moment before releasing C++20. Now, we are facing the predictable consequences of running out of names.
As long as some concepts in the library could be easily named with a standard_case there are some that are hard to distinguish from the corresponding type names, such as Quantity, QuantityPoint, QuantitySpec, or Reference. This is why we decided to use CamelCase consistently for all the concept identifiers to make it clear when we are talking about a type or concept identifier.
However, we are aware that this might be a temporary solution. In case the library gets standardized, we can expect the ISO C++ Committee to bikeshed/rename all of the concept identifiers to a standard_case, even if it will result in a harder to understand code.
Note
In case you have a good idea of how to rename existing concepts to the standard_case, please let us know in the associated GitHub Issue.
Both C++ and ISO 80000 are standardized by the ISO. ISO 80000 and the SI standards specify Unicode symbols as the official unit names for some quantities (e.g. \u03a9 symbol for the resistance quantity). As the mp-units library will be proposed for standardization as a part of the C++ Standard Library we have to obey the rules and be consistent with ISO specifications.
Note
We do understand engineering reality and the constraints of some environments. This is why the library has the option of ASCII-only Quantity Symbols.
"},{"location":"getting_started/faq/#why-dont-we-have-cmake-options-to-disable-the-building-of-tests-and-examples","title":"Why don't we have CMake options to disable the building of tests and examples?","text":"Over time, many people provided PRs proposing adding options to build tests and examples conditionally. Here are a few examples:
We admit this is a common practice in the industry, but we also believe this is a bad pattern.
First, the only need for such options comes when a user wants to use add_subdirectory() in CMake to handle dependencies. Such an approach does not scale and should be discouraged. There is little use for such a practice in times when we have dedicated package managers like Conan.
The second thing is that our observation is that many people are fixed on disabling \"unneeded\" subdirectories from compilation, but they do not see or address the biggest issue, which is polluting user's build environment with our development-specific settings. Propagating our restrictive compilation flags to user's project is not the best idea as it might cause a lot of harm if this project stops to compile because of that.
Last but not least, not having those options is on purpose. Top level CMakeLists.txt file should only be used by mp-units developers and contributors as an entry point for the project's development. We want to ensure that everyone will build ALL the code correctly before pushing a commit. Having such options would allow unintended issues to leak to PRs and CI.
This is why our projects have two entry points:
add_subdirectory() to handle the dependencies.Note
For more details on this please refer to the CMake + Conan: 3 Years Later - Mateusz Pusz lecture that Mateusz Pusz provided at the C++Now 2021 conference.
"},{"location":"getting_started/installation_and_usage/","title":"Installation And Usage","text":"This chapter provides all the necessary information to obtain and build the code using mp-units. It also describes how to build or distribute the library and generate its documentation.
"},{"location":"getting_started/installation_and_usage/#project-structure","title":"Project structure","text":""},{"location":"getting_started/installation_and_usage/#repository-directory-tree-and-dependencies","title":"Repository directory tree and dependencies","text":"The GitHub repository contains three independent CMake-based projects:
./src
in case this library becomes part of the C++ standard, it will have no external dependencies but until then, it depends on the following:
std::format is not supported yet on a specific compiler)..
additionally to the dependencies of ./src project, it uses:
./test_package
Important: Library users should not use the top-level CMake file
Top level CMakeLists.txt file should only be used by mp-units developers and contributors as an entry point for the project's development. We want to ensure that everyone will build ALL the code correctly before pushing a commit. Having such options would allow unintended issues to leak to PRs and CI.
This is why our projects have two entry points:
add_subdirectory() to handle the dependencies.To learn more about the rationale, please check our FAQ.
"},{"location":"getting_started/installation_and_usage/#modules","title":"Modules","text":"The mp-units library provides the following C++ modules:
flowchart TD\n mp_units --- mp_units.systems --- mp_units.coremp_units.core mp-units::core Core library framework and systems-independent utilities mp_units.systems mp-units::systems All the systems of quantities and units mp_units mp-units::mp-units Core + Systems Note
C++ modules are provided within the package only when:
cxx_modules Conan option is set to True,MP_UNITS_BUILD_CXX_MODULES CMake option is set to ON.All of the project's header files can be found in the mp-units/... subdirectory.
mp-units/framework.h contains the entire library's framework definitions,mp-units/concepts.h exposes only the library's concepts for generic code needs,mp-units/format.h provides text formatting support,mp-units/ostream.h enables streaming of the library's objects to the text output,mp-units/math.h provides overloads of common math functions for quantities,mp-units/random.h provides C++ pseudo-random number generators for quantities,mp-units/compat_macros.h provides macros for wide compatibility.More detailed header files can be found in subfolders which typically should not be included by the end users:
mp-units/framework/... provides all the public interfaces of the framework,mp-units/bits/... provides private implementation details only (no public definitions),mp-units/ext/... contains external dependencies that at some point in the future should be replaced with C++ standard library facilities.The systems definitions can be found in the mp-units/systems/... subdirectory:
mp-units/systems/isq.h provides International System of Quantities (ISQ) definitions,mp-units/systems/isq.h might be expensive to compile in every translation unit. There are some smaller, domain targeted files available for explicit inclusion in the mp-units/systems/isq/... subdirectory.
mp-units/systems/si.h provides International System of Units (SI) definitions and associated math functions,mp-units/systems/angular.h provides strong angular units and associated math functions,mp-units/systems/international.h provides international yard and pound units,mp-units/systems/imperial.h includes international.h and extends it with imperial units,mp-units/systems/usc.h includes international.h and extends it with United States customary system of units,mp-units/systems/cgs.h provides centimetre-gram-second system of units,mp-units/systems/iau.h provides astronomical system of units,mp-units/systems/hep.h provides units used in high-energy physics,mp-units/systems/typographic.h provides units used in typography or typesetting,mp-units/systems/natural.h provides an example implementation of natural units.mp-units/systems/si.h might be expensive to compile in every translation unit. There are some smaller files available for explicit inclusion in the mp-units/systems/si/... subdirectory.
mp-units/systems/si/unit_symbols.h is the most expensive to include.
This library assumes that most of the dependencies will be provided by the Conan Package Manager. If you want to obtain required dependencies by other means, some modifications to the library's CMake files might be needed. The rest of the dependencies responsible for documentation generation are provided by python3-pip.
In case you are not familiar with Conan, to install it (or upgrade) just do:
pip install -U conan\nAfter that, you might need to add a custom profile file for your development environment in ~/.conan2/profiles directory. An example profile can look as follows:
~/.conan2/profiles/gcc12[settings]\narch=x86_64\nbuild_type=Release\ncompiler=gcc\ncompiler.cppstd=20\ncompiler.libcxx=libstdc++11\ncompiler.version=12\nos=Linux\n\n[conf]\ntools.build:compiler_executables={\"c\": \"gcc-12\", \"cpp\": \"g++-12\"}\nSetting the language version
Please note that the mp-units library requires at least C++20 to be set in a Conan profile or forced via the Conan command line. If we do the former, we will not need to provide -s compiler.cppstd=20 every time we run a Conan command line (as provided in the command line instructions below).
Using Ninja as a CMake generator for Conan
It is highly recommended to set Ninja as a CMake generator for Conan. To do so, we should create a ~/.conan2/global.conf file that will set tools.cmake.cmaketoolchain:generator to one of the Ninja generators. For example:
tools.cmake.cmaketoolchain:generator=\"Ninja Multi-Config\"\nSeparate build folders for different configurations
~/.conan2/global.conf file may also set tools.cmake.cmake_layout:build_folder_vars which makes working with several compilers or build configurations easier. For example, the below line will force Conan to generate separate CMake presets and folders for each compiler and C++ standard version:
tools.cmake.cmake_layout:build_folder_vars=[\"settings.compiler\", \"settings.compiler.version\", \"settings.compiler.cppstd\"]\nIn such a case, we will need to use a configuration-specific preset name in the Conan instructions provided below rather than just conan-default and conan-release (e.g. conan-gcc-13-23 and conan-gcc-13-23-release)
Note
Most of the below options are related to the C++ language features available in the compilers. Please refer to the C++ compiler support chapter to learn more about which C++ features are required and which compiler support them.
"},{"location":"getting_started/installation_and_usage/#conan-options","title":"Conan options","text":"cxx_modules 2.2.0 \u00b7 True/False (Default: automatically determined from settings)
Configures CMake to add C++ modules to the list of default targets.
import_std 2.3.0 \u00b7 True/False (Default: automatically determined from settings)
Enables import std; usage.
std_format 2.2.0 \u00b7 True/False (Default: automatically determined from settings)
Enables the usage of std::format and associated facilities for text formatting. If it is not supported, then the {fmt} library is used instead.
string_view_ret 2.2.0 \u00b7 True/False (Default: automatically determined from settings)
Enables returning std::string_view from the unit_symbol() and dimension_symbol() functions. If this feature is not available, those functions will return mp_units::basic_fixed_string<CharT, N> instead.
no_crtp 2.2.0 \u00b7 True/False (Default: automatically determined from settings)
Removes the need for the usage of the CRTP idiom in the quantity_spec definitions.
contracts 2.2.0 \u00b7 none/gsl-lite/ms-gsl (Default: gsl-lite)
Enables checking of preconditions and additional asserts in the code.
freestanding 2.2.0 \u00b7 True/False (Default: False)
Configures the library in the freestanding mode. When enabled, the library's source code should build with the compiler's -ffreestanding compilation option without any issues.
user.mp-units.build:all 2.2.0 \u00b7 True/False (Default: False)
Enables compilation of all the source code, including tests and examples. To support this, it requires some additional Conan build dependencies described in Repository directory tree and dependencies. It also runs unit tests during Conan build (unless tools.build:skip_test configuration property is set to True).
user.mp-units.build:skip_la 2.2.0 \u00b7 True/False (Default: True)
If user.mp-units.build:all is enabled, among others, Conan installs the external wg21-linear_algebra dependency and enables the compilation of linear algebra-based tests and usage examples. Such behavior can be disabled with this option.
user.mp-units.analyze:clang-tidy 2.2.0 \u00b7 True/False (Default: False)
Enables clang-tidy analysis.
"},{"location":"getting_started/installation_and_usage/#cmake-options","title":"CMake options","text":"MP_UNITS_BUILD_AS_SYSTEM_HEADERS 2.2.0 \u00b7 ON/OFF (Default: OFF)
Exports library as system headers.
MP_UNITS_BUILD_CXX_MODULES 2.2.0 \u00b7 ON/OFF (Default: OFF)
Adds C++ modules to the list of default targets.
MP_UNITS_BUILD_IMPORT_STD 2.3.0 \u00b7 ON/OFF (Default: OFF)
Enables import std; usage.
MP_UNITS_API_STD_FORMAT 2.2.0 \u00b7 ON/OFF (Default: automatically determined)
Enables the usage of std::format and associated facilities for text formatting. If it is not supported, then the {fmt} library is used instead.
MP_UNITS_API_STRING_VIEW_RET 2.2.0 \u00b7 ON/OFF (Default: automatically determined)
Enables returning std::string_view from the unit_symbol() and dimension_symbol() functions. If this feature is not available, those functions will return mp_units::basic_fixed_string<CharT, N> instead.
MP_UNITS_API_NO_CRTP 2.2.0 \u00b7 ON/OFF (Default: automatically determined)
Removes the need for the usage of the CRTP idiom in the quantity_spec definitions.
MP_UNITS_API_CONTRACTS 2.2.0 \u00b7 NONE/GSL-LITE/MS-GSL (Default: GSL-LITE)
Enables checking of preconditions and additional asserts in the code.
MP_UNITS_API_FREESTANDING 2.2.0 \u00b7 ON/OFF (Default: OFF)
Configures the library in the freestanding mode. When enabled, the library's source code should build with the compiler's -ffreestanding compilation option without any issues.
MP_UNITS_DEV_BUILD_LA 2.2.0 \u00b7 ON/OFF (Default: ON)
Enables building code depending on the linear algebra library.
MP_UNITS_DEV_IWYU 2.2.0 \u00b7 ON/OFF (Default: OFF)
Enables include-what-you-use analysis.
MP_UNITS_DEV_CLANG_TIDY 2.2.0 \u00b7 ON/OFF (Default: OFF)
Enables clang-tidy analysis.
"},{"location":"getting_started/installation_and_usage/#cmake-with-presets-support","title":"CMake with presets support","text":"It is recommended to use at least CMake 3.23 to build this project as this version introduced support for CMake Presets schema version 4, used now by Conan to generate presets files. All build instructions below assume that you have such support. If not, your CMake invocations have to be replaced with something like:
mkdir build && cd build\ncmake .. -G \"Ninja Multi-Config\" -DCMAKE_TOOLCHAIN_FILE=<path_to_generators_dir>/conan_toolchain.cmake\ncmake --build . --config Release\nTip
In case you can't use CMake 3.23 but you have access to CMake 3.20 or later, you can append -c tools.cmake.cmaketoolchain.presets:max_schema_version=2 to the conan install command which will force Conan to use an older version of the CMake Presets schema.
There are many different ways of installing/reusing mp-units in your project. Below we mention only a few of many options possible.
Important: Prefer using Conan if possible
The easiest and most recommended way to obtain mp-units is with the Conan package manager. See Conan + CMake (release) for a detailed instruction.
"},{"location":"getting_started/installation_and_usage/#copy","title":"Copy","text":"As mp-units is a C++ header-only library you can simply copy all needed src/*/include subdirectories to your source tree.
Note
In such a case, you are on your own to ensure all the dependencies are installed and their header files can be located during the build. Please also note that some compiler-specific flags are needed to make the code compile without issues.
"},{"location":"getting_started/installation_and_usage/#copy-cmake","title":"Copy + CMake","text":"If you copy the whole mp-units repository to your project's file tree, you can reuse CMake targets defined by the library. To do so, you should use CMakeLists.txt file from the ./src directory:
add_subdirectory(<path_to_units_folder>/src)\n# ...\ntarget_link_libraries(<your_target> <PUBLIC|PRIVATE|INTERFACE> mp-units::mp-units)\nNote
You are still on your own to make sure all the dependencies are installed and their header and CMake configuration files can be located during the build.
"},{"location":"getting_started/installation_and_usage/#conan-cmake-release","title":"Conan + CMake (release)","text":"Tip
If you are new to the Conan package manager, it is highly recommended to read Obtaining Dependencies and refer to Consuming packages chapter of the official Conan documentation for more information.
mp-units releases are hosted on Conan-Center. The following steps may be performed to obtain an official library release:
Create Conan configuration file (either conanfile.txt or conanfile.py) in your project's top-level directory and add mp-units as a dependency of your project. For example, the simplest file may look as follows:
conanfile.txt[requires]\nmp-units/2.2.0\n\n[options]\nmp-units:cxx_modules=True\n\n[layout]\ncmake_layout\n\n[generators]\nCMakeToolchain\nCMakeDeps\nImport mp-units and its dependencies definitions to your project's build procedure with find_package:
find_package(mp-units REQUIRED)\nLink your CMake targets with mp-units:
target_link_libraries(<your_target> <PUBLIC|PRIVATE|INTERFACE> mp-units::mp-units)\nDownload, build, and install Conan dependencies before running the CMake configuration step:
conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing\ncmake --preset conan-default\ncmake --build --preset conan-release\nThis chapter describes the procedure to Live At Head, which means using the latest stable version of mp-units all the time.
Note
Please note that even though the Conan packages that you will be using are generated ONLY for builds that are considered stable (passed our CI tests), some minor regressions may happen (our CI and C++20 build environment is not perfect yet). Also, please expect that the library interface might, and probably will, change occasionally. Even though we do our best, such changes might not be reflected in the project's documentation right away.
The procedure is similar to the one described in Conan + CMake (release) with the following differences:
Before starting the previous procedure, add mp-units remote to your Conan configuration:
conan remote add conan-mpusz https://mpusz.jfrog.io/artifactory/api/conan/conan-oss\nIn your Conan configuration file, provide the package identifier of the mpusz/testing stream:
[requires]\nmp-units/2.3.0@mpusz/testing\n\n[options]\nmp-units:cxx_modules=True\n\n[layout]\ncmake_layout\n\n[generators]\nCMakeToolchain\nCMakeDeps\nTip
The identifiers of the latest packages can always be found in the project's README file or on the project's Artifactory.
Force Conan to check for updated recipes with -u:
conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing -u\nIn case you don't want to use Conan in your project and just want to install the mp-units library on your file system and use find_package(mp-units) from another repository to find it; it is enough to perform the following steps:
conan install . -pr <your_conan_profile> -s compiler.cppstd=20 -b=missing\nmv CMakeUserPresets.json src\ncd src\ncmake --preset conan-default -DCMAKE_INSTALL_PREFIX=<your_installation_path>\ncmake --build --preset conan-release --target install\nIn case you would like to build all the mp-units source code (with unit tests and examples), you should:
user.mp-units.build:all = True.git clone https://github.com/mpusz/mp-units.git && cd units\nconan build . -pr <your_conan_profile> -s compiler.cppstd=23 -o '&:cxx_modules=True' -c user.mp-units.build:all=True -b missing\nThe above will download and install all of the dependencies needed for the development of the library, build all of the source code, and run unit tests.
If you prefer to build the project via CMake rather than Conan, then you should replace the conan build with conan install command and then follow with a regular CMake build:
cmake --preset conan-default\ncmake --build --preset conan-release\ncmake --build --preset conan-release --target all_verify_interface_header_sets\ncmake --build --preset conan-release --target test\nStarting from mp-units 2.0 we are using Material for MkDocs to build our documentation. The easiest way to install all the required dependencies is with pip:
pip install -U mkdocs-material mkdocs-rss-plugin\nAdditionally, a Cairo Graphics library is required by Material for MkDocs. Please follow the official MkDocs documentation to install it.
After that, you can either:
easily start a live server to preview the documentation as you write
mkdocs serve\nbuild the documentation
mkdocs build\nTo test CMake installation and Conan packaging or create a Conan package run:
conan create . --user <username> --channel <channel> -pr <your_conan_profile> -s compiler.cppstd=20 -o '&:cxx_modules=True' -c user.mp-units.build:all=True -b missing\nThe above will create a Conan package and run tests provided in ./test_package directory.
"},{"location":"getting_started/installation_and_usage/#uploading-mp-units-package-to-the-conan-server","title":"Uploading mp-units package to the Conan server","text":"conan upload -r <remote-name> --all mp-units/2.2.0@<user>/<channel>\nmp-units is a Modern C++ library that provides compile-time dimensional analysis and unit/quantity manipulation. The initial versions of the library were inspired by the std::chrono::duration but with each release, the interfaces diverged from the original to provide a better user experience.
Info
A brief introduction to the library's interfaces and the rationale for changes in version 2.0 of mp-units were provided in detail by Mateusz Pusz in the \"The Power of C++ Templates With mp-units: Lessons Learned & a New Library Design\" talk at the C++ on Sea 2023 conference.
"},{"location":"getting_started/introduction/#open-source","title":"Open Source","text":"mp-units is Free and Open Source, with a permissive MIT license. Check out the source code and issue tracking (for questions and support, reporting bugs, suggesting feature requests and improvements) at https://github.com/mpusz/mp-units.
"},{"location":"getting_started/introduction/#with-the-users-experience-in-mind","title":"With the User's Experience in Mind","text":"Most of the critical design decisions in the library are dictated by the requirement of providing the best user experience possible. Other C++ physical units libraries are \"famous\" for their enormous and hard-to-understand error messages (one line of the error log often does not fit on one slide). The ultimate goal of mp-units is to improve this and make compile-time errors and debugging as easy and user-friendly as possible.
To achieve this goal, several techniques are applied:
Important: It is all about errors
In many generic C++ libraries, compile-time errors do not happen often. It is hard to break std::string or std::vector in a way that won't compile with a huge error log. Physical quantities and units libraries are different. Generation of compile-time errors is the main reason to use such a library.
quantity and quantity_point)- Compile-time checked conversions of quantities and units- Unique support for many quantities of the same kind- Type-safe equations on scalar, vector, and tensor quantities and their units- Value-preserving conversions Performance - All the compile-time logic implemented as immediate (consteval) functions- As fast or even faster than working with fundamental types- No space size overhead needed to implement high-level abstractions Great User Experience - Optimized for readable compilation errors and great debugging experience- Efficient and composable way to specify a unit of choice- Value-based dimension, unit, and quantity equations Feature Rich - Systems of Quantities- Systems of Units- Scalar, vector, and tensor quantities- The affine space- Different models of the universe (e.g. natural units systems)- Strong dimensionless quantities- Strong angular system- Supports any unit's magnitude (huge, small, floating-point)- Faster-than-lightspeed constants- Highly adjustable text-output formatting Easy to Extend - Each entity can be defined with a single line of code- User can easily extend the systems with custom dimensions, quantities, and units Low Standardization Cost - Small number of predefined entities thanks to their composability- No external dependencies (assuming full C++20 support)- No macros in the user interface (besides portability and standard-compliance issues)- Possibility to be standardized as a freestanding part of the C++ Standard Library"},{"location":"getting_started/look_and_feel/","title":"Look and Feel","text":"Here is a small example of operations possible on scalar quantities:
C++ modulesHeader filesimport mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\n// simple numeric operations\nstatic_assert(10 * km / 2 == 5 * km);\n\n// conversions to common units\nstatic_assert(1 * h == 3600 * s);\nstatic_assert(1 * km + 1 * m == 1001 * m);\n\n// derived quantities\nstatic_assert(1 * km / (1 * s) == 1000 * m / s);\nstatic_assert(2 * km / h * (2 * h) == 4 * km);\nstatic_assert(2 * km / (2 * km / h) == 1 * h);\n\nstatic_assert(2 * m * (3 * m) == 6 * m2);\n\nstatic_assert(10 * km / (5 * km) == 2);\n\nstatic_assert(1000 / (1 * s) == 1 * kHz);\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\n// simple numeric operations\nstatic_assert(10 * km / 2 == 5 * km);\n\n// conversions to common units\nstatic_assert(1 * h == 3600 * s);\nstatic_assert(1 * km + 1 * m == 1001 * m);\n\n// derived quantities\nstatic_assert(1 * km / (1 * s) == 1000 * m / s);\nstatic_assert(2 * km / h * (2 * h) == 4 * km);\nstatic_assert(2 * km / (2 * km / h) == 1 * h);\n\nstatic_assert(2 * m * (3 * m) == 6 * m2);\n\nstatic_assert(10 * km / (5 * km) == 2);\n\nstatic_assert(1000 / (1 * s) == 1 * kHz);\nTry it on Compiler Explorer
This library requires some C++20 features (concepts and constraints, classes as NTTP, ...). Thanks to them, a user gets a powerful but still easy-to-use interface where all unit conversions and dimensional analysis can be performed without sacrificing accuracy. Please see the below example for a quick preview of basic library features:
C++ modulesHeader files#include <format>\n#include <iomanip>\n#include <iostream>\n#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,\n QuantityOf<isq::time> auto t)\n{\n return d / t;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n using namespace mp_units::international::unit_symbols;\n\n constexpr quantity v1 = 110 * km / h;\n constexpr quantity v2 = 70 * mph;\n constexpr quantity v3 = avg_speed(220. * isq::distance[km], 2 * h);\n constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * h);\n constexpr quantity v5 = v3.in(m / s);\n constexpr quantity v6 = value_cast<m / s>(v4);\n constexpr quantity v7 = value_cast<int>(v6);\n\n std::cout << v1 << '\\n'; // 110 km/h\n std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n'; // ***70 mi/h\n std::cout << std::format(\"{:*^10}\\n\", v3); // *110 km/h*\n std::println(\"{:%N in %U of %D}\", v4); // 70 in mi/h of LT\u207b\u00b9\n std::println(\"{::N[.2f]}\", v5); // 30.56 m/s\n std::println(\"{::N[.2f]U[dn]}\", v6); // 31.29 m\u22c5s\u207b\u00b9\n std::println(\"{:%N}\", v7); // 31\n}\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <format>\n#include <iomanip>\n#include <iostream>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d,\n QuantityOf<isq::time> auto t)\n{\n return d / t;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n using namespace mp_units::international::unit_symbols;\n\n constexpr quantity v1 = 110 * km / h;\n constexpr quantity v2 = 70 * mph;\n constexpr quantity v3 = avg_speed(220. * isq::distance[km], 2 * h);\n constexpr quantity v4 = avg_speed(isq::distance(140. * mi), 2 * h);\n constexpr quantity v5 = v3.in(m / s);\n constexpr quantity v6 = value_cast<m / s>(v4);\n constexpr quantity v7 = value_cast<int>(v6);\n\n std::cout << v1 << '\\n'; // 110 km/h\n std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n'; // ***70 mi/h\n std::cout << std::format(\"{:*^10}\\n\", v3); // *110 km/h*\n std::println(\"{:%N in %U of %D}\", v4); // 70 in mi/h of LT\u207b\u00b9\n std::println(\"{::N[.2f]}\", v5); // 30.56 m/s\n std::println(\"{::N[.2f]U[dn]}\", v6); // 31.29 m\u22c5s\u207b\u00b9\n std::println(\"{:%N}\", v7); // 31\n}\nTry it on Compiler Explorer
Note
More code examples can be found in the Examples chapter.
"},{"location":"getting_started/quick_start/","title":"Quick Start","text":"This chapter provides a quick introduction to get you started with mp-units. Much more details can be found in our User's Guide.
"},{"location":"getting_started/quick_start/#quantities","title":"Quantities","text":"A quantity is a concrete amount of a unit representing a quantity type of a specified dimension with a specific representation. It is represented in the library with a quantity class template.
The SI Brochure says:
SI Brochure
The value of the quantity is the product of the number and the unit. The space between the number and the unit is regarded as a multiplication sign (just as a space between units implies multiplication).
Following the above, the value of a quantity in the mp-units library is created by multiplying a number with a predefined unit:
C++ modulesHeader filesimport mp_units;\n\nusing namespace mp_units;\n\nquantity q = 42 * si::metre / si::second;\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q = 42 * si::metre / si::second;\nInfo
In case someone doesn't like the multiply syntax or there is an ambiguity between operator* provided by this and other libraries, there are two other ways to create a quantity:
delta construction helper:
import mp_units;\n\nusing namespace mp_units;\n\nquantity q = delta<si::metre / si::second>(42);\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q = delta<si::metre / si::second>(42);\nA two-parameter constructor:
C++ modulesHeader filesimport mp_units;\n\nusing namespace mp_units;\n\nquantity q{42, si::metre / si::second};\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\n\nquantity q{42, si::metre / si::second};\nThe above creates an instance of quantity<derived_unit<si::metre, per<si::second>>{}, int>. The same can be obtained using optional unit symbols:
import mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity q = 42 * m / s;\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nquantity q = 42 * m / s;\nImportant
Unit symbols introduce a lot of short identifiers into the current scope, which may cause naming collisions with unrelated but already existing identifiers in the code base. This is why unit symbols are opt-in and typically should be imported only in the context where they are being used (e.g., function scope).
A user has several options here to choose from depending on the required scenario and possible naming conflicts:
using-directiveusing-declarationcustom short identifierunit namesExplicitly \"import\" all of the symbols of a specific system of units from a dedicated unit_symbols namespace with a using-directive:
using namespace mp_units;\n\nvoid foo(double speed_m_s)\n{\n // imports all the SI symbols at once\n using namespace si::unit_symbols;\n quantity speed = speed_m_s * m / s;\n // ...\n}\nNote
This solution is perfect for small and isolated scopes but can cause surprising issues when used in larger scopes or when used for the entire program namespace.
There are 29 named units in SI, and each of them has many prefixed variations (e.g., ng, kcd, ...). It is pretty easy to introduce a name collision with those.
Selectively bring only the required and not-conflicting symbols with using-declarations:
using namespace mp_units;\n\nvoid foo(double N)\n{\n // 'N' function parameter would collide with the SI symbol for Newton, so we only bring what we need\n using si::unit_symbols::m;\n using si::unit_symbols::s;\n quantity speed = N * m / s;\n // ...\n}\nSpecify a custom not conflicting unit identifier for a unit:
using namespace mp_units;\n\nvoid foo(double speed_m_s)\n{\n // names of some local variables are conflicting with the symbols we want to use\n auto m = ...;\n auto s = ...;\n\n constexpr Unit auto mps = si::metre / si::second;\n quantity speed = speed_m_s * mps;\n}\nFull unit names are straightforward to use and often provide the most readable code:
using namespace mp_units;\n\nvoid foo(double m, double s)\n{\n quantity speed = m * si::metre / (s * si::second);\n // ...\n}\nQuantities of the same kind can be added, subtracted, and compared to each other:
C++ modulesHeader filesimport mp_units;\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nstatic_assert(1 * km + 50 * m == 1050 * m);\n#include <mp-units/systems/si.h>\n\nusing namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\n\nstatic_assert(1 * km + 50 * m == 1050 * m);\nVarious quantities can be multiplied or divided by each other:
static_assert(140 * km / (2 * h) == 70 * km / h);\nNote
In case you wonder why this library does not use UDLs to create quantities, please check our FAQ.
"},{"location":"getting_started/quick_start/#quantity-points","title":"Quantity points","text":"The quantity point specifies an absolute quantity with respect to an origin. If no origin is provided explicitly, an implicit one will be provided by the library.
Together with quantities, they model The Affine Space.
Quantity points should be used in all places where adding two values is meaningless (e.g., temperature points, timestamps, altitudes, readouts from the car's odometer, etc.).
The set of operations that can be done on quantity points is limited compared to quantities. This introduces an additional type-safety.
C++ modulesHeader files#include <print>\nimport mp_units;\n\nint main()\n{\n using namespace mp_units;\n using namespace mp_units::si::unit_symbols;\n using namespace mp_units::usc::unit_symbols;\n\n quantity_point temp = absolute<deg_C>(20.);\n std::println(\"Temperature: {} ({})\",\n temp.quantity_from_zero(),\n temp.in(deg_F).quantity_from_zero());\n}\n#include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <mp-units/systems/usc.h>\n#include <print>\n\nint main()\n{\n using namespace mp_units;\n using namespace mp_units::si::unit_symbols;\n using namespace mp_units::usc::unit_symbols;\n\n quantity_point temp = absolute<deg_C>(20.);\n std::println(\"Temperature: {} ({})\",\n temp.quantity_from_zero(),\n temp.in(deg_F).quantity_from_zero());\n}\nThe above outputs:
Temperature: 20 \u2103 (68 \u2109)\nInfo
Check The Affine Space chapter to learn more about quantity points.
"},{"location":"users_guide/terms_and_definitions/","title":"Terms and Definitions","text":"The mp-units project consistently uses the official metrology vocabulary defined by the ISO and BIPM. You can find essential project-related definitions in our documentation's \"Glossary\" chapter. Even more, terms are provided in the official metrology vocabulary of the ISO and BIPM.
Tip
Please familiarize yourself with terms from \"Glossary\" to better understand the documentation and improve domain-related communication and discussions.
"},{"location":"users_guide/examples/avg_speed/","title":"avg_speed","text":"Try it on Compiler Explorer
Let's continue the previous example. This time, our purpose will not be to showcase as many library features as possible, but we will scope on different interfaces one can provide with the mp-units. We will also describe some advantages and disadvantages of presented solutions.
First, we either import a module or include all the necessary header files and import all the identifiers from the mp_units namespace:
#ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <exception>\n#include <iostream>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/ostream.h>\n#include <mp-units/systems/cgs.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\nNext, we define two functions calculating average speed based on quantities of fixed units and integral and floating-point representation types, respectively, and a third function that we introduced in the previous example:
avg_speed.cppnamespace {\n\nusing namespace mp_units;\n\nconstexpr quantity<si::metre / si::second, int> fixed_int_si_avg_speed(quantity<si::metre, int> d,\n quantity<si::second, int> t)\n{\n return d / t;\n}\n\nconstexpr quantity<si::metre / si::second> fixed_double_si_avg_speed(quantity<si::metre> d, quantity<si::second> t)\n{\n return d / t;\n}\nWe also added a simple utility to print our results:
avg_speed.cpp{\n return d / t;\n}\n\ntemplate<QuantityOf<isq::length> D, QuantityOf<isq::time> T, QuantityOf<isq::speed> V>\nvoid print_result(D distance, T duration, V speed)\n{\nNow, let's analyze how those three utility functions behave with different sets of arguments. First, we are going to use quantities of SI units and integral representation:
avg_speed.cpp std::cout << \"Average speed of a car that makes \" << distance << \" in \" << duration << \" is \" << result_in_kmph\n << \".\\n\";\n}\n\nvoid example()\n{\n using namespace mp_units::si::unit_symbols;\n\n // SI (int)\n {\n constexpr auto distance = 220 * km;\n constexpr auto duration = 2 * h;\n\n std::cout << \"SI units with 'int' as representation\\n\";\nThe above provides the following output:
SI units with 'int' as representation\nAverage speed of a car that makes 220 km in 2 h is 108 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nPlease note that in the first two cases, we must convert length from km to m and time from h to s. The converted values are used to calculate speed in m/s which is then again converted to the one in km/h. Those conversions not only impact the application's runtime performance but may also affect the precision of the final result. Such truncation can be easily observed in the first case where we deal with integral representation types (the resulting speed is 108 km/h).
The second scenario is really similar to the previous one, but this time, function arguments have floating-point representation types:
avg_speed.cpp print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\n }\n\n // SI (double)\n {\n constexpr auto distance = 220. * km;\n constexpr auto duration = 2. * h;\n\n std::cout << \"\\nSI units with 'double' as representation\\n\";\n\n // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\nConversion from floating-point to integral representation types is considered value-truncating and that is why now, in the first case, we need an explicit call to value_cast<int>.
In the text output, we can observe that, again, the resulting value gets truncated during conversions in the first cast:
SI units with 'double' as representation\nAverage speed of a car that makes 220 km in 2 h is 108 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nAverage speed of a car that makes 220 km in 2 h is 110 km/h.\nNext, let's do the same for integral and floating-point representations, but this time using international mile:
avg_speed.cpp print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\n }\n\n // International mile (int)\n {\n using namespace mp_units::international::unit_symbols;\n\n constexpr auto distance = 140 * mi;\n constexpr auto duration = 2 * h;\n\n std::cout << \"\\nInternational mile with 'int' as representation\\n\";\n\n // it is not possible to make a lossless conversion of miles to meters on an integral type\n // (explicit cast needed)\n print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));\n print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\n }\n\n // International mile (double)\n {\n using namespace mp_units::international::unit_symbols;\n\n constexpr auto distance = 140. * mi;\n constexpr auto duration = 2. * h;\n\n std::cout << \"\\nInternational mile with 'double' as representation\\n\";\n\n // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n // also it is not possible to make a lossless conversion of miles to meters on an integral type\n // (explicit cast needed)\n print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));\nOne important difference here is the fact that as it is not possible to make a lossless conversion of miles to meters on a quantity using an integral representation type, so this time, we need a value_cast<m, int> to force it.
If we check the text output of the above, we will see the following:
International mile with 'int' as representation\nAverage speed of a car that makes 140 mi in 2 h is 111 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112 km/h.\n\nInternational mile with 'double' as representation\nAverage speed of a car that makes 140 mi in 2 h is 111 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\nAverage speed of a car that makes 140 mi in 2 h is 112.654 km/h.\nPlease note how the first and third results get truncated using integral representation types.
In the end, we repeat the scenario for CGS units:
avg_speed.cpp print_result(distance, duration, avg_speed(distance, duration));\n }\n\n // CGS (int)\n {\n constexpr auto distance = 22'000'000 * cgs::centimetre;\n constexpr auto duration = 7200 * cgs::second;\n\n std::cout << \"\\nCGS units with 'int' as representation\\n\";\n\n // it is not possible to make a lossless conversion of centimeters to meters on an integral type\n // (explicit cast needed)\n print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));\n print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\n }\n\n // CGS (double)\n {\n constexpr auto distance = 22'000'000. * cgs::centimetre;\n constexpr auto duration = 7200. * cgs::second;\n\n std::cout << \"\\nCGS units with 'double' as representation\\n\";\n\n // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed\n // it is not possible to make a lossless conversion of centimeters to meters on an integral type\n // (explicit cast needed)\n print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));\n\n print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));\n print_result(distance, duration, avg_speed(distance, duration));\nAgain, we observe value_cast being used in the same places and consistent truncation errors in the text output:
CGS units with 'int' as representation\nAverage speed of a car that makes 22000000 cm in 7200 s is 108 km/h.\nAverage speed of a car that makes 22000000 cm in 7200 s is 110 km/h.\nAverage speed of a car that makes 22000000 cm in 7200 s is 109 km/h.\n\nCGS units with 'double' as representation\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 108 km/h.\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 110 km/h.\nAverage speed of a car that makes 2.2e+07 cm in 7200 s is 110 km/h.\nThe example file ends with a simple main() function:
}\n\n} // namespace\n\nint main()\n{\n try {\n example();\n } catch (const std::exception& ex) {\n std::cerr << \"Unhandled std exception caught: \" << ex.what() << '\\n';\n } catch (...) {\n std::cerr << \"Unhandled unknown exception caught\\n\";\n }\n}\nhello_units","text":"Try it on Compiler Explorer
This is a really simple example showcasing the features of the mp-units library.
First, we either import the mp_units module or include the headers for:
#include <mp-units/compat_macros.h>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <iomanip>\n#include <iostream>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\nAlso, to shorten the definitions, we \"import\" all the symbols from the mp_units namespace.
#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\nNext, we define a simple function that calculates the average speed based on the provided arguments of length and time:
hello_units.cpp#endif\n\nusing namespace mp_units;\nThe above function template takes any quantities implicitly convertible to isq::length and isq::time, respectively. Those quantities can use any compatible unit and a representation type. The function returns a result of a straightforward equation and ensures that its quantity type is implicitly convertible to isq::speed.
Tip
Besides verifying the type returned from the function, constraining a generic return type is beneficial for users of such a function as it provides more information of what to expect from a function than just using auto.
{\n return d / t;\n}\nThe above lines explicitly opt into using unit symbols from two systems of units. As this introduces a lot of short identifiers into the current scope, it is not done implicitly while including a header file.
hello_units.cpp{\n using namespace mp_units::si::unit_symbols;\n using namespace mp_units::international::unit_symbols;\n\n constexpr quantity v1 = 110 * km / h;\n constexpr quantity v2 = 70 * mph;\n constexpr quantity v3 = avg_speed(220. * km, 2 * h);\n23 & 24 create a quantity of kind isq::length / isq::time with the numbers and units provided. Such quantities can be converted or assigned to any other quantity with a matching kind.25 calls our function template with quantities of kind isq::length and isq::time and number and units provided.26 explicitly provides quantity types of the quantities passed to a function template. This time, those will not be quantity kinds anymore and will have more restrictive conversion rules.27 changes the unit of a quantity v3 to m / s in a value-preserving way (floating-point representations are considered to be value-preserving).28 does a similar operation, but this time, it would also succeed for value-truncating cases (if that was the case).29 does a value-truncating conversion of changing the underlying representation type from double to int. constexpr quantity v5 = v3.in(m / s);\n constexpr quantity v6 = value_cast<m / s>(v4);\n constexpr quantity v7 = value_cast<int>(v6);\n\n std::cout << v1 << '\\n'; // 110 km/h\n std::cout << std::setw(10) << std::setfill('*') << v2 << '\\n'; // ***70 mi/h\n std::cout << MP_UNITS_STD_FMT::format(\"{:*^10}\\n\", v3); // *110 km/h*\n std::cout << MP_UNITS_STD_FMT::format(\"{:%N in %U of %D}\\n\", v4); // 70 in mi/h of LT\u207b\u00b9\n std::cout << MP_UNITS_STD_FMT::format(\"{::N[.2f]}\\n\", v5); // 30.56 m/s\n std::cout << MP_UNITS_STD_FMT::format(\"{::N[.2f]U[dn]}\\n\", v6); // 31.29 m\u22c5s\u207b\u00b9\n std::cout << MP_UNITS_STD_FMT::format(\"{:%N}\\n\", v7); // 31\n}\nThe above presents various ways to print a quantity. Both stream insertion operations and std::format facilities are supported.
Tip
MP_UNITS_STD_FMT is used for compatibility reasons. If a specific compiler does not support std::format or a user prefers to use the {fmt} library, this macro will resolve to fmt namespace. Otherwise, the std namespace will be used.
si_constants","text":"Try it on Compiler Explorer
The next example presents all the seven defining constants of the SI system. We can observe how Faster-than-lightspeed Constants work in practice.
si_constants.cpp#include <mp-units/compat_macros.h>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_IMPORT_STD\nimport std;\n#else\n#include <iostream>\n#endif\n#ifdef MP_UNITS_MODULES\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#endif\nAs always, we start with the inclusion of all the needed header files. After that, for the simplicity of this example, we hack the character of quantities to be able to express vector quantities with simple scalar types.
si_constants.cpptemplate<class T>\n requires mp_units::is_scalar<T>\ninline constexpr bool mp_units::is_vector<T> = true;\n\nint main()\n{\n using namespace mp_units;\n using namespace mp_units::si;\n using namespace mp_units::si::unit_symbols;\n\n std::cout << \"The seven defining constants of the SI and the seven corresponding units they define:\\n\";\n std::cout << MP_UNITS_STD_FMT::format(\"- hyperfine transition frequency of Cs: {} = {::N[.0]}\\n\",\n 1. * si2019::hyperfine_structure_transition_frequency_of_cs,\n (1. * si2019::hyperfine_structure_transition_frequency_of_cs).in(Hz));\n std::cout << MP_UNITS_STD_FMT::format(\"- speed of light in vacuum: {} = {::N[.0]}\\n\",\n 1. * si2019::speed_of_light_in_vacuum,\n (1. * si2019::speed_of_light_in_vacuum).in(m / s));\n std::cout << MP_UNITS_STD_FMT::format(\"- Planck constant: {} = {::N[.8e]}\\n\",\n 1. * si2019::planck_constant, (1. * si2019::planck_constant).in(J * s));\n std::cout << MP_UNITS_STD_FMT::format(\"- elementary charge: {} = {::N[.9e]}\\n\",\n 1. * si2019::elementary_charge, (1. * si2019::elementary_charge).in(C));\n std::cout << MP_UNITS_STD_FMT::format(\"- Boltzmann constant: {} = {::N[.6e]}\\n\",\n 1. * si2019::boltzmann_constant, (1. * si2019::boltzmann_constant).in(J / K));\n std::cout << MP_UNITS_STD_FMT::format(\"- Avogadro constant: {} = {::N[.8e]}\\n\",\n 1. * si2019::avogadro_constant, (1. * si2019::avogadro_constant).in(one / mol));\n std::cout << MP_UNITS_STD_FMT::format(\"- luminous efficacy: {} = {}\\n\",\n 1. * si2019::luminous_efficacy, (1. * si2019::luminous_efficacy).in(lm / W));\n}\nThe main part of the example prints all of the SI-defining constants. While analyzing the output of this program (provided below), we can easily notice that a direct printing of the quantity provides just a value 1 with a proper constant symbol. This is the main power of the Faster-than-lightspeed Constants feature. Only after we explicitly convert the unit of a quantity to proper SI units we get an actual numeric value of the constant.
The seven defining constants of the SI and the seven corresponding units they define:\n- hyperfine transition frequency of Cs: 1 \u0394\u03bd_Cs = 9192631770 Hz\n- speed of light in vacuum: 1 c = 299792458 m/s\n- Planck constant: 1 h = 6.62607015e-34 J s\n- elementary charge: 1 e = 1.602176634e-19 C\n- Boltzmann constant: 1 k = 1.380649e-23 J/K\n- Avogadro constant: 1 N_A = 6.02214076e+23 1/mol\n- luminous efficacy: 1 K_cd = 683 lm/W\nWarning
This chapter's features are experimental and subject to change or removal. Please share your feedback if something seems wrong or could be improved.
"},{"location":"users_guide/framework_basics/character_of_a_quantity/#scalars-vectors-and-tensors","title":"Scalars, vectors, and tensors","text":"ISO 80000-2
Scalars, vectors and tensors are mathematical objects that can be used to denote certain physical quantities and their values. They are as such independent of the particular choice of a coordinate system, whereas each scalar component of a vector or a tensor and each component vector and component tensor depend on that choice.
Such distinction is important because each quantity character represents different properties and allows different operations to be done on its quantities.
For example, imagine a physical units library that allows the creation of a \\(speed\\) quantity from both \\(length / time\\) and \\(length * time\\). It wouldn't be too safe to use such a product, right?
Now we have to realize that both of the above operations (multiplication and division) are not even mathematically defined for linear algebra types such as vectors or tensors. On the other hand, two vectors can be passed as arguments to dot and cross-product operations. The result of the first one is a scalar. The second one results in a vector that is perpendicular to both vectors passed as arguments. Again, it wouldn't be safe to allow replacing those two operations with each other or expect the same results from both cases. This simply can't work.
"},{"location":"users_guide/framework_basics/character_of_a_quantity/#isq-defines-quantities-of-all-characters","title":"ISQ defines quantities of all characters","text":"While defining quantities ISO 80000 explicitly mentions when a specific quantity has a vector or tensor character. Here are some examples:
Quantity Character Quantity Equation \\(duration\\) scalar {base quantity} \\(mass\\) scalar {base quantity} \\(length\\) scalar {base quantity} \\(path\\; length\\) scalar {base quantity} \\(radius\\) scalar {base quantity} \\(position\\; vector\\) vector {base quantity} \\(velocity\\) vector \\(position\\; vector / duration\\) \\(acceleration\\) vector \\(velocity / duration\\) \\(force\\) vector \\(mass * acceleration\\) \\(power\\) scalar \\(force \\cdot velocity\\) \\(moment\\; of\\; force\\) vector \\(position\\; vector \\times force\\) \\(torque\\) scalar \\(moment\\; of\\; force \\cdot \\{unit\\; vector\\}\\) \\(surface\\; tension\\) scalar \\(\\lvert force \\rvert / length\\) \\(angular\\; displacement\\) scalar \\(path\\; length / radius\\) \\(angular\\; velocity\\) vector \\(angular\\; displacement / duration * \\{unit\\; vector\\}\\) \\(momentum\\) vector \\(mass * velocity\\) \\(angular\\; momentum\\) vector \\(position\\; vector \\times momentum\\) \\(moment\\; of\\; inertia\\) tensor \\(angular\\; momentum \\otimes angular\\; velocity\\)In the above equations:
Note
As of now, all of the C++ physical units libraries on the market besides mp-units do not support the operations mentioned above. They expose only multiplication and division operators, which do not work for linear algebra-based representation types. If a user of those libraries would like to create the quantities provided in the above table properly, this would result in a compile-time error stating that multiplication and division of two linear algebra vectors is impossible.
"},{"location":"users_guide/framework_basics/character_of_a_quantity/#characters-dont-apply-to-dimensions-and-units","title":"Characters don't apply to dimensions and units","text":"ISO 80000 explicitly states that dimensions are orthogonal to quantity characters:
ISO 80000-1:2009
In deriving the dimension of a quantity, no account is taken of its scalar, vector, or tensor character.
Also, it explicitly states that:
ISO 80000-2
All units are scalars.
"},{"location":"users_guide/framework_basics/character_of_a_quantity/#defining-vector-and-tensor-quantities","title":"Defining vector and tensor quantities","text":"To specify that a specific quantity has a vector or tensor character a value of quantity_character enumeration can be appended to the quantity_spec describing such a quantity type:
inline constexpr struct position_vector final : quantity_spec<length, quantity_character::vector> {} position_vector;\ninline constexpr struct displacement final : quantity_spec<length, quantity_character::vector> {} displacement;\ninline constexpr struct position_vector final : quantity_spec<position_vector, length, quantity_character::vector> {} position_vector;\ninline constexpr struct displacement final : quantity_spec<displacement, length, quantity_character::vector> {} displacement;\nQUANTITY_SPEC(position_vector, length, quantity_character::vector);\nQUANTITY_SPEC(displacement, length, quantity_character::vector);\nWith the above, all the quantities derived from position_vector or displacement will have a correct character determined according to the kind of operations included in the quantity equation defining a derived quantity.
For example, velocity in the below definition will be defined as a vector quantity (no explicit character override is needed):
inline constexpr struct velocity final : quantity_spec<speed, position_vector / duration> {} velocity;\ninline constexpr struct velocity final : quantity_spec<velocity, speed, position_vector / duration> {} velocity;\nQUANTITY_SPEC(velocity, speed, position_vector / duration);\nAs we remember, the quantity class template is defined as follows:
template<Reference auto R,\n RepresentationOf<get_quantity_spec(R).character> Rep = double>\nclass quantity;\nThe second template parameter is constrained with a RepresentationOf concept that checks if the provided representation type satisfies the requirements for the character associated with this quantity type.
Note
The current version of the C++ Standard Library does not provide any types that could be used as a representation type for vector and tensor quantities. This is why users are on their own here .
To provide examples and implement unit tests, our library uses the types proposed in the P1385 and available as a Conan package in the Conan Center. However, thanks to the provided customization points, any linear algebra library types can be used as a vector or tensor quantity representation type.
To enable the usage of a user-defined type as a representation type for vector or tensor quantities, we need to provide a partial specialization of is_vector or is_tensor customization points.
For example, here is how it can be done for the P1385 types:
#include <matrix>\n\nusing la_vector = STD_LA::fixed_size_column_vector<double, 3>;\n\ntemplate<>\ninline constexpr bool mp_units::is_vector<la_vector> = true;\nWith the above, we can use la_vector as a representation type for our quantity:
Quantity auto q = la_vector{1, 2, 3} * isq::velocity[m / s];\nIn case there is an ambiguity of operator* between mp-units and a linear algebra library, we can either:
use two-parameter constructor
Quantity auto q = quantity{la_vector{1, 2, 3}, isq::velocity[m / s]};\nprovide a dedicated overload of operator* that will resolve the ambiguity and wrap the above
template<Reference R>\nQuantity auto operator*(la_vector rep, R)\n{\n return quantity{rep, R{}};\n}\nNote
The following does not work:
Quantity auto q1 = la_vector{1, 2, 3} * m / s;\nQuantity auto q2 = isq::velocity(la_vector{1, 2, 3} * m / s);\nquantity<isq::velocity[m/s]> q3{la_vector{1, 2, 3} * m / s};\nIn all the cases above, the SI unit m / s has an associated scalar quantity of isq::length / isq::time. la_vector is not a correct representation type for a scalar quantity so the construction fails.
Sometimes we want to use a vector quantity, but we don't care about its direction. For example, the standard gravity acceleration constant always points down, so we might not care about this in a particular scenario. In such a case, we may want to \"hack\" the library to allow scalar types to be used as a representation type for scalar quantities.
For example, we can do the following:
template<class T>\n requires mp_units::is_scalar<T>\ninline constexpr bool mp_units::is_vector<T> = true;\nwhich says that every type that can be used as a scalar representation is also allowed for vector quantities.
Doing the above is actually not such a big \"hack\" as the ISO 80000 explicitly allows it:
ISO 80000-2
A vector is a tensor of the first order and a scalar is a tensor of order zero.
Despite it being allowed by ISO 80000, for type-safety reasons, we do not allow such a behavior by default, and a user has to opt into such scenarios explicitly.
"},{"location":"users_guide/framework_basics/concepts/","title":"Concepts","text":"This chapter enumerates all the user-facing concepts in the mp-units library.
"},{"location":"users_guide/framework_basics/concepts/#Dimension","title":"Dimension<T>","text":"Dimension concept matches a dimension of either a base or derived quantity:
base_dimension class template. It should be instantiated with a unique symbol identifier describing this dimension in a specific system of quantities.All of the above dimensions have to be marked as final.
DimensionOf<T, V>","text":"DimensionOf concept is satisfied when both arguments satisfy a Dimension concept and when they compare equal.
QuantitySpec<T>","text":"QuantitySpec concept matches all the quantity specifications including:
quantity_spec class template instantiated with a base dimension argument.quantity_spec class template instantiated with a result of a quantity equation passed as an argument.quantity_spec class template instantiated with another \"parent\" quantity specification passed as an argument.All of the above quantity specifications have to be marked as final.
QuantitySpecOf<T, V>","text":"QuantitySpecOf concept is satisfied when both arguments satisfy a QuantitySpec concept and when T is implicitly convertible to V.
Additionally:
T should not be a nested quantity specification of VT is quantity kind or V should not be a nested quantity specification of TThose additional conditions are required to make the following work:
static_assert(ReferenceOf<si::radian, isq::angular_measure>);\nstatic_assert(!ReferenceOf<si::radian, dimensionless>);\nstatic_assert(!ReferenceOf<isq::angular_measure[si::radian], dimensionless>);\nstatic_assert(ReferenceOf<one, isq::angular_measure>);\nstatic_assert(!ReferenceOf<dimensionless[one], isq::angular_measure>);\nUnit<T>","text":"Unit concept matches all the units in the library including:
named_unit class template instantiated with a unique symbol identifier describing this unit in a specific system of units.named_unit class template instantiated with a unique symbol identifier and a product of multiplying another unit with some magnitude.prefixed_unit class template instantiated with a prefix symbol, a magnitude, and a unit to be prefixed.named_unit class template instantiated with a unique symbol identifier and a result of unit equation passed as an argument.All of the above units have to be marked as final.
Note
In the mp-units library, physical constants are also implemented as units.
"},{"location":"users_guide/framework_basics/concepts/#AssociatedUnit","title":"AssociatedUnit<T>","text":"AssociatedUnit concept describes a unit with an associated quantity and is satisfied by:
named_unit class template instantiated with a unique symbol identifier and a QuantitySpec of a quantity kind.All units in the SI have associated quantities. For example, si::second is specified to measure isq::time.
Natural units typically do not have an associated quantity. For example, if we assume c = 1, a natural::second unit can be used to measure both time and length. In such case, speed would have a unit of one.
PrefixableUnit<T>","text":"PrefixableUnit concept is satisfied by all units derived from a named_unit class template for which a customization point unit_can_be_prefixed<T{}> was not explicitly set to false. Such units can be passed as an argument to a prefixed_unit class template.
All units in the SI can be prefixed with SI-defined prefixes.
Some off-system units like non_si::day can't be prefixed. To enforce that, the following has to be provided:
template<> inline constexpr bool unit_can_be_prefixed<non_si::day> = false;\nUnitOf<T, V>","text":"UnitOf concept is satisfied for all units T matching an AssociatedUnit concept with an associated quantity type implicitly convertible to V.
Additionally, the kind of V and the kind of quantity type associated with T must be the same, or the quantity type associated with T may not be derived from the kind of V.
This condition is required to make dimensionless[si::radian] invalid as si::radian should be only used for isq::angular_measure, which is a nested quantity kind within the dimensionless quantities tree.
Reference<T>","text":"Reference concept is satisfied by all quantity reference types. Such types provide all the meta-information required to create a Quantity. A Reference can either be:
AssociatedUnit.reference class template with a QuantitySpec passed as the first template argument and a Unit passed as the second one.ReferenceOf<T, V>","text":"ReferenceOf concept is satisfied by references T which have a quantity specification that satisfies QuantitySpecOf<V> concept. |
Representation<T>","text":"Representation concept constraints a type of a number that stores the value of a quantity.
RepresentationOf<T, Ch>","text":"RepresentationOf concept is satisfied by all Representation types that are of a specified quantity character Ch.
A user can declare a custom representation type to be of a specific character by providing the specialization with true for one or more of the following variable templates:
is_scalar<T>is_vector<T>is_tensor<T>If we want to use scalar types to also express vector quantities (e.g., ignoring the \"direction\" of the vector) the following definition can be provided to enable such a behavior:
template<class T>\n requires mp_units::is_scalar<T>\ninline constexpr bool mp_units::is_vector<T> = true;\nQuantity<T>","text":"Quantity concept matches every quantity in the library and is satisfied by all types being or deriving from an instantiation of a quantity class template.
QuantityOf<T, V>","text":"QuantityOf concept is satisfied by all the quantities for which a QuantitySpecOf<V> is true.
PointOrigin<T>","text":"PointOrigin concept matches all quantity point origins in the library. It is satisfied by either:
absolute_point_origin class template.relative_point_origin class template.PointOriginFor<T, V>","text":"PointOriginFor concept is satisfied by all PointOrigin types that have quantity type implicitly convertible from quantity specification V, which means that V must satisfy QuantitySpecOf<T::quantity_spec>.
si::ice_point can serve as a point origin for points of isq::Celsius_temperature because this quantity type implicitly converts to isq::thermodynamic_temperature.
However, if we define mean_sea_level in the following way:
inline constexpr struct mean_sea_level final : absolute_point_origin<isq::altitude> {} mean_sea_level;\nthen it can't be used as a point origin for points of isq::length or isq::width as none of them is implicitly convertible to isq::altitude:
QuantityPoint<T>","text":"QuantityPoint concept is satisfied by all types being either a specialization or derived from quantity_point class template.
QuantityPointOf<T, V>","text":"QuantityPointOf concept is satisfied by all the quantity points T that match the following value V:
V Condition QuantitySpec The quantity point quantity specification satisfies QuantitySpecOf<V> concept. PointOrigin The point and V have the same absolute point origin."},{"location":"users_guide/framework_basics/concepts/#QuantityLike","title":"QuantityLike<T>","text":"QuantityLike concept provides interoperability with other libraries and is satisfied by a type T for which an instantiation of quantity_like_traits type trait yields a valid type that provides:
reference that matches the Reference concept,rep type that matches RepresentationOf concept with the character provided in reference.to_numerical_value(T) static member function returning a raw value of the quantity packed in either convert_explicitly or convert_implicitly wrapper that enables implicit conversion in the latter case.from_numerical_value(rep) static member function returning T packed in either convert_explicitly or convert_implicitly wrapper that enables implicit conversion in the latter case.This is how support for std::chrono::seconds can be provided:
template<>\nstruct mp_units::quantity_like_traits<std::chrono::seconds> {\n static constexpr auto reference = si::second;\n using rep = std::chrono::seconds::rep;\n\n [[nodiscard]] static constexpr convert_implicitly<rep> to_numerical_value(const std::chrono::seconds& d)\n {\n return d.count();\n }\n\n [[nodiscard]] static constexpr convert_implicitly<std::chrono::seconds> from_numerical_value(const rep& v)\n {\n return std::chrono::seconds(v);\n }\n};\n\nquantity q = 42s;\nstd::chrono::seconds dur = 42 * s;\nQuantityPointLike<T>","text":"QuantityPointLike concept provides interoperability with other libraries and is satisfied by a type T for which an instantiation of quantity_point_like_traits type trait yields a valid type that provides:
reference that matches the Reference concept.point_origin that matches the PointOrigin concept.rep type that matches RepresentationOf concept with the character provided in reference.to_numerical_value(T) static member function returning a raw value of the quantity being the offset of the point from the origin packed in either convert_explicitly or convert_implicitly wrapper that enables implicit conversion in the latter case.from_numerical_value(rep) static member function returning T packed in either convert_explicitly or convert_implicitly wrapper that enables implicit conversion in the latter case.This is how support for a std::chrono::time_point of std::chrono::seconds can be provided:
template<typename C>\nstruct mp_units::quantity_point_like_traits<std::chrono::time_point<C, std::chrono::seconds>> {\n using T = std::chrono::time_point<C, std::chrono::seconds>;\n static constexpr auto reference = si::second;\n static constexpr struct point_origin_ final : absolute_point_origin<isq::time> {} point_origin{};\n using rep = std::chrono::seconds::rep;\n\n [[nodiscard]] static constexpr convert_implicitly<rep> to_numerical_value(const T& tp)\n {\n return tp.time_since_epoch().count();\n }\n\n [[nodiscard]] static constexpr convert_implicitly<T> from_numerical_value(const rep& v)\n {\n return T(std::chrono::seconds(v));\n }\n};\n\nquantity_point qp = time_point_cast<std::chrono::seconds>(std::chrono::system_clock::now());\nstd::chrono::sys_seconds q = qp + 42 * s;\nThe most important entities in the mp-units library are:
The graph provided below presents how those and a few other entities depend on each other:
flowchart TD\n Unit --- Reference\n Dimension --- QuantitySpec[\"Quantity specification\"]\n quantity_character[\"Quantity character\"] --- QuantitySpec\n QuantitySpec --- Reference[\"Quantity reference\"]\n Reference --- Quantity\n quantity_character -.- Representation\n Representation --- Quantity\n Quantity --- QuantityPoint[\"Quantity point\"]\n PointOrigin[\"Point origin\"] --- QuantityPoint\n\n click Dimension \"#dimension\"\n click quantity_character \"#quantity-character\"\n click QuantitySpec \"#quantity-specification\"\n click Unit \"#unit\"\n click Reference \"#quantity-reference\"\n click Representation \"#quantity-representation\"\n click Quantity \"#quantity\"\n click PointOrigin \"#point-origin\"\n click QuantityPoint \"#quantity-point\"Dimension specifies the dependence of a quantity on the base quantities of a particular system of quantities. It is represented as a product of powers of factors corresponding to the base quantities, omitting any numerical factor.
In the mp-units library, we use the terms:
For example:
iec80000::dim_traffic_intensity base dimension to extend ISQ with strong information technology quantities.Base dimensions can be defined by the user in the following way:
inline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct dim_time final : base_dimension<\"T\"> {} dim_time;\nDerived dimensions are implicitly created by the library's framework based on the quantity equation provided in the quantity specification:
C++23C++20Portableinline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct time final : quantity_spec<dim_time> {} time;\ninline constexpr struct speed final : quantity_spec<length / time> {} speed;\n\nstatic_assert(speed.dimension == dim_length / dim_time);\ninline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct time final : quantity_spec<time, dim_time> {} time;\ninline constexpr struct speed final : quantity_spec<speed, length / time> {} speed;\n\nstatic_assert(speed.dimension == dim_length / dim_time);\nQUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(time, dim_time);\nQUANTITY_SPEC(speed, length / time);\n\nstatic_assert(speed.dimension == dim_length / dim_time);\nImportant
Users should not explicitly define any derived dimensions. Those should always be implicitly created by the framework.
The multiplication/division on quantity specifications also multiplies/divides their dimensions:
static_assert((length / time).dimension == dim_length / dim_time);\nThe dimension equation of isq::dim_length / isq::dim_time results in the derived_dimension<isq::dim_length, per<isq::dim_time>> type.
ISO 80000 explicitly states that quantities (even of the same kind) may have different characters:
The quantity character in the mp-units library is implemented with the quantity_character enumeration:
enum class quantity_character { scalar, vector, tensor };\nInfo
You can read more on quantity characters in the \"Character of a Quantity\" chapter.
"},{"location":"users_guide/framework_basics/design_overview/#quantity-specification","title":"Quantity specification","text":"Dimension is not enough to describe a quantity. This is why the ISO 80000 provides hundreds of named quantity types. It turns out that there are many more quantity types in the ISQ than the named units in the SI.
This is why the mp-units library introduces a quantity specification entity that stores:
Note
We know that it might be sometimes confusing to talk about quantities, quantity types/names, and quantity specifications. However, it might be important to notice here that even the ISO 80000 admits that:
It is customary to use the same term, \"quantity\", to refer to both general quantities, such as length, mass, etc., and their instances, such as given lengths, given masses, etc. Accordingly, we are used to saying both that length is a quantity and that a given length is a quantity by maintaining the specification \u2013 \"general quantity, \\(Q\\)\" or \"individual quantity, \\(Q_\\textsf{a}\\)\" \u2013 implicit and exploiting the linguistic context to remove the ambiguity.
In the mp-units library, we have a:
quantity class template,quantity_spec class template that among others identifies a specific quantity type/name.For example:
isq::length, isq::mass, isq::time, isq::electric_current, isq::thermodynamic_temperature, isq::amount_of_substance, and isq::luminous_intensity are the specifications of base quantities in the ISQ.isq::width, isq::height, isq::radius, and isq::position_vector are only a few of many quantities of a kind length specified in the ISQ.isq::area, isq::speed, isq::moment_of_force are only a few of many derived quantities provided in the ISQ.Quantity specification can be defined by the user in one of the following ways:
C++23C++20Portableinline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct height final : quantity_spec<length> {} height;\ninline constexpr struct speed final : quantity_spec<length / time> {} speed;\ninline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct height final : quantity_spec<height, length> {} height;\ninline constexpr struct speed final : quantity_spec<speed, length / time> {} speed;\nQUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(height, length);\nQUANTITY_SPEC(speed, length / time);\nThe quantity equation of isq::length / isq::time results in the derived_quantity_spec<isq::length, per<isq::time>> type.
A unit is a concrete amount of a quantity that allows us to measure the values of quantities of the same kind and represent the result as a number being the ratio of the two quantities.
For example:
si::second, si::metre, si::kilogram, si::ampere, si::kelvin, si::mole, and si::candela are the base units of the SI.si::kilo<si::metre> is a prefixed unit of length.si::radian, si::newton, and si::watt are examples of named derived units within the SI.non_si::minute is an example of a scaled unit of time.si::si2019::speed_of_light_in_vacuum is a physical constant standardized by the SI in 2019.Note
In the mp-units library, physical constants are also implemented as units.
A unit can be defined by the user in one of the following ways:
template<PrefixableUnit U> struct kilo_ : prefixed_unit<\"k\", mag_power<10, 3>, U{}> {};\ntemplate<PrefixableUnit auto U> inline constexpr kilo_<decltype(U)> kilo;\n\ninline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\ninline constexpr struct minute final : named_unit<\"min\", mag<60> * second> {} minute;\ninline constexpr struct gram final : named_unit<\"g\", kind_of<isq::mass>> {} gram;\ninline constexpr auto kilogram = kilo<gram>;\ninline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\n\ninline constexpr struct speed_of_light_in_vacuum final : named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\nThe unit equation of si::metre / si::second results in the derived_unit<si::metre, per<si::second>> type.
ISO defines a quantity as:
Quote
property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
After that, it says:
Quote
A reference can be a measurement unit, a measurement procedure, a reference material, or a combination of such.
In the mp-units library, a quantity reference provides all the domain-specific metadata for the quantity besides its numerical value:
Together with the value of a representation type, it forms a quantity.
In the library, we have two different ways to provide a reference:
reference class template with this quantity spec and a unit passed as arguments.Note
All the units of the SI have associated quantity kinds and may serve as a reference.
For example:
si::metre is defined in the SI as a unit of isq::length and thus can be used as a reference to instantiate a quantity of length (e.g., 42 * m).isq::height[m] results with reference<isq::height, si::metre>, which can be used to instantiate a quantity of isq::height with a unit of si::metre (e.g., 42 * isq::height[m]).Quantity representation defines the type used to store the numerical value of a quantity. Such a type should be of a specific quantity character provided in the quantity specification.
Note
By default, all floating-point and integral (besides bool) types are treated as scalars.
ISO defines a quantity as:
Quote
property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
This is why a quantity class template is defined in the library as:
template<Reference auto R,\n RepresentationOf<get_quantity_spec(R).character> Rep = double>\nclass quantity;\nIts value can be easily created by multiplying/dividing the numerical value and a reference.
For example:
42 * m, 42 * si::metre, 42 * isq::height[m], and isq::height(42 * m) create a quantity.quantity<si::metre, int>, quantity<isq::height[m]>).In the affine space theory, the point origin specifies where the \"zero\" of our measurement's scale is.
In the mp-units library, we have two types of point origins:
For example:
inline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr struct ice_point final : relative_point_origin<absolute_zero + 273'150 * milli<kelvin>> {} ice_point;\nQuantity point implements a point in the affine space theory.
In the mp-units library, the quantity point is implemented as:
template<Reference auto R,\n PointOriginFor<get_quantity_spec(R)> auto PO,\n RepresentationOf<get_quantity_spec(R).character> Rep = double>\nclass quantity_point;\nIts value can be easily created by adding/subtracting the quantity with a point origin.
For example:
ice_point provided in the previous example:constexpr auto room_reference_temperature = ice_point + delta<isq::Celsius_temperature[deg_C]>(21);\nThe quantities we discussed so far always had some specific type and physical dimension. However, this is not always the case. While performing various computations, we sometimes end up with so-called \"dimensionless\" quantities, which ISO defines as quantities of dimension one:
ISO/IEC Guide 99
Dividing two quantities of the same kind always results in a quantity of dimension one. However, depending on what type of quantities we divide or what their units are, we may end up with slightly different results.
Note
In mp-units, dividing two quantities of the same dimension always results in a quantity with the dimension being dimension_one. This is often different for other physical units libraries, which may return a raw representation type for such cases. A raw value is also always returned from the division of two std::chrono::duration objects.
To read more about the reasoning for this design decision, please check our FAQ.
"},{"location":"users_guide/framework_basics/dimensionless_quantities/#dividing-quantities-of-the-same-type","title":"Dividing quantities of the same type","text":"First, let's analyze what happens if we divide two quantities of the same type:
constexpr QuantityOf<dimensionless> auto q = isq::height(200 * m) / isq::height(50 * m);\nIn such a case, we end up with a dimensionless quantity that has the following properties:
static_assert(q.quantity_spec == dimensionless);\nstatic_assert(q.dimension == dimension_one);\nstatic_assert(q.unit == one);\nIn case we would like to print its value, we would see a raw value of 4 in the output with no unit being printed.
Now let's see what happens if we divide quantities of the same dimension and unit but which have different quantity types:
constexpr QuantityOf<dimensionless> auto q = isq::work(200 * J) / isq::heat(50 * J);\nAgain we end up with dimension_one and one, but this time:
static_assert(q.quantity_spec == isq::work / isq::heat);\nAs shown above, the result is not of a dimensionless type anymore. Instead, we get a quantity type derived from the performed quantity equation. According to the ISQ, work divided by heat is the recipe for the thermodynamic efficiency quantity, thus:
static_assert(implicitly_convertible(q.quantity_spec, isq::efficiency_thermodynamics));\nNote
The quantity of isq::efficiency_thermodynamics is of a kind dimensionless, so it is implicitly convertible to dimensionless and satisfies the QuantityOf<dimensionless> concept.
Now, let's see what happens when we divide two quantities of the same type but different units:
constexpr QuantityOf<dimensionless> auto q = isq::height(4 * km) / isq::height(2 * m);\nThis time, we still get a quantity of the dimensionless type with a dimension_one as its dimension. However, the resulting unit is not one anymore:
static_assert(q.unit == mag_power<10, 3> * one);\nIn case we would print the text output of this quantity, we would not see a raw value of 2000, but 2 km/m.
First, it may look surprising, but this is consistent with dividing quantities of different dimensions. For example, if we divide 4 * km / 2 * s, we do not expect km to be \"expanded\" to m before the division, right? We would expect the result of 2 km/s, which is exactly what we get when we divide quantities of the same kind.
This is a compelling feature that allows us to express huge or tiny ratios without the need for big and expensive representation types. With this, we can easily define things like a Hubble's constant that uses a unit that is proportional to the ratio of kilometers per megaparsecs, which are both units of length:
inline constexpr struct hubble_constant final :\n named_unit<{u8\"H\u2080\", \"H_0\"}, mag_ratio<701, 10> * si::kilo<si::metre> / si::second / si::mega<parsec>> {} hubble_constant;\nAnother important use case for dimensionless quantities is to provide strong types for counts of things. For example:
Thanks to assigning strong names to such quantities, later on, they can be explicitly used as arguments in the quantity equations of other quantities deriving from them.
"},{"location":"users_guide/framework_basics/dimensionless_quantities/#predefined-units-of-the-dimensionless-quantity","title":"Predefined units of the dimensionless quantity","text":"As we observed above, the most common unit for dimensionless quantities is one. It has the ratio of 1 and does not output any textual symbol.
Important: one is an identity
A unit one is special in the entire type system of units as it is considered to be an identity operand in the unit expression templates. This means that, for example:
static_assert(one * one == one);\nstatic_assert(one * si::metre == si::metre);\nstatic_assert(si::metre / si::metre == one);\nThe same is also true for dimension_one and dimensionless in the domains of dimensions and quantity specifications.
Besides the unit one, there are a few other scaled units predefined in the library for usage with dimensionless quantities:
inline constexpr struct percent final : named_unit<\"%\", mag_ratio<1, 100> * one> {} percent;\ninline constexpr struct per_mille final : named_unit<{u8\"\u2030\", \"%o\"}, mag_ratio<1, 1000> * one> {} per_mille;\ninline constexpr struct parts_per_million final : named_unit<\"ppm\", mag_ratio<1, 1'000'000> * one> {} parts_per_million;\ninline constexpr auto ppm = parts_per_million;\none","text":"Quantities of the unit one are the only ones that are implicitly convertible from a raw value and explicitly convertible to it. This property also expands to usual arithmetic operators.
Thanks to the above, we can type:
quantity<one> inc(quantity<one> q) { return q + 1; }\nvoid legacy(double) { /* ... */ }\n\nif (auto q = inc(42); q != 0)\n legacy(static_cast<int>(q));\nSpecial, often controversial, examples of dimensionless quantities are an angular measure and solid angular measure quantities that are defined in the ISQ to be the result of a division of \\(arc\\; length / radius\\) and \\(area / radius^2\\) respectively. Moreover, ISQ also explicitly states that both can be expressed in the unit one. This means that both angular measure and solid angular measure should be of a kind dimensionless.
On the other hand, ISQ also specifies that a unit radian can be used for angular measure, and a unit steradian can be used for solid angular measure. Those should not be mixed or used to express other types of dimensionless quantities. This means that both angular measure and solid angular measure should also be quantity kinds by themselves.
Note
Many people claim that angle being a dimensionless quantity is a bad idea. There are proposals submitted to make an angle a base quantity and rad to become a base unit. More on this topic can be found in the \"Strong Angular System\" chapter.
Thanks to the usage of magnitudes the library provides efficient strong types for all angular types. This means that with the built-in support for magnitudes of \\(\\pi\\) we can provide accurate conversions between radians and degrees. The library also provides common trigonometric functions for angular quantities:
using namespace mp_units::si::unit_symbols;\nusing mp_units::angular::unit_symbols::rad;\nusing mp_units::angular::unit_symbols::deg;\nusing mp_units::angular::unit_symbols::grad;\n\nquantity speed = 110 * km / h;\nquantity rate_of_climb = -0.63657 * m / s;\nquantity glide_ratio = speed / -rate_of_climb;\nquantity glide_angle = angular::asin(1 / glide_ratio);\n\nstd::println(\"Glide ratio: {::N[.1f]}\", glide_ratio.in(one));\nstd::println(\"Glide angle:\");\nstd::println(\" - {::N[.4f]}\", glide_angle.in(rad));\nstd::println(\" - {::N[.2f]}\", glide_angle.in(deg));\nstd::println(\" - {::N[.2f]}\", glide_angle.in(grad));\nThe above program prints:
Glide ratio: 48.0\nGlide angle:\n - 0.0208 rad\n - 1.19\u00b0\n - 1.33\u1d4d\nNote
In the production code the above speed and rate_of_climb quantities should probably be modelled as separate typed quantities of the same kind.
Angular quantities are not the only ones with such a \"strange\" behavior. Another but a similar case is a storage capacity quantity specified in IEC-80000-13 that again allows expressing it in both one and bit units.
Those cases make dimensionless quantities an exceptional tree in the library. This is the only quantity hierarchy that contains more than one quantity kind in its tree:
flowchart TD\n dimensionless[\"dimensionless\\n[one]\"]\n dimensionless --- rotation\n dimensionless --- efficiency\n dimensionless --- angular_measure[\"angular_measure\\n[rad]\"]\n angular_measure --- rotational_displacement\n angular_measure --- phase_angle\n dimensionless --- solid_angular_measure[\"solid_angular_measure\\n[sr]\"]\n dimensionless --- drag_factor\n dimensionless --- storage_capacity[\"storage_capacity\\n[bit]\"] --- equivalent_binary_storage_capacity\n dimensionless --- ...To provide such support in the library, we provided an is_kind specifier that can be appended to the quantity specification:
inline constexpr struct angular_measure final : quantity_spec<dimensionless, arc_length / radius, is_kind> {} angular_measure;\ninline constexpr struct solid_angular_measure final : quantity_spec<dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;\ninline constexpr struct storage_capacity final : quantity_spec<dimensionless, is_kind> {} storage_capacity;\ninline constexpr struct angular_measure final : quantity_spec<angular_measure, dimensionless, arc_length / radius, is_kind> {} angular_measure;\ninline constexpr struct solid_angular_measure final : quantity_spec<solid_angular_measure, dimensionless, area / pow<2>(radius), is_kind> {} solid_angular_measure;\ninline constexpr struct storage_capacity final : quantity_spec<storage_capacity, dimensionless, is_kind> {} storage_capacity;\nQUANTITY_SPEC(angular_measure, dimensionless, arc_length / radius, is_kind);\nQUANTITY_SPEC(solid_angular_measure, dimensionless, area / pow<2>(radius), is_kind);\nQUANTITY_SPEC(storage_capacity, dimensionless, is_kind);\nWith the above, we can constrain radian, steradian, and bit to be allowed for usage with specific quantity kinds only:
inline constexpr struct radian final : named_unit<\"rad\", metre / metre, kind_of<isq::angular_measure>> {} radian;\ninline constexpr struct steradian final : named_unit<\"sr\", square(metre) / square(metre), kind_of<isq::solid_angular_measure>> {} steradian;\ninline constexpr struct bit final : named_unit<\"bit\", one, kind_of<storage_capacity>> {} bit;\nbut still allow the usage of one and its scaled versions for such quantities.
In most libraries, physical constants are implemented as constant (possibly constexpr) quantity values. Such an approach has some disadvantages, often affecting the run time performance and causing a loss of precision.
When dealing with equations involving physical constants, they often occur more than once in an expression. Such a constant may appear both in a numerator and denominator of a quantity equation. As we know from fundamental physics, we can simplify such an expression by striking a constant out of the equation. Supporting such behavior allows a faster runtime performance and often a better precision of the resulting value.
"},{"location":"users_guide/framework_basics/faster_than_lightspeed_constants/#physical-constants-as-units","title":"Physical constants as units","text":"The mp-units library allows and encourages the implementation of physical constants as regular units. With that, the constant's value is handled at compile-time, and under favorable circumstances, it can be simplified in the same way as all other repeated units do. If it is not simplified, the value is stored in a type, and the expensive multiplication or division operations can be delayed in time until a user selects a specific unit to represent/print the data.
Such a feature often also allows using simpler or faster representation types in the equation. For example, instead of always having to multiply a small integral value with a big floating-point constant number, we can just use the integral type all the way. Only in case a constant will not simplify in the equation, and the user will require a specific unit, such a multiplication will be lazily invoked, and the representation type will need to be expanded to facilitate that. With that, addition, subtractions, multiplications, and divisions will always be the fastest - compiled away or done in out-of-order execution.
To benefit from all of the above, in the mp-units library, SI defining and other constants are implemented as units in the following way:
namespace si {\n\nnamespace si2019 {\n\ninline constexpr struct speed_of_light_in_vacuum final :\n named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\n\n} // namespace si2019\n\ninline constexpr struct magnetic_constant final :\n named_unit<{u8\"\u03bc\u2080\", \"u_0\"}, mag<4> * mag_pi * mag_power<10, -7> * henry / metre> {} magnetic_constant;\n\n} // namespace mp_units::si\nWith the above definitions, we can calculate vacuum permittivity as:
constexpr auto permeability_of_vacuum = 1. * si::magnetic_constant;\nconstexpr auto speed_of_light_in_vacuum = 1 * si::si2019::speed_of_light_in_vacuum;\n\nQuantityOf<isq::permittivity_of_vacuum> auto q = 1 / (permeability_of_vacuum * pow<2>(speed_of_light_in_vacuum));\n\nstd::println(\"permittivity of vacuum = {} = {::N[.3e]}\", q, q.in(F / m));\nThe above first prints the following:
permittivity of vacuum = 1 \u03bc\u2080\u207b\u00b9 c\u207b\u00b2 = 8.854e-12 F/m\nAs we can clearly see, all the calculations above were just about multiplying and dividing the number 1 with the rest of the information provided as a compile-time type. Only when a user wants a specific SI unit as a result, the unit ratios are lazily resolved.
Another similar example can be an equation for total energy:
QuantityOf<isq::mechanical_energy> auto total_energy(QuantityOf<isq::momentum> auto p,\n QuantityOf<isq::mass> auto m,\n QuantityOf<isq::speed> auto c)\n{\n return isq::mechanical_energy(sqrt(pow<2>(p * c) + pow<2>(m * pow<2>(c))));\n}\nconstexpr auto GeV = si::giga<si::electronvolt>;\nconstexpr QuantityOf<isq::speed> auto c = 1. * si::si2019::speed_of_light_in_vacuum;\nconstexpr auto c2 = pow<2>(c);\n\nconst auto p1 = isq::momentum(4. * GeV / c);\nconst QuantityOf<isq::mass> auto m1 = 3. * GeV / c2;\nconst auto E = total_energy(p1, m1, c);\n\nstd::cout << \"in `GeV` and `c`:\\n\"\n << \"p = \" << p1 << \"\\n\"\n << \"m = \" << m1 << \"\\n\"\n << \"E = \" << E << \"\\n\";\n\nconst auto p2 = p1.in(GeV / (m / s));\nconst auto m2 = m1.in(GeV / pow<2>(m / s));\nconst auto E2 = total_energy(p2, m2, c).in(GeV);\n\nstd::cout << \"\\nin `GeV`:\\n\"\n << \"p = \" << p2 << \"\\n\"\n << \"m = \" << m2 << \"\\n\"\n << \"E = \" << E2 << \"\\n\";\n\nconst auto p3 = p1.in(kg * m / s);\nconst auto m3 = m1.in(kg);\nconst auto E3 = total_energy(p3, m3, c).in(J);\n\nstd::cout << \"\\nin SI base units:\\n\"\n << \"p = \" << p3 << \"\\n\"\n << \"m = \" << m3 << \"\\n\"\n << \"E = \" << E3 << \"\\n\";\nThe above prints the following:
in `GeV` and `c`:\np = 4 GeV/c\nm = 3 GeV/c\u00b2\nE = 5 GeV\n\nin `GeV`:\np = 1.33426e-08 GeV s/m\nm = 3.33795e-17 GeV s\u00b2/m\u00b2\nE = 5 GeV\n\nin SI base units:\np = 2.13771e-18 kg m/s\nm = 5.34799e-27 kg\nE = 8.01088e-10 J\nUsing a concrete unit in the interface often makes a lot of sense. It is especially useful if we store the data internally in the object. In such a case, we have to select a specific unit anyway.
For example, let's consider a simple storage tank:
class StorageTank {\n quantity<horizontal_area[m2]> base_;\n quantity<isq::height[m]> height_;\n quantity<isq::mass_density[kg / m3]> density_ = air_density;\npublic:\n constexpr StorageTank(const quantity<horizontal_area[m2]>& base, const quantity<isq::height[m]>& height) :\n base_(base), height_(height)\n {\n }\n\n // ...\n};\nAs the quantities provided in the function's interface are then stored in the class, there is probably no sense in using generic interfaces here.
"},{"location":"users_guide/framework_basics/generic_interfaces/#the-issues-with-unit-specific-interfaces","title":"The issues with unit-specific interfaces","text":"However, in many cases, using a specific unit in the interface is counterproductive. Let's consider the following function:
quantity<km / h> avg_speed(quantity<km> distance, quantity<h> duration)\n{\n return distance / duration;\n}\nEverything seems fine for now. It also works great if we call it with:
quantity<km / h> s1 = avg_speed(220 * km, 2 * h);\nHowever, if the user starts doing the following:
quantity<mi / h> s2 = avg_speed(140 * mi, 2 * h);\nquantity<m / s> s3 = avg_speed(20 * m, 2 * s);\nsome issues start to be clearly visible:
km/h, another potentially expensive multiplication/division operations must be performed to convert the resulting quantity into a unit being the derived unit of the initial function's arguments.We have to use a floating-point representation type (the quantity class template by default uses double as a representation type) which is considered value-preserving. Trying to use an integral type in this scenario will work only for s1, while s2 and s3 will fail to compile. Failing to compile is a good thing here as the library tries to prevent the user from doing a clearly wrong thing. To make the code compile, the user needs to use dedicated value_cast or force_in like this:
quantity<isq::speed[mi / h]> s2 = avg_speed(value_cast<km>(140 * mi), 2 * h);\nquantity<isq::speed[m / s]> s3 = avg_speed((20 * m).force_in(km), (2 * s).force_in(h));\nbut the above will obviously provide an incorrect behavior (e.g., division by 0 in the evaluation of s3).
A naive solution here would be to implement the function as an unconstrained function template:
auto avg_speed(auto distance, auto duration)\n{\n return distance / duration;\n}\nBeware, this is not a good solution. The above code is too generic. Such a function template accepts everything:
double arguments,std::vector and std::lock_guard will be accepted as well (of course, this will fail in the instantiation of a function's body later in the compilation process).Note
The usage of auto instead of a function parameter type is a C++20 feature. It makes such a code a function template where the type of such a parameter will be deduced during the template instantiation process from the argument type passed by the user.
Much better generic code can be implemented using basic concepts provided with the library:
Original template notationThe shorthand notationTerse notationtemplate<typename Distance, typename Duration>\n requires QuantityOf<Distance, isq::length> && QuantityOf<Duration, isq::time>\nauto avg_speed(Distance distance, Duration duration)\n{\n return isq::speed(distance / duration);\n}\ntemplate<QuantityOf<isq::length> Distance, QuantityOf<isq::time> Duration>\nauto avg_speed(Distance distance, Duration duration)\n{\n return isq::speed(distance / duration);\n}\nauto avg_speed(QuantityOf<isq::length> auto distance,\n QuantityOf<isq::time> auto duration)\n{\n return isq::speed(distance / duration);\n}\nThis explicitly states that the arguments passed by the user must not only satisfy a Quantity concept, but also their quantity specification must be implicitly convertible to isq::length and isq::time accordingly. This no longer leaves room for error while still allowing the compiler to generate the most efficient code.
Tip
Please note that now it is safe just to use integral types all the way which again improves the runtime performance as the multiplication/division operations are often faster on the integral rather than floating-point types.
"},{"location":"users_guide/framework_basics/generic_interfaces/#constraining-function-template-return-type","title":"Constraining function template return type","text":"The above function template resolves all of the issues described before. However, we can do even better here by additionally constraining the return type:
QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto distance,\n QuantityOf<isq::time> auto duration)\n{\n return isq::speed(distance / duration);\n}\nDoing so has two important benefits:
auto, which does not provide any hint about the thing being returned there.If we know precisely what the function does in its internals and if we know the exact argument types passed to such a function, we often know the exact type that will be returned from its invocation.
However, if we care about performance, we should often use the generic interfaces described in this chapter. A side effect is that we sometimes are unsure about the return type. Even if we know it today, it might change a week from now due to some code refactoring.
In such cases, we can again use auto to denote the type:
auto s1 = avg_speed(220 * km, 2 * h);\nauto s2 = avg_speed(140 * mi, 2 * h);\nauto s3 = avg_speed(20 * m, 2 * s);\nor benefit from CTAD:
quantity s1 = avg_speed(220 * km, 2 * h);\nquantity s2 = avg_speed(140 * mi, 2 * h);\nquantity s3 = avg_speed(20 * m, 2 * s);\nIn both cases, it is probably OK to do so as the avg_speed function name explicitly provides the information on what to expect as a result.
In other scenarios where the returned quantity type is not so obvious, it is again helpful to constrain the type with a concept like so:
QuantityOf<isq::speed> auto s1 = avg_speed(220 * km, 2 * h);\nQuantityOf<isq::speed> auto s2 = avg_speed(140 * mi, 2 * h);\nQuantityOf<isq::speed> auto s3 = avg_speed(20 * m, 2 * s);\nThe above explicitly provides additional information about the quantity we are dealing with in the code, and it serves as a unit test checking if the \"thing\" returned from a function is actually what we expected here.
Note
The QuantityOf and QuantityPointOf concepts are probably the most useful, but there are a few more to play with. A list of all the concepts can be found in the Basic Concepts chapter.
The mp-units library decided to use a rather unusual pattern to define entities. Here is how we define metre and second SI base units:
inline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\ninline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\nPlease note that the above reuses the same identifier for a type and its value. The rationale behind this is that:
Important
To improve compiler errors' readability and make it easier to correlate them with a user's written code, a new idiom in the library is to use the same identifier for a type and its instance.
Also, to prevent possible issues in compile-time logic, all of the library's entities must be marked final. This prevents the users to derive own strong types from them, which would prevent expression template simplification of equivalent entities.
Let's look again at the above units definitions. Another important point to notice is that all the types describing entities in the library are short, nicely named identifiers that derive from longer, more verbose class template instantiations. This is really important to improve the user experience while debugging the program or analyzing the compilation error.
Note
Such a practice is rare in the industry. Some popular C++ physical units libraries generate enormously long error messages where even only the first line failed to fit on a slide with a tiny font.
"},{"location":"users_guide/framework_basics/interface_introduction/#entities-composability","title":"Entities composability","text":"Many physical units libraries (in C++ or any other programming language) assign strong types to library entities (e.g., derived units). While metre_per_second as a type may not look too scary, consider, for example, units of angular momentum. If we followed this path, its coherent unit would look like kilogram_metre_sq_per_second. Now, consider how many scaled versions of this unit you would predefine in the library to ensure that all users are happy with your choice? How expensive would it be from the implementation point of view? What about potential future standardization efforts?
This is why in mp-units, we put a strong requirement to make everything as composable as possible. For example, to create a quantity with a unit of speed, one may write:
quantity<si::metre / si::second> q;\nIn case we use such a unit often and would prefer to have a handy helper for it, we can always do something like this:
constexpr auto metre_per_second = si::metre / si::second;\nquantity<metre_per_second> q;\nor choose any shorter identifier of our choice.
Coming back to the angular momentum case, thanks to the composability of units, a user can create such a quantity in the following way:
using namespace mp_units::si::unit_symbols;\nauto q = la_vector{1, 2, 3} * isq::angular_momentum[kg * m2 / s];\nIt is a much better solution. It is terse and easy to understand. Please also notice how easy it is to obtain any scaled version of such a unit (e.g., mg * square(mm) / min) without having to introduce hundreds of types to predefine them.
The mp-units library is based on C++20, significantly improving user experience. One of such improvements is the usage of value-based equations.
As we have learned above, the entities are being used as values in the code, and they compose. Moreover, derived entities can be defined in the library using such value-based equations. This is a huge improvement compared to what we can find in other physical units libraries or what we have to deal with when we want to write some equations for std::ratio.
For example, below are a few definitions of the SI derived units showing the power of C++20 extensions to Non-Type Template Parameters, which allow us to directly pass a result of the value-based unit equation to a class template definition:
inline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\ninline constexpr struct pascal final : named_unit<\"Pa\", newton / square(metre)> {} pascal;\ninline constexpr struct joule final : named_unit<\"J\", newton * metre> {} joule;\nThe previous chapter provided a rationale for not having predefined types for derived entities. In many libraries, such an approach results in long and unreadable compilation errors, as framework-generated types are typically far from being easy to read and understand.
The mp-units library greatly improves the user experience by extensively using expression templates. Such expressions are used consistently throughout the entire library to describe the results of:
derived_dimension<> class templatederived_quantity_spec<> class templatederived_unit<> class templateFor example, if we take the above-defined base units and put the results of their division into the quantity class template like this:
quantity<metre / second> q;\nwe will observe the following type in the debugger
(gdb) ptype q\ntype = class mp_units::quantity<mp_units::derived_unit<metre, mp_units::per<second>>(), double> [with Rep = double] {\nThe same type identifier will be visible in the compilation error (in case it happens).
Important
Expressions templates are extensively used throughout the library to improve the readability of the resulting types.
"},{"location":"users_guide/framework_basics/interface_introduction/#identities","title":"Identities","text":"As mentioned above, equations can be performed on dimensions, quantities, and units. Each such domain must introduce an identity object that can be used in the resulting expressions. Here is the list of identities used in the library:
Domain Concept IdentityDimension dimension_one QuantitySpec dimensionless Unit one In the equations, a user can explicitly refer to an identity object. For example:
constexpr auto my_unit = one / second;\nNote
Another way to achieve the same result is to call an inverse() function:
constexpr auto my_unit = inverse(second);\nBoth cases will result in the same expression template being generated and put into the wrapper class template.
"},{"location":"users_guide/framework_basics/interface_introduction/#supported-operations-and-their-results","title":"Supported operations and their results","text":"There are only a few operations that one can do on such entities, and the result of each of them has its unique representation in the library:
Operation Resulting template expression argumentsA * B A, B B * A A, B A * A power<A, 2> {identity} * A A A * {identity} A A / B A, per<B> A / A {identity} A / {identity} A {identity} / A {identity}, per<A> pow<2>(A) power<A, 2> pow<2>({identity}) {identity} sqrt(A) or pow<1, 2>(A) power<A, 1, 2> sqrt({identity}) or pow<1, 2>({identity}) {identity}"},{"location":"users_guide/framework_basics/interface_introduction/#simplifying-the-resulting-expression-templates","title":"Simplifying the resulting expression templates","text":"To limit the length and improve the readability of generated types, there are many rules to simplify the resulting expression template.
Ordering
The resulting comma-separated arguments of multiplication are always sorted according to a specific predicate. This is why:
static_assert(A * B == B * A);\nstatic_assert(std::is_same_v<decltype(A * B), decltype(B * A)>);\nThis is probably the most important of all the steps, as it allows comparing types and enables the rest of the simplification rules.
Aggregation
In case two of the same identifiers are found next to each other on the argument list they will be aggregated in one entry:
Before AfterA, A power<A, 2> A, power<A, 2> power<A, 3> power<A, 1, 2>, power<A, 2> power<A, 5, 2> power<A, 1, 2>, power<A, 1, 2> A Simplification
In case two of the same identifiers are found in the numerator and denominator argument lists; they are being simplified into one entry:
Before AfterA, per<A> {identity} power<A, 2>, per<A> A power<A, 3>, per<A> power<A, 2> A, per<power<A, 2>> {identity}, per<A> It is important to notice here that only the elements with exactly the same type are being simplified. This means that, for example, m/m results in one, but km/m will not be simplified. The resulting derived unit will preserve both symbols and their relative magnitude. This allows us to properly print symbols of some units or constants that require such behavior. For example, the Hubble constant is expressed in km\u22c5s\u207b\u00b9\u22c5Mpc\u207b\u00b9, where both km and Mpc are units of length.
Also, to prevent possible issues in compile-time logic, all of the library's entities must be marked final. This prevents the users to derive own strong types from them, which would prevent expression template simplification of equivalent entities.
Repacking
In case an expression uses two results of other operations, the components of its arguments are repacked into one resulting type and simplified there.
For example, assuming:
constexpr auto X = A / B;\nthen:
Operation Resulting template expression argumentsX * B A X * A power<A, 2>, per<B> X * X power<A, 2>, per<power<B, 2>> X / X {identity} X / A {identity}, per<B> X / B A, per<power<B, 2>> Thanks to all of the features described above, a user may write the code like this one:
using namespace mp_units::si::unit_symbols;\nquantity speed = 60. * isq::speed[km / h];\nquantity duration = 8 * s;\nquantity acceleration = speed / duration;\nstd::cout << \"acceleration: \" << acceleration << \" (\" << acceleration.in(m / s2) << \")\\n\";\nThe acceleration quantity, being the result of the above code, has the following type (after stripping the mp_units namespace for brevity):
quantity<reference<derived_quantity_spec<isq::speed, per<isq::time>>{}, derived_unit<si::kilo_<si::metre{}>, per<non_si::hour, si::second>>{}>{}, int>\nand the text output presents:
acceleration: 7.5 km h\u207b\u00b9 s\u207b\u00b9 (2.08333 m/s\u00b2)\nquantity is a numeric wrapper","text":"If we think about it, the quantity class template is just a \"smart\" numeric wrapper. It exposes properly constrained set of arithmetic operations on one or two operands.
Important: quantity propagates the underlying interface
Every single arithmetic operator is exposed by the quantity class template only if the underlying representation type provides it as well, and when its implementation has proper semantics (e.g., returns a reasonable type).
For example, in the following code, -a will compile only if MyInt exposes such an operation as well:
quantity a = MyInt{42} * m;\nquantity b = -a;\nAssuming that:
q is our quantity,qi is a quantity implicitly convertible to q,qk is a quantity of the same kind as q,q1 is a quantity of dimension_one with the unit one,qq is any other quantity,number is a value of a type \"compatible\" with q's representation type,here is the list of all the supported operators:
+q-q++qq++--qq--q += qiq -= qiq %= qiq *= numberq *= q1q /= numberq /= q1q + qkq - qkq % qkq * qqq * numbernumber * qq / qqq / numbernumber / qq == qkq <=> qkAs we can see, there are plenty of operations one can do on a value of a quantity type. As most of them are obvious, in the following chapters, we will discuss only the most important or non-trivial aspects of quantity arithmetics.
Quantities can easily be added or subtracted from each other:
static_assert(1 * m + 1 * m == 2 * m);\nstatic_assert(2 * m - 1 * m == 1 * m);\nstatic_assert(isq::height(1 * m) + isq::height(1 * m) == isq::height(2 * m));\nstatic_assert(isq::height(2 * m) - isq::height(1 * m) == isq::height(1 * m));\nThe above uses the same types for LHS, RHS, and the result, but in general, we can add, subtract, or compare the values of any quantity type as long as both quantities are of the same kind. The result of such an operation will be the common type of the arguments:
static_assert(1 * km + 1.5 * m == 1001.5 * m);\nstatic_assert(isq::height(1 * m) + isq::width(1 * m) == isq::length(2 * m));\nstatic_assert(isq::height(2 * m) - isq::distance(0.5 * m) == 1.5 * m);\nstatic_assert(isq::radius(1 * m) - 0.5 * m == isq::radius(0.5 * m));\nNote
Please note that for the compound assignment operators, both arguments have to either be of the same type or the RHS has to be implicitly convertible to the LHS, as the type of LHS is always the result of such an operation:
static_assert((1 * m += 1 * km) == 1001 * m);\nstatic_assert((isq::height(1.5 * m) -= 1 * m) == isq::height(0.5 * m));\nIf we break those rules, the following code will not compile:
static_assert((1 * m -= 0.5 * m) == 0.5 * m); // Compile-time error(1)\nstatic_assert((1 * km += 1 * m) == 1001 * m); // Compile-time error(2)\nstatic_assert((isq::height(1 * m) += isq::length(1 * m)) == 2 * m); // Compile-time error(3)\nMultiplying or dividing a quantity by a number does not change its quantity type or unit. However, its representation type may change. For example:
static_assert(isq::height(3 * m) * 0.5 == isq::height(1.5 * m));\nNote
Unless we use a compound assignment operator, in which case truncating operations are again not allowed:
static_assert((isq::height(3 * m) *= 0.5) == isq::height(1.5 * m)); // Compile-time error(1)\nHowever, suppose we multiply or divide quantities of the same or different types or we divide a raw number by a quantity. In that case, we most probably will end up in a quantity of yet another type:
static_assert(120 * km / (2 * h) == 60 * km / h);\nstatic_assert(isq::width(2 * m) * isq::length(2 * m) == isq::area(4 * m2));\nstatic_assert(50 / isq::time(1 * s) == isq::frequency(50 * Hz));\nNote
An exception from the above rule happens when one of the arguments is a dimensionless quantity. If we multiply or divide by such a quantity, the quantity type will not change. If such a quantity has a unit one, also the unit of a quantity will not change:
static_assert(120 * m / (2 * one) == 60 * m);\nAn interesting special case happens when we divide the same quantity kinds or multiply a quantity by its inverted type. In such a case, we end up with a dimensionless quantity.
static_assert(isq::height(4 * m) / isq::width(2 * m) == 2 * one); // (1)!\nstatic_assert(5 * h / (120 * min) == 0 * one); // (2)!\nstatic_assert(5. * h / (120 * min) == 2.5 * one);\nisq::height / isq::width, which is a quantity of the dimensionless kind.0 * dimensionless[h / min]. To be consistent with the division of different quantity types, we do not convert quantity values to a common unit before the division.Important: Beware of integral division
The physical units library can't do any runtime branching logic for the division operator. All logic must be done at compile-time when the actual values are unknown, and the quantity types can't change at runtime.
If we expect 120 * km / (2 * h) to return 60 km / h, we have to agree with the fact that 5 * km / (24 * h) returns 0 km/h. We can't do a range check at runtime to dynamically adjust scales and types based on the values of provided function arguments.
This is why we often prefer floating-point representation types when dealing with units. Some popular physical units libraries even forbid integer division at all.
"},{"location":"users_guide/framework_basics/quantity_arithmetics/#modulo","title":"Modulo","text":"Now that we know how addition, subtraction, multiplication, and division work, it is time to discuss modulo. What would we expect to be returned from the following quantity equation?
auto q = 5 * h % (120 * min);\nMost of us would probably expect to see 1 h or 60 min as a result. And this is where the problems start.
C++ language defines its / and % operators with the quotient-remainder theorem:
q = a / b;\nr = a % b;\nq * b + r == a;\nThe important property of the modulo operation is that it only works for integral representation types (it is undefined what modulo for floating-point types means). However, as we saw in the previous chapter, integral types are tricky because they often truncate the value.
From the quotient-remainder theorem, the result of modulo operation is r = a - q * b. Let's see what we get from such a quantity equation on integral representation types:
const quantity a = 5 * h;\nconst quantity b = 120 * min;\nconst quantity q = a / b;\nconst quantity r = a - q * b;\n\nstd::cout << \"reminder: \" << r << \"\\n\";\nThe above code outputs:
reminder: 5 h\nAnd now, a tough question needs an answer. Do we really want modulo operation on physical units to be consistent with the quotient-remainder theorem and return 5 h for 5 * h % (120 * min)?
This is exactly why we decided not to follow this hugely surprising path in the mp-units library. The selected approach was also consistent with the feedback from the C++ experts. For example, this is what Richard Smith said about this issue:
Richard Smith
I think the quotient-remainder property is a less important motivation here than other factors -- the constraints on % and / are quite different, so they lack the inherent connection they have for integers. In particular, I would expect that A / B works for all quantities A and B, whereas A % B is only meaningful when A and B have the same dimension. It seems like a nice-to-have for the property to apply in the case where both / and % are defined, but internal consistency of / across all cases seems much more important to me.
I would expect 61 min % 1 h to be 1 min, and 1 h % 59 min to also be 1 min, so my intuition tells me that the result type of A % B, where A and B have the same dimension, should have the smaller unit of A and B (and if the smaller one doesn't divide the larger one, we should either use the gcd / std::common_type of the units of A and B or perhaps just produce an error). I think any other behavior for % is hard to defend.
On the other hand, for division it seems to me that the choice of unit should probably not affect the result, and so if we want that 5 mm / 120 min = 0 mm/min, then 5 h / 120 min == 0 hc (where hc is a dimensionless \"hexaconta\", or 60x, unit). I don't like the idea of taking SI base units into account; that seems arbitrary and like it would do the wrong thing as often as it does the right thing, especially when the units have a multiplier that is very large or small. We could special-case the situation of a dimensionless quantity, but that could lead to problematic overflow pretty easily: a calculation such as 10 s * 5 GHz * 2 uW would overflow an int if it produces a dimensionless quantity for 10 s * 5 GHz, but it could equally produce 50 G * 2 uW = 100 kW without any overflow, and presumably would if the terms were merely reordered.
If people want to use integer-valued quantities, I think it's fundamental that you need to know what the units of the result of an operation will be, and take that into account in how you express computations; the simplest rule for heterogeneous operators like * or / seems to be that the units of the result are determined by applying the operator to the units of the operands -- and for homogeneous operators like + or %, it seems like the only reasonable option is that you get the std::common_type of the units of the operands.
To summarize, the modulo operation on physical units has more in common with addition and division operators than with the quotient-remainder theorem. To avoid surprising results, the operation uses a common unit to do the calculation and provide its result:
static_assert(5 * h / (120 * min) == 0 * one);\nstatic_assert(5 * h % (120 * min) == 60 * min);\nstatic_assert(61 * min % (1 * h) == 1 * min);\nstatic_assert(1 * h % (59 * min) == 1 * min);\nIn our code, we often want to compare the value of a quantity against zero. For example, we do it every time we want to ensure that we deal with a non-zero or positive value.
We could implement such checks in the following way:
if (q1 / q2 != 0 * m / s)\n // ...\nThe above would work (assuming we are dealing with the quantity of speed) but could be suboptimal if the result of q1 / q2 is not expressed in m / s. To eliminate the need for conversion, we need to write:
if (auto q = q1 / q2; q != q.zero())\n // ...\nbut that is a bit inconvenient, and inexperienced users could be unaware of this technique and its reasons.
For the above reasons, the library provides dedicated interfaces to compare against zero that follow the naming convention of named comparison functions in the C++ Standard Library. The mp-units/compare.h header file exposes the following functions:
is_eq_zerois_neq_zerois_lt_zerois_gt_zerois_lteq_zerois_gteq_zeroThanks to them, to save typing and not pay for unneeded conversions, our check could be implemented as follows:
if (is_neq_zero(q1 / q2))\n // ...\nTip
Those functions will work with any type T that exposes zero() member function returning something comparable to T. Thanks to that, we can use them not only with quantities but also with std::chrono::duration or any other type that exposes such an interface.
This chapter scopes only on the quantity type's operators. However, there are many named math functions taking quantities as arguments. Those can be found in the mp-units/math.h header file. Among others, we can find there the following:
pow(), sqrt(), cbrt(),exp(),abs(),epsilon(),fma(), fmod(), remainder(),isfinite(), isinf(), isnan(),floor(), ceil(), round(),inverse(),hypot(),sin(), cos(), tan(),asin(), acos(), atan(), atan2().In the library, we can also find mp-units/random.h header file with all the pseudo-random number generators working on quantity types.
"},{"location":"users_guide/framework_basics/simple_and_typed_quantities/","title":"Simple and Typed Quantities","text":"ISO defines a quantity as:
Quote
property of a phenomenon, body, or substance, where the property has a magnitude that can be expressed as a number and a reference
After that, it says:
Quote
A reference can be a measurement unit, a measurement procedure, a reference material, or a combination of such.
"},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#quantity-class-template","title":"quantity class template","text":"In the mp-units library, a quantity is represented with the following class template:
template<Reference auto R,\n RepresentationOf<get_quantity_spec(R).character> Rep = double>\nclass quantity;\nThe concept Reference is satisfied by a type that provides all the domain-specific metadata describing a quantity (besides the representation type and its value). Such a type can be either:
si::metre, m / s),Important
All units in the SI system have an associated quantity type.
A reference type is implicitly created as a result of the following expression:
constexpr auto ref = isq::length[m];\nThe above example results in the following type reference<isq::length(), si::metre()> being instantiated.
As we have two alternative options that satisfy the Reference concept in the mp-units library, we also have two modes of dealing with quantities.
The simple mode might be preferred by many developers. It is all about units. Quantities using this mode have shorter type identifiers, resulting in easier-to-understand error messages and better debugging experience.
Here is a simple example showing how to deal with such quantities:
C++ modulesHeader files#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n quantity<si::second> time)\n{\n return dist / time;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n\n const quantity distance = 110 * km;\n const quantity duration = 2 * h;\n const quantity speed = avg_speed(distance, duration);\n\n std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n distance, duration, speed, speed.in(km / h));\n}\n#include <mp-units/format.h>\n#include <mp-units/systems/si.h>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n quantity<si::second> time)\n{\n return dist / time;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n\n const quantity distance = 110 * km;\n const quantity duration = 2 * h;\n const quantity speed = avg_speed(distance, duration);\n\n std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n distance, duration, speed, speed.in(km / h));\n}\nThe code above prints:
A car driving 110 km in 2 h has an average speed of 15.28 m/s (55 km/h)\nTry it on Compiler Explorer
"},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#user-provided-unit-wrappers","title":"User-provided unit wrappers","text":"Sometimes it might be awkward to type some derived units:
quantity speed = 60 * km / h;\nIn case such a unit is used a lot in the project, a user can easily provide a nicely named wrapper for it with:
constexpr auto kmph = km / h;\nquantity speed = 60 * kmph;\nIn case a user makes an error in a quantity equation and the result of the calculation will not match the function return type, the compiler will detect such an issue at compile-time.
For example, in case we will make the following error:
constexpr quantity<si::metre / si::second> avg_speed(quantity<si::metre> dist,\n quantity<si::second> time)\n{\n return dist * time; // (1)!\n}\nthe following compilation error message will be provided:
error: no viable conversion from returned value of type\n 'quantity<mp_units::derived_unit<mp_units::si::metre, mp_units::si::second>{{{}}}, [...]>'\n to function return type\n 'quantity<mp_units::derived_unit<mp_units::si::metre, mp_units::per<mp_units::si::second>>{{{}}}, [...]>'\n 10 | return dist * time;\n | ^~~~~~~~~~~\nSimple mode is all about and just about units. In case we care about a specific quantity type, typed quantities should be preferred. With this mode, for example, we can specify if we deal with width, height, or radius and ensure we will not assign one to another by accident.
The previous example can be re-typed using typed quantities in the following way:
C++ modulesHeader files#include <print>\nimport mp_units;\n\nusing namespace mp_units;\n\nconstexpr quantity<isq::speed[si::metre / si::second]> avg_speed(quantity<isq::length[si::metre]> dist,\n quantity<isq::time[si::second]> time)\n{\n return dist / time;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n\n const quantity distance = isq::distance(110 * km);\n const quantity duration = isq::time(2 * h);\n const quantity speed = avg_speed(distance, duration);\n\n std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n distance, duration, speed, speed.in(km / h));\n}\n#include <mp-units/format.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <print>\n\nusing namespace mp_units;\n\nconstexpr quantity<isq::speed[si::metre / si::second]> avg_speed(quantity<isq::length[si::metre]> dist,\n quantity<isq::time[si::second]> time)\n{\n return dist / time;\n}\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n\n const quantity distance = isq::distance(110 * km);\n const quantity duration = isq::time(2 * h);\n const quantity speed = avg_speed(distance, duration);\n\n std::println(\"A car driving {} in {} has an average speed of {::N[.4]} ({::N[.4]})\",\n distance, duration, speed, speed.in(km / h));\n}\nA car driving 110 km in 2 h has an average speed of 15.28 m/s (55 km/h)\nTry it on Compiler Explorer
In case we will accidentally make the same calculation error as before, this time, we will get a bit longer error message, this time also containing information about the quantity type:
error: no viable conversion from returned value of type\n 'quantity<reference<get_quantity_spec(metre{}) * struct time{{{}}}, metre{} * second{{}}>{}, [...]>'\n to function return type\n 'quantity<reference<speed{}, derived_unit<metre, per<second>>{}>{}, [...]>'\n 12 | return dist * time;\n | ^~~~~~~~~~~\nAs we can see above, the compilation error is longer but still relatively easy to understand.
"},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#additional-type-safety-with-typed-quantities","title":"Additional type safety with typed quantities","text":"Based on the previous example, it might seem that typed quantities are not that useful, more to type and provide harder-to-understand error messages. It might be true in some cases, but there are scenarios where they offer additional level of safety.
Let's see another example:
C++ modulesHeader files SimpleTyped#include <numbers>\nimport mp_units;\n\nusing namespace mp_units;\n\nclass StorageTank {\n quantity<square(si::metre)> base_;\n quantity<si::metre> height_;\npublic:\n constexpr StorageTank(const quantity<square(si::metre)>& base,\n const quantity<si::metre>& height) :\n base_(base), height_(height)\n {\n }\n\n // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n constexpr CylindricalStorageTank(const quantity<si::metre>& radius,\n const quantity<si::metre>& height) :\n StorageTank(std::numbers::pi * pow<2>(radius), height)\n {\n }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n constexpr RectangularStorageTank(const quantity<si::metre>& length,\n const quantity<si::metre>& width,\n const quantity<si::metre>& height) :\n StorageTank(length * width, height)\n {\n }\n};\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n auto tank = RectangularStorageTank(1'000 * mm, 500 * mm, 200 * mm);\n // ...\n}\n#include <numbers>\nimport mp_units;\n\nusing namespace mp_units;\n\n// add a custom quantity type of kind isq::length\ninline constexpr struct horizontal_length final :\n quantity_spec<isq::length> {} horizontal_length;\n\n// add a custom derived quantity type of kind isq::area\n// with a constrained quantity equation\ninline constexpr struct horizontal_area final :\n quantity_spec<isq::area, horizontal_length * isq::width> {} horizontal_area;\n\nclass StorageTank {\n quantity<horizontal_area[square(si::metre)]> base_;\n quantity<isq::height[si::metre]> height_;\npublic:\n constexpr StorageTank(const quantity<horizontal_area[square(si::metre)]>& base,\n const quantity<isq::height[si::metre]>& height) :\n base_(base), height_(height)\n {\n }\n\n // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n constexpr CylindricalStorageTank(const quantity<isq::radius[si::metre]>& radius,\n const quantity<isq::height[si::metre]>& height) :\n StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n height)\n {\n }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n constexpr RectangularStorageTank(const quantity<horizontal_length[si::metre]>& length,\n const quantity<isq::width[si::metre]>& width,\n const quantity<isq::height[si::metre]>& height) :\n StorageTank(length * width, height)\n {\n }\n};\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n isq::width(500 * mm),\n isq::height(200 * mm));\n // ...\n}\n#include <mp-units/math.h>\n#include <mp-units/systems/si.h>\n#include <numbers>\n\nusing namespace mp_units;\n\nclass StorageTank {\n quantity<square(si::metre)> base_;\n quantity<si::metre> height_;\npublic:\n constexpr StorageTank(const quantity<square(si::metre)>& base,\n const quantity<si::metre>& height) :\n base_(base), height_(height)\n {\n }\n\n // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n constexpr CylindricalStorageTank(const quantity<si::metre>& radius,\n const quantity<si::metre>& height) :\n StorageTank(std::numbers::pi * pow<2>(radius), height)\n {\n }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n constexpr RectangularStorageTank(const quantity<si::metre>& length,\n const quantity<si::metre>& width,\n const quantity<si::metre>& height) :\n StorageTank(length * width, height)\n {\n }\n};\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n auto tank = RectangularStorageTank(1'000 * mm, 500 * mm, 200 * mm);\n // ...\n}\n#include <mp-units/math.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <numbers>\n\nusing namespace mp_units;\n\n// add a custom quantity type of kind isq::length\ninline constexpr struct horizontal_length final :\n quantity_spec<isq::length> {} horizontal_length;\n\n// add a custom derived quantity type of kind isq::area\n// with a constrained quantity equation\ninline constexpr struct horizontal_area final :\n quantity_spec<isq::area, horizontal_length * isq::width> {} horizontal_area;\n\nclass StorageTank {\n quantity<horizontal_area[square(si::metre)]> base_;\n quantity<isq::height[si::metre]> height_;\npublic:\n constexpr StorageTank(const quantity<horizontal_area[square(si::metre)]>& base,\n const quantity<isq::height[si::metre]>& height) :\n base_(base), height_(height)\n {\n }\n\n // ...\n};\n\nclass CylindricalStorageTank : public StorageTank {\npublic:\n constexpr CylindricalStorageTank(const quantity<isq::radius[si::metre]>& radius,\n const quantity<isq::height[si::metre]>& height) :\n StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n height)\n {\n }\n};\n\nclass RectangularStorageTank : public StorageTank {\npublic:\n constexpr RectangularStorageTank(const quantity<horizontal_length[si::metre]>& length,\n const quantity<isq::width[si::metre]>& width,\n const quantity<isq::height[si::metre]>& height) :\n StorageTank(length * width, height)\n {\n }\n};\n\nint main()\n{\n using namespace mp_units::si::unit_symbols;\n auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n isq::width(500 * mm),\n isq::height(200 * mm));\n // ...\n}\nIn the above example, the highlighted call doesn't look that safe anymore in the case of simple quantities, right? Suppose someone, either by mistake or due to some refactoring, will call the function with an invalid order of arguments. In that case, the program will compile fine but not work as expected.
Let's see what will happen if we reorder the arguments in the case of typed quantities:
auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n isq::height(200 * mm),\n isq::width(500 * mm));\nThis time, a compiler provides the following compilation error:
<source>:53:15: error: no matching constructor for initialization of 'RectangularStorageTank'\n 53 | auto tank = RectangularStorageTank(horizontal_length(1'000 * mm),\n | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n 54 | isq::height(200 * mm),\n | ~~~~~~~~~~~~~~~~~~~~~~\n 55 | isq::width(500 * mm));\n | ~~~~~~~~~~~~~~~~~~~~\n<source>:43:13: note: candidate constructor not viable: no known conversion from\n 'quantity<mp_units::reference<mp_units::isq::height{{{{{}}}}},\n mp_units::si::milli_<mp_units::si::metre{{}}>{{{{}}}}>{}, int>' to\n 'const quantity<reference<width{}, metre{}>{}, (default) double>' for 2nd argument\n 43 | constexpr RectangularStorageTank(const quantity<horizontal_length[m]>& length,\n | ^\n 44 | const quantity<isq::width[m]>& width,\n | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nWhat about derived quantities? In the above example, you probably noticed that we also defined a custom horizontal_area quantity of kind isq::area. This quantity has the unique property of being implicitly constructible only from the result of the multiplication of quantities of horizontal_area and isq::width or the ones that implicitly convert to them.
Based on the above error message, we already know that a quantity of isq::height is not implicitly constructible to the quantity of isq::width. This property is transitively passed to derived quantities using them. If by accident, we will try to create a StorageTank base class in the following way:
class RectangularStorageTank : public StorageTank {\npublic:\n constexpr RectangularStorageTank(const quantity<horizontal_length[m]>& length,\n const quantity<isq::width[m]>& width,\n const quantity<isq::height[m]>& height) :\n StorageTank(length * height, height)\n {\n }\n};\nwe will again get a compilation error message like this one:
error: no matching constructor for initialization of 'StorageTank'\n 46 | StorageTank(length * height, height)\n | ^ ~~~~~~~~~~~~~~~~~~~~~~~\n<source>:22:13: note: candidate constructor not viable: no known conversion from\n 'quantity<mp_units::reference<mp_units::derived_quantity_spec<horizontal_length, mp_units::isq::height>{{}, {{}}},\n mp_units::derived_unit<mp_units::power<mp_units::si::metre, 2>>{{{}}}>{}, [...]>' to\n 'const quantity<reference<horizontal_area{}, derived_unit<power<metre, 2>>{}>{}, [...]>' for 1st argument\n 22 | constexpr StorageTank(const quantity<horizontal_area[m2]>& base,\n | ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\nTip
If you need to use various quantities of the same kind, consider using typed quantities to bring an additional level of safety to your project.
"},{"location":"users_guide/framework_basics/simple_and_typed_quantities/#quantity_cast-to-force-unsafe-conversions","title":"quantity_cast() to force unsafe conversions","text":"Did you notice the quantity_cast() usage in the other child class?
class CylindricalStorageTank : public StorageTank {\npublic:\n constexpr CylindricalStorageTank(const quantity<isq::radius[m]>& radius,\n const quantity<isq::height[m]>& height) :\n StorageTank(quantity_cast<horizontal_area>(std::numbers::pi * pow<2>(radius)),\n height)\n {\n }\n};\nAs isq::radius is not convertible to horizontal_length, the derived quantity of pow<2>(radius) can't be converted to horizontal_area as well. It would be unsafe to allow such a conversion as not all of the circles lie flat on the ground, right?
In such a case, the user has to explicitly force such an unsafe conversion with the help of a quantity_cast(). This function name is easy to spot in code reviews or while searching the project for problems if something goes sideways. In case of unexpected quantities-related issues, this should be the first function to look for.
Tip
Do not overuse quantity_cast(). Use it only when necessary and ensure that the requested conversion is exactly what you need in this case.
We have good news for you if you wonder which mode you should choose for your project. Simple and typed quantity modes can be freely mixed with each other. When you use different quantities of the same kind (e.g., radius, wavelength, altitude, ...), you should probably reach for typed quantities to bring additional safety for those cases. Otherwise, just use simple mode for the remaining quantities. The mp-units library will do its best to protect your project based on the information provided.
Tip
You can easily mix simple and typed quantities in your project.
"},{"location":"users_guide/framework_basics/systems_of_quantities/","title":"Systems of Quantities","text":"The physical units libraries on the market typically only scope on modeling one or more systems of units. However, this is not the only system kind to model. Another, and maybe even more important, system kind is a system of quantities.
Info
Please note that the mp-units is probably the first library on the Open Source market (in any programming language) that models the ISQ with all its definitions provided in ISO 80000. Please provide feedback if something looks odd or could be improved.
"},{"location":"users_guide/framework_basics/systems_of_quantities/#dimension-is-not-enough-to-describe-a-quantity","title":"Dimension is not enough to describe a quantity","text":"Most of the products on the market are aware of physical dimensions. However, a dimension is not enough to describe a quantity. For example, let's see the following implementation:
class Box {\n area base_;\n length height_;\npublic:\n Box(length l, length w, length h) : base_(l * w), height_(h) {}\n // ...\n};\n\nBox my_box(2 * m, 3 * m, 1 * m);\nHow do you like such an interface? It turns out that in most existing strongly-typed libraries this is often the best we can do
Another typical question many users ask is how to deal with work and torque. Both of those have the same dimension but are different quantities.
A similar issue is related to figuring out what should be the result of:
auto res = 1 * Hz + 1 * Bq + 1 * Bd;\nwhere:
Hz (hertz) - unit of frequencyBq (becquerel) - unit of activityBd (baud) - unit of modulation rateAll of those quantities have the same dimension, namely \\(\\mathsf{T}^{-1}\\), but probably it is not wise to allow adding, subtracting, or comparing them, as they describe vastly different physical properties.
If the above example seems too abstract, let's consider a fuel consumption (fuel volume divided by distance, e.g., 6.7 l/km) and an area. Again, both have the same dimension \\(\\mathsf{L}^{2}\\), but probably it wouldn't be wise to allow adding, subtracting, or comparing a fuel consumption of a car and the area of a football field. Such an operation does not have any physical sense and should fail to compile.
Important
More than one quantity may be defined for the same dimension:
It turns out that the above issues can't be solved correctly without proper modeling of a system of quantities.
"},{"location":"users_guide/framework_basics/systems_of_quantities/#quantities-of-the-same-kind","title":"Quantities of the same kind","text":"ISO 80000-1
The above quotes from ISO 80000 provide answers to all the issues above. Two quantities can't be added, subtracted, or compared unless they belong to the same kind. As frequency, activity, and modulation rate are different kinds, the expression provided above should not compile.
"},{"location":"users_guide/framework_basics/systems_of_quantities/#system-of-quantities-is-not-only-about-kinds","title":"System of quantities is not only about kinds","text":"ISO 80000 specify hundreds of different quantities. There are plenty of different kinds provided and often each kind contains more than one quantity. In fact, it turns out that such quantities form a hierarchy of quantities of the same kind.
For example, here are all quantities of the kind length provided in the ISO 80000:
flowchart TD\n length --- width[width, breadth]\n length --- height[height, depth, altitude]\n width --- thickness\n width --- diameter\n width --- radius\n length --- path_length\n path_length --- distance\n distance --- radial_distance\n length --- wavelength\n length --- position_vector[\"position_vector\\n{vector}\"]\n length --- displacement[\"displacement\\n{vector}\"]\n radius --- radius_of_curvatureEach of the above quantities expresses some kind of length, and each can be measured with si::metre. However, each of them has different properties, usage, and sometimes even requires a different representation type (notice that position_vector and displacement are vector quantities).
Such a hierarchy helps us in defining arithmetics and conversion rules for various quantities of the same kind.
"},{"location":"users_guide/framework_basics/systems_of_quantities/#defining-quantities","title":"Defining quantities","text":"In the mp-units library all the information about the quantity is provided with the quantity_spec class template. In order to define a specific quantity a user should inherit a strong type from such an instantiation.
Tip
Quantity specification definitions benefit from an explicit object parameter added in C++23 to remove the need for CRTP idiom, which significantly simplifies the code. However, as C++23 is far from being mainstream today, a portability macro QUANTITY_SPEC() is provided and used consistently through the library to allow the code to compile with C++20 compilers, thanks to the CRTP usage under the hood.
See more in the C++ compiler support chapter.
For example, here is how the above quantity kind tree can be modeled in the library:
C++23C++20Portableinline constexpr struct length final : quantity_spec<dim_length> {} length;\ninline constexpr struct width final : quantity_spec<length> {} width;\ninline constexpr auto breadth = width;\ninline constexpr struct height final : quantity_spec<length> {} height;\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\ninline constexpr struct thickness final : quantity_spec<width> {} thickness;\ninline constexpr struct diameter final : quantity_spec<width> {} diameter;\ninline constexpr struct radius final : quantity_spec<width> {} radius;\ninline constexpr struct radius_of_curvature final : quantity_spec<radius> {} radius_of_curvature;\ninline constexpr struct path_length final : quantity_spec<length> {} path_length;\ninline constexpr auto arc_length = path_length;\ninline constexpr struct distance final : quantity_spec<path_length> {} distance;\ninline constexpr struct radial_distance final : quantity_spec<distance> {} radial_distance;\ninline constexpr struct wavelength final : quantity_spec<length> {} wavelength;\ninline constexpr struct position_vector final : quantity_spec<length, quantity_character::vector> {} position_vector;\ninline constexpr struct displacement final : quantity_spec<length, quantity_character::vector> {} displacement;\ninline constexpr struct length final : quantity_spec<length, dim_length> {} length;\ninline constexpr struct width final : quantity_spec<width, length> {} width;\ninline constexpr auto breadth = width;\ninline constexpr struct height final : quantity_spec<height, length> {} height;\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\ninline constexpr struct thickness final : quantity_spec<thickness, width> {} thickness;\ninline constexpr struct diameter final : quantity_spec<diameter, width> {} diameter;\ninline constexpr struct radius final : quantity_spec<radius, width> {} radius;\ninline constexpr struct radius_of_curvature final : quantity_spec<radius_of_curvature, radius> {} radius_of_curvature;\ninline constexpr struct path_length final : quantity_spec<path_length, length> {} path_length;\ninline constexpr auto arc_length = path_length;\ninline constexpr struct distance final : quantity_spec<distance, path_length> {} distance;\ninline constexpr struct radial_distance final : quantity_spec<radial_distance, distance> {} radial_distance;\ninline constexpr struct wavelength final : quantity_spec<wavelength, length> {} wavelength;\ninline constexpr struct position_vector final : quantity_spec<position_vector, length, quantity_character::vector> {} position_vector;\ninline constexpr struct displacement final : quantity_spec<displacement, length, quantity_character::vector> {} displacement;\nQUANTITY_SPEC(length, dim_length);\nQUANTITY_SPEC(width, length);\ninline constexpr auto breadth = width;\nQUANTITY_SPEC(height, length);\ninline constexpr auto depth = height;\ninline constexpr auto altitude = height;\nQUANTITY_SPEC(thickness, width);\nQUANTITY_SPEC(diameter, width);\nQUANTITY_SPEC(radius, width);\nQUANTITY_SPEC(radius_of_curvature, radius);\nQUANTITY_SPEC(path_length, length);\ninline constexpr auto arc_length = path_length;\nQUANTITY_SPEC(distance, path_length);\nQUANTITY_SPEC(radial_distance, distance);\nQUANTITY_SPEC(wavelength, length);\nQUANTITY_SPEC(position_vector, length, quantity_character::vector);\nQUANTITY_SPEC(displacement, length, quantity_character::vector);\nNote
More information on how to define a system of quantities can be found in the \"International System of Quantities (ISQ)\" chapter.
"},{"location":"users_guide/framework_basics/systems_of_quantities/#comparing-adding-and-subtracting-quantities","title":"Comparing, adding, and subtracting quantities","text":"ISO 80000 explicitly states that width and height are quantities of the same kind, and as such they:
If we take the above for granted, the only reasonable result of 1 * width + 1 * height is 2 * length, where the result of length is known as a common quantity type. A result of such an equation is always the first common node in a hierarchy tree of the same kind. For example:
static_assert(common_quantity_spec(isq::width, isq::height) == isq::length);\nstatic_assert(common_quantity_spec(isq::thickness, isq::radius) == isq::width);\nstatic_assert(common_quantity_spec(isq::distance, isq::path_length) == isq::path_length);\nBased on the same hierarchy of quantities of kind length, we can define quantity conversion rules.
Implicit conversions
static_assert(implicitly_convertible(isq::width, isq::length));\nstatic_assert(implicitly_convertible(isq::radius, isq::width));\nstatic_assert(implicitly_convertible(isq::radius, isq::length));\nExplicit conversions
static_assert(!implicitly_convertible(isq::length, isq::width));\nstatic_assert(!implicitly_convertible(isq::width, isq::radius));\nstatic_assert(!implicitly_convertible(isq::length, isq::radius));\nstatic_assert(explicitly_convertible(isq::length, isq::width));\nstatic_assert(explicitly_convertible(isq::width, isq::radius));\nstatic_assert(explicitly_convertible(isq::length, isq::radius));\nExplicit casts
static_assert(!implicitly_convertible(isq::height, isq::width));\nstatic_assert(!explicitly_convertible(isq::height, isq::width));\nstatic_assert(castable(isq::height, isq::width));\nNo conversion
static_assert(!implicitly_convertible(isq::time, isq::length));\nstatic_assert(!explicitly_convertible(isq::time, isq::length));\nstatic_assert(!castable(isq::time, isq::length));\nDerived quantity equations often do not automatically form a hierarchy tree. This is why it is sometimes not obvious what such a tree should look like. Also, ISO explicitly states:
ISO/IEC Guide 99
The division of \u2018quantity\u2019 according to \u2018kind of quantity\u2019 is, to some extent, arbitrary.
The below presents some arbitrary hierarchy of derived quantities of kind energy:
flowchart TD\n energy[\"energy\\n(mass * length<sup>2</sup> / time<sup>2</sup>)\"]\n energy --- mechanical_energy\n mechanical_energy --- potential_energy\n potential_energy --- gravitational_potential_energy[\"gravitational_potential_energy\\n(mass * acceleration_of_free_fall * height)\"]\n potential_energy --- elastic_potential_energy[\"elastic_potential_energy\\n(spring_constant * amount_of_compression<sup>2</sup>)\"]\n mechanical_energy --- kinetic_energy[\"kinetic_energy\\n(mass * speed<sup>2</sup>)\"]\n energy --- enthalpy\n enthalpy --- internal_energy[internal_energy, thermodynamic_energy]\n internal_energy --- Helmholtz_energy[Helmholtz_energy, Helmholtz_function]\n enthalpy --- Gibbs_energy[Gibbs_energy, Gibbs_function]\n energy --- active_energyNotice, that even though all of those quantities have the same dimension and can be expressed in the same units, they have different quantity equations that can be used to create them implicitly:
energy is the most generic one and thus can be created from base quantities of mass, length, and time. As those are also the roots of quantities of their kinds and all other quantities from their trees are implicitly convertible to them (we agreed on that \"every width is a length\" already), it means that an energy can be implicitly constructed from any quantity of mass, length, and time:
static_assert(implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time), isq::energy));\nstatic_assert(implicitly_convertible(isq::mass * pow<2>(isq::height) / pow<2>(isq::time), isq::energy));\nmechanical energy is a more \"specialized\" quantity than energy (not every energy is a mechanical energy). It is why an explicit cast is needed to convert from either energy or the results of its quantity equation:
static_assert(!implicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::energy, isq::mechanical_energy));\nstatic_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n isq::mechanical_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n isq::mechanical_energy));\ngravitational potential energy is not only even more specialized one but additionally, it is special in a way that it provides its own \"constrained\" quantity equation. Maybe not every mass * pow<2>(length) / pow<2>(time) is a gravitational potential energy, but every mass * acceleration_of_free_fall * height is.
static_assert(!implicitly_convertible(isq::energy, gravitational_potential_energy));\nstatic_assert(explicitly_convertible(isq::energy, gravitational_potential_energy));\nstatic_assert(!implicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n gravitational_potential_energy));\nstatic_assert(explicitly_convertible(isq::mass * pow<2>(isq::length) / pow<2>(isq::time),\n gravitational_potential_energy));\nstatic_assert(implicitly_convertible(isq::mass * isq::acceleration_of_free_fall * isq::height,\n gravitational_potential_energy));\nIn the physical units library, we also need an abstraction describing an entire family of quantities of the same kind. Such quantities have not only the same dimension but also can be expressed in the same units.
To annotate a quantity to represent its kind (and not just a hierarchy tree's root quantity) we introduced a kind_of<> specifier. For example, to express any quantity of length, we need to type kind_of<isq::length>.
Important
isq::length and kind_of<isq::length> are two different things.
Such an entity behaves as any quantity of its kind. This means that it is implicitly convertible to any quantity in a tree.
static_assert(!implicitly_convertible(isq::length, isq::height));\nstatic_assert(implicitly_convertible(kind_of<isq::length>, isq::height));\nAdditionally, the result of operations on quantity kinds is also a quantity kind:
static_assert(same_type<kind_of<isq::length> / kind_of<isq::time>, kind_of<isq::length / isq::time>>);\nHowever, if at least one equation's operand is not a quantity kind, the result becomes a \"strong\" quantity where all the kinds are converted to the hierarchy tree's root quantities:
static_assert(!same_type<kind_of<isq::length> / isq::time, kind_of<isq::length / isq::time>>);\nstatic_assert(same_type<kind_of<isq::length> / isq::time, isq::length / isq::time>);\nInfo
Only a root quantity from the hierarchy tree or the one marked with is_kind specifier in the quantity_spec definition can be put as a template parameter to the kind_of specifier. For example, kind_of<isq::width> will fail to compile. However, we can call get_kind(q) to obtain a kind of any quantity:
static_assert(get_kind(isq::width) == kind_of<isq::length>);\nModeling a system of units is probably the most important feature and a selling point of every physical units library. Thanks to that, the library can protect users from performing invalid operations on quantities and provide automated conversion factors between various compatible units.
Probably all the libraries in the wild model the SI and many of them provide support for additional units belonging to various other systems (e.g., imperial, cgs, etc).
"},{"location":"users_guide/framework_basics/systems_of_units/#systems-of-units-are-based-on-systems-of-quantities","title":"Systems of Units are based on Systems of Quantities","text":"Systems of quantities specify a set of quantities and equations relating to those quantities. Those equations do not take any unit or a numerical representation into account at all. To create a quantity, we need to add those missing pieces of information. This is where a system of units kicks in.
The SI is explicitly stated to be based on the ISQ. Among others, it defines 7 base units, one for each base quantity. In the mp-units this is expressed by associating a quantity kind (that we discussed in detail in the previous chapter) with a unit that is used to express it:
inline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\nImportant
The kind_of<isq::length> above states explicitly that this unit has an associated quantity kind. In other words, si::metre (and scaled units based on it) can be used to express the amount of any quantity of kind length.
One of the most vital points of the SI system is that its units compose. This allows providing thousands of different units for hundreds of various quantities with a tiny set of predefined units and prefixes.
The same is modeled in the mp-units library, which also allows composing predefined units to create a nearly infinite number of different derived units. For example, one can write:
quantity<si::metre / si::second> q;\nto express a quantity of speed. The resulting quantity type is implicitly inferred from the unit equation by repeating the same operations on the associated quantity kinds.
"},{"location":"users_guide/framework_basics/systems_of_units/#many-shades-of-the-same-unit","title":"Many shades of the same unit","text":"The SI provides the names for 22 common coherent units of 22 derived quantities.
Each such named derived unit is a result of a specific predefined unit equation. For example, a unit of power quantity is defined in the library as:
inline constexpr struct watt final : named_unit<\"W\", joule / second> {} watt;\nHowever, a power quantity can be expressed in other units as well. For example, the following:
auto q1 = 42 * W;\nstd::cout << q1 << \"\\n\";\nstd::cout << q1.in(J / s) << \"\\n\";\nstd::cout << q1.in(N * m / s) << \"\\n\";\nstd::cout << q1.in(kg * m2 / s3) << \"\\n\";\nprints:
42 W\n42 J/s\n42 N m/s\n42 kg m\u00b2/s\u00b3\nAll of the above quantities are equivalent and mean exactly the same.
"},{"location":"users_guide/framework_basics/systems_of_units/#constraining-a-derived-unit-to-work-only-with-a-specific-derived-quantity","title":"Constraining a derived unit to work only with a specific derived quantity","text":"Some derived units are valid only for specific derived quantities. For example, SI specifies both hertz and becquerel derived units with the same unit equation 1 / s. However, it also explicitly states:
SI Brochure
The hertz shall only be used for periodic phenomena and the becquerel shall only be used for stochastic processes in activity referred to a radionuclide.
The above means that the usage of becquerel as a unit of a frequency quantity is an error.
The library allows constraining such units to work only with quantities of a specific kind in the following way:
inline constexpr struct hertz final : named_unit<\"Hz\", one / second, kind_of<isq::frequency>> {} hertz;\ninline constexpr struct becquerel final : named_unit<\"Bq\", one / second, kind_of<isq::activity>> {} becquerel;\nWith the above, hertz can only be used with frequencies, while becquerel should only be used with quantities of activity. This means that the following equation will not compile:
auto q = 1 * Hz + 1 * Bq; // Fails to compile\nThis is exactly what we wanted to achieve to improve the type-safety of the library.
"},{"location":"users_guide/framework_basics/systems_of_units/#prefixed-units","title":"Prefixed units","text":"Besides named units, the SI specifies also 24 prefixes (all being a power of 10) that can be prepended to all named units to obtain various scaled versions of them.
Implementation of std::ratio provided by all major compilers is able to express only 16 of them. This is why, in the mp-units, we had to find an alternative way to represent unit magnitude in a more flexible way.
Each prefix is implemented similarly to the following:
template<PrefixableUnit U> struct quecto_ : prefixed_unit<\"q\", mag_power<10, -30>, U{}> {};\ntemplate<PrefixableUnit auto U> inline constexpr quecto_<decltype(U)> quecto;\nand then a PrefixableUnit can be prefixed in the following way:
inline constexpr auto qm = quecto<metre>;\nThe usage of mag_power not only enables providing support for SI prefixes, but it can also efficiently represent any rational magnitude. For example, IEC 80000 prefixes used in the IT industry can be implemented as:
template<PrefixableUnit U> struct yobi_ : prefixed_unit<\"Yi\", mag_power<2, 80>, U{}> {};\ntemplate<PrefixableUnit auto U> inline constexpr yobi_<decltype(U)> yobi;\nIn the SI, all units are either base or derived units or prefixed versions of those. However, those are only some of the options possible.
For example, there is a list of off-system units accepted for use with SI. Those are scaled versions of the SI units with ratios that can't be explicitly expressed with predefined SI prefixes. Those include units like minute, hour, or electronvolt:
inline constexpr struct minute final : named_unit<\"min\", mag<60> * si::second> {} minute;\ninline constexpr struct hour final : named_unit<\"h\", mag<60> * minute> {} hour;\ninline constexpr struct electronvolt final : named_unit<\"eV\", mag_ratio<1'602'176'634, 1'000'000'000> * mag_power<10, -19> * si::joule> {} electronvolt;\nAlso, units of other systems of units are often defined in terms of scaled versions of the SI units. For example, the international yard is defined as:
inline constexpr struct yard final : named_unit<\"yd\", mag_ratio<9'144, 10'000> * si::metre> {} yard;\nFor some units, a magnitude might also be irrational. The best example here is a degree which is defined using a floating-point magnitude having a factor of the number \u03c0 (Pi):
inline constexpr struct mag_pi final : magnitude<std::numbers::pi_v<long double>> {} mag_pi;\ninline constexpr struct degree final : named_unit<{u8\"\u00b0\", \"deg\"}, mag_pi / mag<180> * si::radian> {} degree;\nBesides providing dimensional analysis and unit conversions, the library also tries hard to print any quantity in the most user-friendly way. We can print the entire quantity or its selected parts (numerical value, unit, or dimension).
Note
The library does not provide a text output for quantity points. The quantity stored inside is just an implementation detail of this type. It is a vector from a specific origin. Without the knowledge of the origin, the vector by itself is useless as we can't determine which point it describes.
In the current library design, point origin does not provide any text in its definition. Even if we could add such information to the point's definition, we would not know how to output it in the text. There may be many ways to do it. For example, should we prepend or append the origin part to the quantity text?
For example, the text output of 42 m for a quantity point may mean many things. It may be an offset from the mountain top, sea level, or maybe the center of Mars. Printing 42 m AMSL for altitudes above mean sea level is a much better solution, but the library does not have enough information to print it that way by itself.
Please let us know if you have a good idea of how to solve this issue.
"},{"location":"users_guide/framework_basics/text_output/#predefined-symbols","title":"Predefined symbols","text":"The definitions of dimensions, units, prefixes, and constants require assigning text symbols for each entity. Those symbols will be composed by the library's framework to express dimensions and units of derived quantities.
DimensionsUnitsPrefixesConstantsinline constexpr struct dim_length final : base_dimension<\"L\"> {} dim_length;\ninline constexpr struct dim_mass final : base_dimension<\"M\"> {} dim_mass;\ninline constexpr struct dim_time final : base_dimension<\"T\"> {} dim_time;\ninline constexpr struct dim_electric_current final : base_dimension<\"I\"> {} dim_electric_current;\ninline constexpr struct dim_thermodynamic_temperature final : base_dimension<{u8\"\u0398\", \"O\"}> {} dim_thermodynamic_temperature;\ninline constexpr struct dim_amount_of_substance final : base_dimension<\"N\"> {} dim_amount_of_substance;\ninline constexpr struct dim_luminous_intensity final : base_dimension<\"J\"> {} dim_luminous_intensity;\ninline constexpr struct second final : named_unit<\"s\", kind_of<isq::time>> {} second;\ninline constexpr struct metre final : named_unit<\"m\", kind_of<isq::length>> {} metre;\ninline constexpr struct gram final : named_unit<\"g\", kind_of<isq::mass>> {} gram;\ninline constexpr auto kilogram = kilo<gram>;\n\ninline constexpr struct newton final : named_unit<\"N\", kilogram * metre / square(second)> {} newton;\ninline constexpr struct joule final : named_unit<\"J\", newton * metre> {} joule;\ninline constexpr struct watt final : named_unit<\"W\", joule / second> {} watt;\ninline constexpr struct coulomb final : named_unit<\"C\", ampere * second> {} coulomb;\ninline constexpr struct volt final : named_unit<\"V\", watt / ampere> {} volt;\ninline constexpr struct farad final : named_unit<\"F\", coulomb / volt> {} farad;\ninline constexpr struct ohm final : named_unit<{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\ntemplate<PrefixableUnit U> struct micro_ : prefixed_unit<{u8\"\u00b5\", \"u\"}, mag_power<10, -6>, U{}> {};\ntemplate<PrefixableUnit U> struct milli_ : prefixed_unit<\"m\", mag_power<10, -3>, U{}> {};\ntemplate<PrefixableUnit U> struct centi_ : prefixed_unit<\"c\", mag_power<10, -2>, U{}> {};\ntemplate<PrefixableUnit U> struct deci_ : prefixed_unit<\"d\", mag_power<10, -1>, U{}> {};\ntemplate<PrefixableUnit U> struct deca_ : prefixed_unit<\"da\", mag_power<10, 1>, U{}> {};\ntemplate<PrefixableUnit U> struct hecto_ : prefixed_unit<\"h\", mag_power<10, 2>, U{}> {};\ntemplate<PrefixableUnit U> struct kilo_ : prefixed_unit<\"k\", mag_power<10, 3>, U{}> {};\ntemplate<PrefixableUnit U> struct mega_ : prefixed_unit<\"M\", mag_power<10, 6>, U{}> {};\ninline constexpr struct hyperfine_structure_transition_frequency_of_cs final : named_unit<{u8\"\u0394\u03bd_Cs\", \"dv_Cs\"}, mag<9'192'631'770> * hertz> {} hyperfine_structure_transition_frequency_of_cs;\ninline constexpr struct speed_of_light_in_vacuum final : named_unit<\"c\", mag<299'792'458> * metre / second> {} speed_of_light_in_vacuum;\ninline constexpr struct planck_constant final : named_unit<\"h\", mag_ratio<662'607'015, 100'000'000> * mag_power<10, -34> * joule * second> {} planck_constant;\ninline constexpr struct elementary_charge final : named_unit<\"e\", mag_ratio<1'602'176'634, 1'000'000'000> * mag_power<10, -19> * coulomb> {} elementary_charge;\ninline constexpr struct boltzmann_constant final : named_unit<\"k\", mag_ratio<1'380'649, 1'000'000> * mag_power<10, -23> * joule / kelvin> {} boltzmann_constant;\ninline constexpr struct avogadro_constant final : named_unit<\"N_A\", mag_ratio<602'214'076, 100'000'000> * mag_power<10, 23> / mole> {} avogadro_constant;\ninline constexpr struct luminous_efficacy final : named_unit<\"K_cd\", mag<683> * lumen / watt> {} luminous_efficacy;\nImportant
Two symbols always have to be provided if the primary symbol contains characters outside of the basic literal character set. The first must be provided as a UTF-8 literal and may contain any Unicode characters. The second one must provide an alternative spelling and only use characters from within of basic literal character set.
Note
Unicode provides only a minimal set of characters available as subscripts, which are often used to differentiate various constants and quantities of the same kind. To workaround this issue, mp-units uses the '_' character to specify that the following characters should be considered a subscript of the symbol.
Tip
For older compilers, it might be required to specify a symbol_text class explicitly template name to initialize it with two symbols:
inline constexpr struct ohm final : named_unit<symbol_text{u8\"\u03a9\", \"ohm\"}, volt / ampere> {} ohm;\ntext_encoding","text":"ISQ and SI standards always specify symbols using Unicode encoding. This is why it is a default and primary target for text output. However, in some applications or environments, a standard ASCII-like text output using only the characters from the basic literal character set can be preferred by users.
This is why the library provides an option to change the default encoding to the ASCII one with:
enum class text_encoding : std::int8_t {\n unicode, // \u00b5s; m\u00b3; L\u00b2MT\u207b\u00b3\n ascii, // us; m^3; L^2MT^-3\n default_encoding = unicode\n};\ndimension_symbol_formatting","text":"dimension_symbol_formatting is a data type describing the configuration of the symbol generation algorithm.
struct dimension_symbol_formatting {\n text_encoding encoding = text_encoding::default_encoding;\n};\ndimension_symbol()","text":"Returns a std::string_view with the symbol of a dimension for the provided configuration:
template<dimension_symbol_formatting fmt = dimension_symbol_formatting{}, typename CharT = char, Dimension D>\n[[nodiscard]] consteval std::string_view dimension_symbol(D);\nFor example:
static_assert(dimension_symbol<{.encoding = text_encoding::ascii}>(isq::power.dimension) == \"L^2MT^-3\");\nNote
std::string_view is returned only when C++23 is available. Otherwise, an instance of a basic_fixed_string is being returned.
dimension_symbol_to()","text":"Inserts the generated dimension symbol into the output text iterator at runtime.
template<typename CharT = char, std::output_iterator<CharT> Out, Dimension D>\nconstexpr Out dimension_symbol_to(Out out, D d, dimension_symbol_formatting fmt = dimension_symbol_formatting{});\nFor example:
std::string txt;\ndimension_symbol_to(std::back_inserter(txt), isq::power.dimension, {.encoding = text_encoding::ascii});\nstd::cout << txt << \"\\n\";\nThe above prints:
L^2MT^-3\nunit_symbol_formatting","text":"unit_symbol_formatting is a data type describing the configuration of the symbol generation algorithm. It contains three orthogonal fields, each with a default value.
enum class unit_symbol_solidus : std::int8_t {\n one_denominator, // m/s; kg m\u207b\u00b9 s\u207b\u00b9\n always, // m/s; kg/(m s)\n never, // m s\u207b\u00b9; kg m\u207b\u00b9 s\u207b\u00b9\n default_denominator = one_denominator\n};\n\nenum class unit_symbol_separator : std::int8_t {\n space, // kg m\u00b2/s\u00b2\n half_high_dot, // kg\u22c5m\u00b2/s\u00b2 (valid only for unicode encoding)\n default_separator = space\n};\n\nstruct unit_symbol_formatting {\n text_encoding encoding = text_encoding::default_encoding;\n unit_symbol_solidus solidus = unit_symbol_solidus::default_denominator;\n unit_symbol_separator separator = unit_symbol_separator::default_separator;\n};\nunit_symbol_solidus impacts how the division of unit symbols is being presented in the text output. By default, the '/' will be printed if only one unit component is in the denominator. Otherwise, the exponent syntax will be used.
unit_symbol_separator specifies how multiple multiplied units should be separated from each other. By default, the space (' ') will be used as a separator.
unit_symbol()","text":"Returns a std::string_view with the symbol of a unit for the provided configuration:
template<unit_symbol_formatting fmt = unit_symbol_formatting{}, typename CharT = char, Unit U>\n[[nodiscard]] consteval std::string_view unit_symbol(U);\nFor example:
static_assert(unit_symbol<{.solidus = unit_symbol_solidus::never,\n .separator = unit_symbol_separator::half_high_dot}>(kg * m / s2) == \"kg\u22c5m\u22c5s\u207b\u00b2\");\nNote
std::string_view is returned only when C++23 is available. Otherwise, an instance of a basic_fixed_string is being returned. See more in the C++ compiler support chapter.
unit_symbol_to()","text":"Inserts the generated unit symbol into the output text iterator at runtime.
template<typename CharT = char, std::output_iterator<CharT> Out, Unit U>\nconstexpr Out unit_symbol_to(Out out, U u, unit_symbol_formatting fmt = unit_symbol_formatting{});\nFor example:
std::string txt;\nunit_symbol_to(std::back_inserter(txt), kg * m / s2,\n {.solidus = unit_symbol_solidus::never, .separator = unit_symbol_separator::half_high_dot});\nstd::cout << txt << \"\\n\";\nThe above prints:
kg\u22c5m\u22c5s\u207b\u00b2\nspace_before_unit_symbol customization point","text":"The SI Brochure says:
SI Brochure
The numerical value always precedes the unit and a space is always used to separate the unit from the number. ... The only exceptions to this rule are for the unit symbols for degree, minute and second for plane angle, \u00b0, \u2032 and \u2033, respectively, for which no space is left between the numerical value and the unit symbol.
There are more units with such properties. For example, percent (%) and per mille(\u2030).
To support the above and other similar cases, the library exposes space_before_unit_symbol customization point. By default, its value is true for all the units, so the space between a number and a unit will be inserted in the output text. To change this behavior, we have to provide a partial specialization for a specific unit:
template<>\ninline constexpr bool space_before_unit_symbol<non_si::degree> = false;\nNote
The above works only for the default formatting or for the format strings that use %? placement field (std::format(\"{}\", q) is equivalent to std::format(\"{:%N%?%U}\", q)).
In case a user provides custom format specification (e.g., std::format(\"{:%N %U}\", q)), the library will always obey this specification for all the units (no matter what the actual value of the space_before_unit_symbol customization point is) and the separating space will always be used in this case.
Tip
The output streaming support is opt-in and can be enabled by including the <mp-units/ostream.h> header file.
The easiest way to print a dimension, unit, or quantity is to provide its object to the output stream:
const QuantityOf<isq::speed> auto v1 = avg_speed(220. * km, 2 * h);\nconst QuantityOf<isq::speed> auto v2 = avg_speed(140. * mi, 2 * h);\nstd::cout << v1 << '\\n'; // 110 km/h\nstd::cout << v2 << '\\n'; // 70 mi/h\nstd::cout << v2.unit << '\\n'; // mi/h\nstd::cout << v2.dimension << '\\n'; // LT\u207b\u00b9\nThe text output will always print the value using the default formatting for this entity.
Important: Don't assume a unit
Remember that when we deal with a quantity of an \"unknown\" (e.g., auto) type, it is a good practice to always convert the unit to the expected one before passing it to the text output:
std::cout << v1.in(km / h) << '\\n'; // 110 km/h\nstd::cout << v1.force_in(m / s) << '\\n'; // 30.5556 m/s\nOnly basic formatting can be applied to output streams. It includes control over width, fill, and alignment.
The numerical value of the quantity will be printed according to the current stream state and standard manipulators may be used to customize that (assuming that the underlying representation type respects them).
std::cout << \"|\" << std::setw(10) << 123 * m << \"|\\n\"; // | 123 m|\nstd::cout << \"|\" << std::setw(10) << std::left << 123 * m << \"|\\n\"; // |123 m |\nstd::cout << \"|\" << std::setw(10) << std::setfill('*') << 123 * m << \"|\\n\"; // |123 m*****|\nNote
To have more control over the formatting of the quantity that is printed with the output stream just use std::cout << std::format(...).
The library provides custom formatters for std::format facility, which allows fine-grained control over what and how it is being printed in the text output.
Tip
The text formatting facility support is opt-in and can be enabled by including the <mp-units/format.h> header file.
Formatting grammar for all the entities provides control over width, fill, and alignment. The C++ standard grammar tokens fill-and-align and width are being used. They treat the entity as a contiguous text to be aligned. For example, here are a few examples of the quantity numerical value and symbol formatting:
std::println(\"|{:0}|\", 123 * m); // |123 m|\nstd::println(\"|{:10}|\", 123 * m); // | 123 m|\nstd::println(\"|{:<10}|\", 123 * m); // |123 m |\nstd::println(\"|{:>10}|\", 123 * m); // | 123 m|\nstd::println(\"|{:^10}|\", 123 * m); // | 123 m |\nstd::println(\"|{:*<10}|\", 123 * m); // |123 m*****|\nstd::println(\"|{:*>10}|\", 123 * m); // |*****123 m|\nstd::println(\"|{:*^10}|\", 123 * m); // |**123 m***|\nIt is important to note that in the second line above, the quantity text is aligned to the right by default, which is consistent with the formatting of numeric types. Units and dimensions behave as text and, thus, are aligned to the left by default.
Note
std::println is a C++23 facility. In case we do not have access to C++23, we can obtain the same output with:
std::cout << std::format(\"<format-string>\\n\", <format-args>);\ndimension-format-spec = [fill-and-align], [width], [dimension-spec];\ndimension-spec = [text-encoding];\ntext-encoding = 'U' | 'A';\nIn the above grammar:
fill-and-align and width tokens are defined in the format.string.std chapter of the C++ standard specification,text-encoding token specifies the symbol text encoding:U (default) uses the Unicode symbols defined by [@ISO80000] (e.g., LT\u207b\u00b2),A forces non-standard ASCII-only output (e.g., LT^-2).Dimension symbols of some quantities are specified to use Unicode signs by the ISQ (e.g., \u0398 symbol for the thermodynamic temperature dimension). The library follows this by default. From the engineering point of view, sometimes Unicode text might not be the best solution, as terminals of many (especially embedded) devices can output only letters from the basic literal character set. In such a case, the dimension symbol can be forced to be printed using such characters thanks to text-encoding token:
std::println(\"{}\", isq::dim_thermodynamic_temperature); // \u0398\nstd::println(\"{:A}\", isq::dim_thermodynamic_temperature); // O\nstd::println(\"{}\", isq::power.dimension); // L\u00b2MT\u207b\u00b3\nstd::println(\"{:A}\", isq::power.dimension); // L^2MT^-3\nunit-format-spec = [fill-and-align], [width], [unit-spec];\nunit-spec = [text-encoding], [unit-symbol-solidus], [unit-symbol-separator], [L]\n | [text-encoding], [unit-symbol-separator], [unit-symbol-solidus], [L]\n | [unit-symbol-solidus], [text-encoding], [unit-symbol-separator], [L]\n | [unit-symbol-solidus], [unit-symbol-separator], [text-encoding], [L]\n | [unit-symbol-separator], [text-encoding], [unit-symbol-solidus], [L]\n | [unit-symbol-separator], [unit-symbol-solidus], [text-encoding], [L];\nunit-symbol-solidus = '1' | 'a' | 'n';\nunit-symbol-separator = 's' | 'd';\nIn the above grammar:
fill-and-align and width tokens are defined in the format.string.std chapter of the C++ standard specification,unit-symbol-solidus token specifies how the division of units should look like:/ only when there is only one unit in the denominator, otherwise negative exponents are printed (e.g., m/s, kg m\u207b\u00b9 s\u207b\u00b9)m/s, kg/(m s))m s\u207b\u00b9, kg m\u207b\u00b9 s\u207b\u00b9)unit-symbol-separator token specifies how multiplied unit symbols should be separated:kg m\u00b2/s\u00b2)\u22c5) as a separator (e.g., kg\u22c5m\u00b2/s\u00b2) (requires the Unicode encoding)Note
The above grammar intended that the elements of unit-spec can appear in any order as they have unique characters. Users shouldn't have to remember the order of those tokens to control the formatting of a unit symbol.
Unit symbols of some quantities are specified to use Unicode signs by the SI (e.g., \u03a9 symbol for the resistance quantity). The library follows this by default. From the engineering point of view, Unicode text might not be the best solution sometimes, as terminals of many (especially embedded) devices can output only letters from the basic literal character set. In such a case, the unit symbol can be forced to be printed using such characters thanks to text-encoding token:
std::println(\"{}\", si::ohm); // \u03a9\nstd::println(\"{:A}\", si::ohm); // ohm\nstd::println(\"{}\", us); // \u00b5s\nstd::println(\"{:A}\", us); // us\nstd::println(\"{}\", m / s2); // m/s\u00b2\nstd::println(\"{:A}\", m / s2); // m/s^2\nAdditionally, both ISO 80000 and SI leave some freedom on how to print unit symbols. This is why two additional tokens were introduced.
unit-symbol-solidus specifies how the division of units should look like. By default, / will be used only when the denominator contains only one unit. However, with the 'a' or 'n' options, we can force the facility to print the / character always (even when there are more units in the denominator), or never, in which case a parenthesis will be added to enclose all denominator units.
std::println(\"{}\", m / s); // m/s\nstd::println(\"{}\", kg / m / s2); // kg m\u207b\u00b9 s\u207b\u00b2\nstd::println(\"{:a}\", m / s); // m/s\nstd::println(\"{:a}\", kg / m / s2); // kg/(m s\u00b2)\nstd::println(\"{:n}\", m / s); // m s\u207b\u00b9\nstd::println(\"{:n}\", kg / m / s2); // kg m\u207b\u00b9 s\u207b\u00b2\nAlso, there are a few options to separate the units being multiplied. ISO 80000 (part 1) says:
ISO 80000-1
When symbols for quantities are combined in a product of two or more quantities, this combination is indicated in one of the following ways: ab, a b, a \u00b7 b, a \u00d7 b
NOTE 1 In some fields, e.g., vector algebra, distinction is made between a \u2219 b and a \u00d7 b.
The library supports a b and a \u00b7 b only. Additionally, we decided that the extraneous space in the latter case makes the result too verbose, so we decided just to use the \u00b7 symbol as a separator.
Note
Please let us know if you require more formatting options here.
The unit-symbol-separator token allows us to obtain the following outputs:
std::println(\"{}\", kg * m2 / s2); // kg m\u00b2/s\u00b2\nstd::println(\"{:d}\", kg * m2 / s2); // kg\u22c5m\u00b2/s\u00b2\nNote
'd' requires the Unicode encoding to be set.
"},{"location":"users_guide/framework_basics/text_output/#quantity-formatting","title":"Quantity formatting","text":"quantity-format-spec = [fill-and-align], [width], [quantity-specs], [defaults-specs];\nquantity-specs = conversion-spec;\n | quantity-specs, conversion-spec;\n | quantity-specs, literal-char;\nliteral-char = ? any character other than '{', '}', or '%' ?;\nconversion-spec = '%', placement-type;\nplacement-type = subentity-id | '?' | '%';\ndefaults-specs = ':', default-spec-list;\ndefault-spec-list = default-spec;\n | default-spec-list, default-spec;\ndefault-spec = subentity-id, '[' format-spec ']';\nsubentity-id = 'N' | 'U' | 'D';\nformat-spec = ? as specified by the formatter for the argument type ?;\nIn the above grammar:
fill-and-align and width tokens are defined in the format.string.std chapter of the C++ standard specification,placement-type token specifies which entity should be put and where:space_before_unit_symbol for this unit,defaults-specs token allows overwriting defaults for the underlying formatters with the custom format string. Each override starts with a subentity identifier ('N', 'U', or 'D') followed by the format string enclosed in square brackets.To format quantity values, the formatting facility uses quantity-format-spec. If left empty, the default formatting is applied. The same default formatting is also applied to the output streams. This is why the following code lines produce the same output:
std::cout << \"Distance: \" << 123 * km << \"\\n\";\nstd::cout << std::format(\"Distance: {}\\n\", 123 * km);\nstd::cout << std::format(\"Distance: {:%N%?%U}\\n\", 123 * km);\nNote
For some quantities, the {:%N %U} format may provide a different output than the default one, as some units have space_before_unit_symbol customization point explicitly set to false (e.g., % and \u00b0).
Thanks to the grammar provided above, the user can easily decide to either:
print a whole quantity:
std::println(\"Speed: {}\", 120 * km / h);\nSpeed: 120 km/h\nprovide custom quantity formatting:
std::println(\"Speed: {:%N in %U}\", 120 * km / h);\nSpeed: 120 in km/h\nprovide custom formatting for components:
std::println(\"Speed: {::N[.2f]U[n]}\", 100. * km / (3 * h));\nSpeed: 33.33 km h\u207b\u00b9\nprint only specific components (numerical value, unit, or dimension):
std::println(\"Speed:\\n- number: {0:%N}\\n- unit: {0:%U}\\n- dimension: {0:%D}\", 120 * km / h);\nSpeed:\n- number: 120\n- unit: km/h\n- dimension: LT\u207b\u00b9\nThe representation type used as a numerical value of a quantity must provide its own formatter specialization. It will be called by the quantity formatter with the format-spec provided by the user in the N defaults specification.
In case we use C++ fundamental arithmetic types with our quantities the standard formatter specified in format.string.std will be used. The rest of this chapter assumes that it is the case and provides some usage examples.
sign token allows us to specify how the value's sign is being printed:
std::println(\"{0},{0::N[+]},{0::N[-]},{0::N[ ]}\", 1 * m); // 1 m,+1 m,1 m, 1 m\nstd::println(\"{0},{0::N[+]},{0::N[-]},{0::N[ ]}\", -1 * m); // -1 m,-1 m,-1 m,-1 m\nwhere:
+ indicates that a sign should be used for both non-negative and negative numbers,- indicates that a sign should be used for negative numbers and negative zero only (this is the default behavior),<space> indicates that a leading space should be used for non-negative numbers other than negative zero, and a minus sign for negative numbers and negative zero.precision token is allowed only for floating-point representation types:
std::println(\"{::N[.0]}\", 1.2345 * m); // 1 m\nstd::println(\"{::N[.1]}\", 1.2345 * m); // 1 m\nstd::println(\"{::N[.2]}\", 1.2345 * m); // 1.2 m\nstd::println(\"{::N[.3]}\", 1.2345 * m); // 1.23 m\nstd::println(\"{::N[.0f]}\", 1.2345 * m); // 1 m\nstd::println(\"{::N[.1f]}\", 1.2345 * m); // 1.2 m\nstd::println(\"{::N[.2f]}\", 1.2345 * m); // 1.23 m\ntype specifies how a value of the representation type is being printed. For integral types:
std::println(\"{::N[b]}\", 42 * m); // 101010 m\nstd::println(\"{::N[B]}\", 42 * m); // 101010 m\nstd::println(\"{::N[d]}\", 42 * m); // 42 m\nstd::println(\"{::N[o]}\", 42 * m); // 52 m\nstd::println(\"{::N[x]}\", 42 * m); // 2a m\nstd::println(\"{::N[X]}\", 42 * m); // 2A m\nThe above can be printed in an alternate version thanks to the # token:
std::println(\"{::N[#b]}\", 42 * m); // 0b101010 m\nstd::println(\"{::N[#B]}\", 42 * m); // 0B101010 m\nstd::println(\"{::N[#o]}\", 42 * m); // 052 m\nstd::println(\"{::N[#x]}\", 42 * m); // 0x2a m\nstd::println(\"{::N[#X]}\", 42 * m); // 0X2A m\nFor floating-point values, the type token works as follows:
std::println(\"{::N[a]}\", 1.2345678 * m); // 1.3c0ca2a5b1d5dp+0 m\nstd::println(\"{::N[.3a]}\", 1.2345678 * m); // 1.3c1p+0 m\nstd::println(\"{::N[A]}\", 1.2345678 * m); // 1.3C0CA2A5B1D5DP+0 m\nstd::println(\"{::N[.3A]}\", 1.2345678 * m); // 1.3C1P+0 m\nstd::println(\"{::N[e]}\", 1.2345678 * m); // 1.234568e+00 m\nstd::println(\"{::N[.3e]}\", 1.2345678 * m); // 1.235e+00 m\nstd::println(\"{::N[E]}\", 1.2345678 * m); // 1.234568E+00 m\nstd::println(\"{::N[.3E]}\", 1.2345678 * m); // 1.235E+00 m\nstd::println(\"{::N[g]}\", 1.2345678 * m); // 1.23457 m\nstd::println(\"{::N[g]}\", 1.2345678e8 * m); // 1.23457e+08 m\nstd::println(\"{::N[.3g]}\", 1.2345678 * m); // 1.23 m\nstd::println(\"{::N[.3g]}\", 1.2345678e8 * m); // 1.23e+08 m\nstd::println(\"{::N[G]}\", 1.2345678 * m); // 1.23457 m\nstd::println(\"{::N[G]}\", 1.2345678e8 * m); // 1.23457E+08 m\nstd::println(\"{::N[.3G]}\", 1.2345678 * m); // 1.23 m\nstd::println(\"{::N[.3G]}\", 1.2345678e8 * m); // 1.23E+08 m\nThe affine space has two types of entities:
In the following subchapters, we will often refer to displacement vectors simply as vectors for brevity.
Note
The displacement vector described here is specific to the affine space theory and is not the same thing as the quantity of a vector character that we discussed in the \"Scalars, vectors, and tensors\" chapter (although, in some cases, those terms may overlap).
"},{"location":"users_guide/framework_basics/the_affine_space/#operations-in-the-affine-space","title":"Operations in the affine space","text":"Here are the primary operations one can do in the affine space:
Important
It is not possible to:
Point abstractions should be used more often in the C++ software. They are not only about temperature or time. Points are everywhere around us and should become more popular in the products we implement. They can be used to implement:
Improving the affine space's Points intuition will allow us to write better and safer software.
"},{"location":"users_guide/framework_basics/the_affine_space/#displacement-vector-is-modeled-by-quantity","title":"Displacement vector is modeled byquantity","text":"Up until now, each time we used a quantity in our code, we were modeling some kind of a difference between two things:
As we already know, a quantity type provides all operations required for a displacement vector abstraction in the affine space. It can be constructed with:
delta<Reference> construction helper (e.g., delta<isq::height[m]>(42), delta<deg_C>(3)),Note
The multiply syntax support is disabled for units that provide a point origin in their definition (i.e., units of temperature like K, deg_C, and deg_F).
quantity_point and PointOrigin","text":"In the mp-units library, the Point abstraction is modelled by:
PointOrigin concept that specifies measurement origin, andquantity_point class template that specifies a Point relative to a specific predefined origin.quantity_point","text":"The quantity_point class template specifies an absolute quantity measured from a predefined origin:
template<Reference auto R,\n PointOriginFor<get_quantity_spec(R)> auto PO = default_point_origin(R),\n RepresentationOf<get_quantity_spec(R).character> Rep = double>\nclass quantity_point;\nAs we can see above, the quantity_point class template exposes one additional parameter compared to quantity. The PO parameter satisfies a PointOriginFor concept and specifies the origin of our measurement scale.
Each quantity_point internally stores a quantity object, which represents a displacement vector from the predefined origin. Thanks to this, an instantiation of a quantity_point can be considered as a model of a vector space from such an origin.
Forcing the user to manually predefine an origin for every domain may be cumbersome and discourage users from using such abstractions at all. This is why, by default, the PO template parameter is initialized with the default_point_origin(R) that provides the quantity points' scale zeroth point using the following rules:
zeroth_point_origin<QuantitySpec> is being used which provides a well-established zeroth point for a specific quantity type.Quantity points with default point origins may be constructed with the absolute construction helper or forcing an explicit conversion from the quantity:
// quantity_point qp1 = 42 * m; // Compile-time error\n// quantity_point qp2 = 42 * K; // Compile-time error\n// quantity_point qp3 = delta<deg_C>(42); // Compile-time error\nquantity_point qp4(42 * m);\nquantity_point qp5(42 * K);\nquantity_point qp6(delta<deg_C>(42));\nquantity_point qp7 = absolute<m>(42);\nquantity_point qp8 = absolute<K>(42);\nquantity_point qp9 = absolute<deg_C>(42);\nTip
The quantity_point definition can be found in the mp-units/quantity_point.h header file.
zeroth_point_origin<QuantitySpec>","text":"zeroth_point_origin<QuantitySpec> is meant to be used in cases where the specific domain has a well-established, non-controversial, and unique zeroth point on the measurement scale. This saves the user from the need to write a boilerplate code that would predefine such a type for this domain.
quantity_point<isq::distance[si::metre]> qp1(100 * m);\nquantity_point<isq::distance[si::metre]> qp2 = absolute<m>(120);\n\nassert(qp1.quantity_from_zero() == 100 * m);\nassert(qp2.quantity_from_zero() == 120 * m);\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\n\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\n\n// auto res = qp1 + qp2; // Compile-time error\nIn the above code 100 * m and 120 * m still create two quantities that serve as displacement vectors here. Quantity point objects can be explicitly constructed from such quantities only when their origin is an instantiation of the zeroth_point_origin<QuantitySpec>.
It is really important to understand that even though we can use .quantity_from_zero() to obtain the displacement vector of a point from the origin, the point by itself does not represent or have any associated physical value. It is just a point in some space. The same point can be expressed with different displacement vectors from different origins.
It is also worth mentioning that simplicity comes with a safety cost here. For some users, it might be surprising that the usage of zeroth_point_origin<QuantitySpec> makes various quantity point objects compatible as long as quantity types used in the origin and reference are compatible:
quantity_point<si::metre> qp1{isq::distance(100 * m)};\nquantity_point<si::metre> qp2 = absolute<isq::height[m]>(120);\n\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\nIn cases where we want to implement an isolated independent space in which points are not compatible with other spaces, even of the same quantity type, we should manually predefine an absolute point origin.
inline constexpr struct origin final : absolute_point_origin<isq::distance> {} origin;\n\n// quantity_point<si::metre, origin> qp1{100 * m}; // Compile-time error\n// quantity_point<si::metre, origin> qp2{delta<m>(120)}; // Compile-time error\nquantity_point<si::metre, origin> qp1 = origin + 100 * m;\nquantity_point<si::metre, origin> qp2 = 120 * m + origin;\n\n// assert(qp1.quantity_from_zero() == 100 * m); // Compile-time error\n// assert(qp2.quantity_from_zero() == 120 * m); // Compile-time error\nassert(qp1.quantity_from(origin) == 100 * m);\nassert(qp2.quantity_from(origin) == 120 * m);\nassert(qp2.quantity_from(qp1) == 20 * m);\nassert(qp1.quantity_from(qp2) == -20 * m);\n\nassert(qp1 - origin == 100 * m);\nassert(qp2 - origin == 120 * m);\nassert(qp2 - qp1 == 20 * m);\nassert(qp1 - qp2 == -20 * m);\n\nassert(origin - qp1 == -100 * m);\nassert(origin - qp2 == -120 * m);\n\n// assert(origin - origin == 0 * m); // Compile-time error\nWe can't construct a quantity point directly from the quantity anymore when a custom, named origin is used. To prevent potential safety and maintenance issues, we always need to explicitly provide both a compatible origin and a quantity measured from it to construct a quantity point.
Said otherwise, a quantity point defined in terms of a specific origin is the result of adding the origin and the displacement vector measured from it to the point we create.
Info
A rationale for this longer construction syntax can be found in the Why can't I create a quantity by passing a number to a constructor? chapter.
Similarly to creation of a quantity, if someone does not like the operator-based syntax to create a quantity_point, the same results can be achieved with a two-parameter constructor:
quantity_point qp1{100 * m, origin};\nAgain, CTAD always helps to use precisely the type we need in a current case.
Additionally, if a quantity point is defined in terms of a custom, named origin, then we can't use a quantity_from_zero() member function anymore. This is to prevent surprises, as our origin may not necessarily be perceived as an absolute zero in the domain we model. Also, as we will learn soon, we can define several related origins in one space, and then it gets harder to understand which one is the \"zero\" one. This is why, to be specific and always correct about the points we use, a quantity_from(QP) member function can be used (where QP can either be an origin or another quantity point).
Finally, please note that it is not allowed to subtract two point origins defined in terms of absolute_point_origin (e.g., origin - origin) as those do not contain information about the unit, so we cannot determine a resulting quantity type.
Absolute point origins are also perfect for establishing independent spaces even if the same quantity type and unit is being used:
inline constexpr struct origin1 final : absolute_point_origin<isq::distance> {} origin1;\ninline constexpr struct origin2 final : absolute_point_origin<isq::distance> {} origin2;\n\nquantity_point qp1 = origin1 + 100 * m;\nquantity_point qp2 = origin2 + 120 * m;\n\nassert(qp1.quantity_from(origin1) == 100 * m);\nassert(qp2.quantity_from(origin2) == 120 * m);\n\nassert(qp1 - origin1 == 100 * m);\nassert(qp2 - origin2 == 120 * m);\nassert(origin1 - qp1 == -100 * m);\nassert(origin2 - qp2 == -120 * m);\n\n// assert(qp2 - qp1 == 20 * m); // Compile-time error\n// assert(qp1 - origin2 == 100 * m); // Compile-time error\n// assert(qp2 - origin1 == 120 * m); // Compile-time error\n// assert(qp2.quantity_from(qp1) == 20 * m); // Compile-time error\n// assert(qp1.quantity_from(origin2) == 100 * m); // Compile-time error\n// assert(qp2.quantity_from(origin1) == 120 * m); // Compile-time error\nWe often do not have only one ultimate \"zero\" point when we measure things. Often, we have one common scale, but we measure various quantities relative to different points and expect those points to be compatible. There are many examples here, but probably the most common are temperatures, timestamps, and altitudes.
For such cases, relative point origins should be used:
inline constexpr struct A final : absolute_point_origin<isq::distance> {} A;\ninline constexpr struct B final : relative_point_origin<A + 10 * m> {} B;\ninline constexpr struct C final : relative_point_origin<B + 10 * m> {} C;\ninline constexpr struct D final : relative_point_origin<A + 30 * m> {} D;\n\nquantity_point qp1 = C + 100 * m;\nquantity_point qp2 = D + 120 * m;\n\nassert(qp1.quantity_ref_from(qp1.point_origin) == 100 * m);\nassert(qp2.quantity_ref_from(qp2.point_origin) == 120 * m);\n\nassert(qp2.quantity_from(qp1) == 30 * m);\nassert(qp1.quantity_from(qp2) == -30 * m);\nassert(qp2 - qp1 == 30 * m);\nassert(qp1 - qp2 == -30 * m);\n\nassert(qp1.quantity_from(A) == 120 * m);\nassert(qp1.quantity_from(B) == 110 * m);\nassert(qp1.quantity_from(C) == 100 * m);\nassert(qp1.quantity_from(D) == 90 * m);\nassert(qp1 - A == 120 * m);\nassert(qp1 - B == 110 * m);\nassert(qp1 - C == 100 * m);\nassert(qp1 - D == 90 * m);\n\nassert(qp2.quantity_from(A) == 150 * m);\nassert(qp2.quantity_from(B) == 140 * m);\nassert(qp2.quantity_from(C) == 130 * m);\nassert(qp2.quantity_from(D) == 120 * m);\nassert(qp2 - A == 150 * m);\nassert(qp2 - B == 140 * m);\nassert(qp2 - C == 130 * m);\nassert(qp2 - D == 120 * m);\n\nassert(B - A == 10 * m);\nassert(C - A == 20 * m);\nassert(D - A == 30 * m);\nassert(D - C == 10 * m);\n\nassert(B - B == 0 * m);\n// assert(A - A == 0 * m); // Compile-time error\nNote
Even though we can't subtract two absolute point origins from each other, it is possible to subtract relative ones or relative and absolute ones.
"},{"location":"users_guide/framework_basics/the_affine_space/#converting-between-different-representations-of-the-same-point","title":"Converting between different representations of the same point","text":"As we might represent the same point with displacement vectors from various origins, the library provides facilities to convert the same point to the quantity_point class templates expressed in terms of different origins.
For this purpose, we can use either:
A converting constructor:
quantity_point<si::metre, C> qp2C = qp2;\nassert(qp2C.quantity_ref_from(qp2C.point_origin) == 130 * m);\nA dedicated conversion interface:
quantity_point qp2B = qp2.point_for(B);\nquantity_point qp2A = qp2.point_for(A);\n\nassert(qp2B.quantity_ref_from(qp2B.point_origin) == 140 * m);\nassert(qp2A.quantity_ref_from(qp2A.point_origin) == 150 * m);\nIt is important to understand that all such translations still describe exactly the same point (e.g., all of them compare equal):
assert(qp2 == qp2C);\nassert(qp2 == qp2B);\nassert(qp2 == qp2A);\nImportant
It is only allowed to convert between various origins defined in terms of the same absolute_point_origin. Even if it is possible to express the same point as a displacement vector from another absolute_point_origin, the library will not provide such a conversion. A custom user-defined conversion function will be needed to add such a functionality.
Said another way, in the library, there is no way to spell how two distinct absolute_point_origin types relate to each other.
Support for temperature quantity points is probably one of the most common examples of relative point origins in action that we use in daily life.
The SI definition in the library provides a few predefined point origins for this purpose:
namespace si {\n\ninline constexpr struct absolute_zero final : absolute_point_origin<isq::thermodynamic_temperature> {} absolute_zero;\ninline constexpr auto zeroth_kelvin = absolute_zero;\n\ninline constexpr struct ice_point final : relative_point_origin<absolute<milli<kelvin>>(273'150)}> {} ice_point;\ninline constexpr auto zeroth_degree_Celsius = ice_point;\n\n}\n\nnamespace usc {\n\ninline constexpr struct zeroth_degree_Fahrenheit final :\n relative_point_origin<absolute<mag_ratio<5, 9> * si::degree_Celsius>(-32)> {} zeroth_degree_Fahrenheit;\n\n}\nThe above is a great example of how point origins can be stacked on top of each other:
usc::zeroth_degree_Fahrenheit is defined relative to si::zeroth_degree_Celsiussi::zeroth_degree_Celsius is defined relative to si::zeroth_kelvin.Note
Notice that while stacking point origins, we can use different representation types and units for origins and a point. In the above example, the relative point origin for degree Celsius is defined in terms of si::kelvin, while the quantity point for it will use si::degree_Celsius as a unit.
The temperature point origins defined above are provided explicitly in the respective units' definitions:
namespace si {\n\ninline constexpr struct kelvin final :\n named_unit<\"K\", kind_of<isq::thermodynamic_temperature>, zeroth_kelvin> {} kelvin;\ninline constexpr struct degree_Celsius final :\n named_unit<{u8\"\u2103\", \"`C\"}, kelvin, zeroth_degree_Celsius> {} degree_Celsius;\n\n}\n\nnamespace usc {\n\ninline constexpr struct degree_Fahrenheit final :\n named_unit<{u8\"\u2109\", \"`F\"}, mag_ratio<5, 9> * si::degree_Celsius,\n zeroth_degree_Fahrenheit> {} degree_Fahrenheit;\n\n}\nAs it was described above, default_point_origin(R) returns a zeroth_point_origin<QuantitySpec> when a unit does not provide any origin in its definition. As of today, the units of temperature are the only ones in the entire mp-units library that provide such origins.
Now, let's see how we can benefit from the above definitions. We have quite a few alternatives to choose from here. Depending on our needs or tastes, we can:
be explicit about the unit and origin:
quantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q1 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q2{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q3{delta<deg_C>(20.5)};\nquantity_point<si::degree_Celsius, si::zeroth_degree_Celsius> q4 = absolute<deg_C>(20.5);\nspecify a unit and use its zeroth point origin implicitly:
quantity_point<si::degree_Celsius> q5 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point<si::degree_Celsius> q6{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point<si::degree_Celsius> q7{delta<deg_C>(20.5)};\nquantity_point<si::degree_Celsius> q8 = absolute<deg_C>(20.5);\nbenefit from CTAD:
quantity_point q9 = si::zeroth_degree_Celsius + delta<deg_C>(20.5);\nquantity_point q10{delta<deg_C>(20.5), si::zeroth_degree_Celsius};\nquantity_point q11{delta<deg_C>(20.5)};\nquantity_point q12 = absolute<deg_C>(20.5);\nIn all of the above cases, we end up with the quantity_point of the same type and value.
To play a bit more with temperatures, we can implement a simple room AC temperature controller in the following way:
constexpr struct room_reference_temp final : relative_point_origin<absolute<deg_C>(21)> {} room_reference_temp;\nusing room_temp = quantity_point<isq::Celsius_temperature[deg_C], room_reference_temp>;\n\nconstexpr auto step_delta = delta<isq::Celsius_temperature<deg_C>>(0.5);\nconstexpr int number_of_steps = 6;\n\nroom_temp room_ref{};\nroom_temp room_low = room_ref - number_of_steps * step_delta;\nroom_temp room_high = room_ref + number_of_steps * step_delta;\n\nstd::println(\"Room reference temperature: {} ({}, {::N[.2f]})\\n\",\n room_ref.quantity_from_zero(),\n room_ref.in(usc::degree_Fahrenheit).quantity_from_zero(),\n room_ref.in(si::kelvin).quantity_from_zero());\n\nstd::println(\"| {:<18} | {:^18} | {:^18} | {:^18} |\",\n \"Temperature delta\", \"Room reference\", \"Ice point\", \"Absolute zero\");\nstd::println(\"|{0:=^20}|{0:=^20}|{0:=^20}|{0:=^20}|\", \"\");\n\nauto print_temp = [&](std::string_view label, auto v) {\n std::println(\"| {:<14} | {:^18} | {:^18} | {:^18:N[.2f]} |\", label,\n v - room_reference_temp, (v - si::ice_point).in(deg_C), (v - si::absolute_zero).in(deg_C));\n};\n\nprint_temp(\"Lowest\", room_low);\nprint_temp(\"Default\", room_ref);\nprint_temp(\"Highest\", room_high);\nThe above prints:
Room reference temperature: 21 \u2103 (69.8 \u2109, 294.15 K)\n\n| Temperature delta | Room reference | Ice point | Absolute zero |\n|====================|====================|====================|====================|\n| Lowest | -3 \u2103 | 18 \u2103 | 291.15 \u2103 |\n| Default | 0 \u2103 | 21 \u2103 | 294.15 \u2103 |\n| Highest | 3 \u2103 | 24 \u2103 | 297.15 \u2103 |\nThe library does not provide a text output for quantity points. The quantity stored inside is just an implementation detail of this type. It is a vector from a specific origin. Without the knowledge of the origin, the vector by itself is useless as we can't determine which point it describes.
In the current library design, point origin does not provide any text in its definition. Even if we could add such information to the point's definition, we would not know how to output it in the text. There may be many ways to do it. For example, should we prepend or append the origin part to the quantity text?
For example, the text output of 42 m for a quantity point may mean many things. It may be an offset from the mountain top, sea level, or maybe the center of Mars. Printing 42 m AMSL for altitudes above mean sea level is a much better solution, but the library does not have enough information to print it that way by itself.
The following operations are not allowed in the affine space:
quantity_point objectsquantity_point from a quantityquantity_point with a scalar2 * DEN airport location?quantity_point with a quantityquantity_point objectsquantity_points of different quantity kindsquantity_points of inconvertible quantitiesquantity_points of convertible quantities but with unrelated originsImportant: The affine space improves safety
The usage of quantity_point and affine space types, in general, improves expressiveness and type-safety of the code we write.
auto q1 = 5 * km;\nstd::cout << q1.in(m) << '\\n';\nquantity<si::metre, int> q2 = q1;\nThe second line above converts the current quantity to the one expressed in meters and prints its contents. The third line converts the quantity expressed in kilometers into the one measured in meters.
In case a user would like to perform an opposite transformation:
auto q1 = 5 * m;\nstd::cout << q1.in(km) << '\\n';\nquantity<si::kilo<si::metre>, int> q2 = q1;\nBoth conversions will fail to compile.
There are two ways to make the above work. The first solution is to use a floating-point representation type:
auto q1 = 5. * m;\nstd::cout << q1.in(km) << '\\n';\nquantity<si::kilo<si::metre>> q2 = q1;\nor
auto q1 = 5 * m;\nstd::cout << value_cast<double>(q1).in(km) << '\\n';\nquantity<si::kilo<si::metre>> q2 = q1; // double by default\nImportant
The mp-units library follows std::chrono::duration logic and treats floating-point types as value-preserving.
The second solution is to force a truncating conversion:
auto q1 = 5 * m;\nstd::cout << value_cast<km>(q1) << '\\n';\nquantity<si::kilo<si::metre>, int> q2 = q1.force_in(km);\nThis explicit cast makes it clear that something unsafe is going on. It is easy to spot in code reviews or while chasing a bug in the source code.
Note
q.force_in(U) is just a shortcut to run value_cast<U>(q). There is no difference in behavior between those two interfaces. q.force_in(U) was added for consistency with q.in(U) and q.force_numerical_value_in(U).
Another place where this cast is useful is when a user wants to convert a quantity with a floating-point representation to the one using an integral one. Again, this is a truncating conversion, so an explicit cast is needed:
quantity<si::metre, int> q3 = value_cast<int>(3.14 * m);\nInfo
It is often OK to use an integral as a representation type, but in general, floating-point types provide better precision and are privileged in the library as they are considered to be value-preserving.
In some cases, a unit and a representation type should be changed simultaneously. Moreover, sometimes, the order of doing those operations matters. In such cases, the library provides the value_cast<U, Rep>(q) which always returns the most precise result:
inline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\ninline constexpr struct currency final : quantity_spec<dim_currency> {} currency;\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n} // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\ninline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\ninline constexpr struct currency final : quantity_spec<currency, dim_currency> {} currency;\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n} // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\ninline constexpr struct dim_currency final : base_dimension<\"$\"> {} dim_currency;\nQUANTITY_SPEC(currency, dim_currency);\n\ninline constexpr struct us_dollar final : named_unit<\"USD\", kind_of<currency>> {} us_dollar;\ninline constexpr struct scaled_us_dollar final : named_unit<\"USD_s\", mag_power<10, -8> * us_dollar> {} scaled_us_dollar;\n\nnamespace unit_symbols {\n\ninline constexpr auto USD = us_dollar;\ninline constexpr auto USD_s = scaled_us_dollar;\n\n} // namespace unit_symbols\n\nusing Price = quantity_point<currency[us_dollar]>;\nusing Scaled = quantity_point<currency[scaled_us_dollar], zeroth_point_origin<currency>, std::int64_t>;\nusing namespace unit_symbols;\nPrice price{12.95 * USD};\nScaled spx = value_cast<USD_s, std::int64_t>(price);\nAs a shortcut, instead of providing a unit and a representation type to value_cast, you may also provide a Quantity type directly, from which unit and representation type are taken. However, value_cast<Quantity>, still only allows for changes in unit and representation type, but not changing the type of the quantity. For that, you will have to use a quantity_cast instead.
Overloads are also provided for instances of quantity_point. All variants of value_cast<...>(q) that apply to instances of quantity have a corresponding version applicable to quantity_point, where the point_origin remains untouched, and the cast changes how the \"offset\" from the origin is represented. Specifically, for any quantity_point instance qp, all of the following equivalences hold:
static_assert(value_cast<Rep>(qp) == quantity_point{value_cast<Rep>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<U>(qp) == quantity_point{value_cast<U>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<U, Rep>(qp) == quantity_point{value_cast<U, Rep>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nstatic_assert(value_cast<Q>(qp) == quantity_point{value_cast<Q>(qp.quantity_from(qp.point_origin)), qp.point_origin});\nFurthermore, there is one additional overload value_cast<ToQP>(qp). This overload permits to additionally replace the point_origin with another compatible one, while still representing the same point in the affine space. Thus, it is roughly equivalent to value_cast<ToQP::unit, ToQP::rep>(qp).point_for(ToQP::point_origin). In contrast to a separate value_cast followed by point_for (or vice-versa), the combined value_cast tries to choose the order of the individual conversion steps in a way to avoid both overflow and unnecessary loss of precision. Overflow is a risk because the change of origin point may require an addition of a potentially large offset (the difference between the origin points), which may well be outside the range of one or both quantity types.
The table below provides all the value conversions functions that may be run on x being the instance of either quantity or quantity_point:
u x.in(u) No T Same x.in<T>() No T u x.in<T>(u) Yes Same u x.force_in(u) value_cast<u>(x) Yes T Same x.force_in<T>() value_cast<T>(x) Yes T u x.force_in<T>(u) value_cast<u, T>(x)"},{"location":"users_guide/systems/strong_angular_system/","title":"Strong Angular System","text":""},{"location":"users_guide/systems/strong_angular_system/#some-background-information","title":"Some background information","text":"As per today's SI, both radian and steradian are dimensionless. This forces the convention to set the angle 1 radian equal to the number 1 within equations (similar to what natural units system does for c constant).
Following Wikipedia:
Wikipedia: Radian - Dimensional analysis
Giacomo Prando says \"the current state of affairs leads inevitably to ghostly appearances and disappearances of the radian in the dimensional analysis of physical equations.\" For example, a mass hanging by a string from a pulley will rise or drop by \\(y=r\u03b8\\) centimeters, where \\(r\\) is the radius of the pulley in centimeters and \\(\u03b8\\) is the angle the pulley turns in radians. When multiplying \\(r\\) by \\(\u03b8\\) the unit of radians disappears from the result. Similarly in the formula for the angular velocity of a rolling wheel, \\(\u03c9=v/r\\), radians appear in the units of \\(\u03c9\\) but not on the right hand side. Anthony French calls this phenomenon \"a perennial problem in the teaching of mechanics\". Oberhofer says that the typical advice of ignoring radians during dimensional analysis and adding or removing radians in units according to convention and contextual knowledge is \"pedagogically unsatisfying\".
At least a dozen scientists have made proposals to treat the radian as a base unit of measure defining its own dimension of \"angle\", as early as 1936 and as recently as 2022. This would bring the advantages of a physics-based, consistent, and logically-robust unit system, with unambiguous units for all physical quantities. At the same time the only notable changes for typical end-users would be: improved units for the quantities torque, angular momentum, and moment of inertia.
Paul Quincey in his proposal \"Angles in the SI: a detailed proposal for solving the problem\" states:
Paul Quincey: Angles in the SI: a detailed proposal for solving the problem
The familiar units assigned to some angular quantities are based on equations that have adopted the radian convention, and so are missing rads that would be present if the complete equation is used. The physically-correct units are those with the rads reinstated. Numerical values would not change, and the physical meanings of all quantities would also be unaffected.
He proposes the following changes:
The SI units for
The option to omit the radian from the SI units for angle, angular velocity, angular frequency, angular acceleration, and angular wavenumber would be removed, the only correct SI units being \\(rad\\), \\(rad/s\\), \\(rad/s\\), \\(rad/s^2\\) and \\(rad/m\\) respectively.
Paul Quincey summarizes that with the above in action:
Paul Quincey: Angles in the SI: a detailed proposal for solving the problem
However, the physical clarity this would build into the SI should be recognised very quickly. The units would tell us that \\(torque \\times angle = energy\\), and \\(angular\\:momentum \\times angle = action\\), for example, in the same way that they do for \\(force \\times distance = energy\\), \\(linear\\:momentum \\times distance = action\\), and \\(radiant\\:intensity \\times solid\\:angle = radiant\\:flux\\). Dimensional analysis could be used to its full extent. Software involving angular quantities would be rationalised. Arguments about the correct units for frequency and angular frequency, and the meaning of the unit \\(Hz\\), could be left behind. The explanation of these changes would be considerably easier and more rewarding than explaining how a kilogram-sized mass can be measured in terms of the Planck constant.
"},{"location":"users_guide/systems/strong_angular_system/#angular-quantities-in-the-si","title":"Angular quantities in the SI","text":"Even though the SI somehow ignores the dimensionality of angle:
SI Brochure
Plane and solid angles, when expressed in radians and steradians respectively, are in effect also treated within the SI as quantities with the unit one. The symbols \\(rad\\) and \\(sr\\) are written explicitly where appropriate, in order to emphasize that, for radians or steradians, the quantity being considered is, or involves the plane angle or solid angle respectively. For steradians it emphasizes the distinction between units of flux and intensity in radiometry and photometry for example. However, it is a long-established practice in mathematics and across all areas of science to make use of \\(rad = 1\\) and \\(sr = 1\\). For historical reasons the radian and steradian are treated as derived units.
It also explicitly states:
SI Brochure
The SI unit of frequency is hertz, the SI unit of angular velocity and angular frequency is radian per second, and the SI unit of activity is becquerel, implying counts per second. Although it is formally correct to write all three of these units as the reciprocal second, the use of the different names emphasizes the different nature of the quantities concerned. It is especially important to carefully distinguish frequencies from angular frequencies, because by definition their numerical values differ by a factor of \\(2\\pi\\). Ignoring this fact may cause an error of \\(2\\pi\\). Note that in some countries, frequency values are conventionally expressed using \u201ccycle/s\u201d or \u201ccps\u201d instead of the SI unit \\(Hz\\), although \u201ccycle\u201d and \u201ccps\u201d are not units in the SI. Note also that it is common, although not recommended, to use the term frequency for quantities expressed in \\(rad/s\\). Because of this, it is recommended that quantities called \u201cfrequency\u201d, \u201cangular frequency\u201d, and \u201cangular velocity\u201d always be given explicit units of \\(Hz\\) or \\(rad/s\\) and not \\(s^{-1}\\).
"},{"location":"users_guide/systems/strong_angular_system/#strong-angular-extensions-in-the-library","title":"Strong Angular extensions in the library","text":"The mp-units library strives to define physically-correct quantities and their units to provide maximum help to its users. As treating angle as a dimensional quantity can lead to many \"trivial\" mistakes in dimensional analysis and calculation, it was decided to provide additional experimental systems of quantities and units that follow the above approach and treat angle as a base quantity with a base unit of radian and solid angle as its derived quantity.
As those (at least for now) are not a part of SI, the plain angle and solid angle definitions can be found in a dedicated angular system. Those definitions are also used in the isq_angle system of quantities to make the recipes for angle-based quantities like torque or angular velocity physically correct:
using namespace mp_units;\nusing namespace mp_units::si::unit_symbols;\nusing mp_units::angular::unit_symbols::deg;\nusing mp_units::angular::unit_symbols::rad;\n\nconst quantity lever = isq_angle::position_vector(20 * cm);\nconst quantity force = isq_angle::force(500 * N);\nconst quantity angle = isq_angle::angular_measure(90. * deg);\nconst quantity torque = isq_angle::torque(lever * force * angular::sin(angle) / (1 * isq_angle::cotes_angle));\n\nstd::cout << \"Applying a perpendicular force of \" << force << \" to a \" << lever << \" long lever results in \"\n << torque.in(N * m / rad) << \" of torque.\\n\";\nThe above program prints:
Applying a perpendicular force of 500 N to a 20 cm long lever results in 100 N m/rad of torque.\nNote
cotes_angle is a constant which represents an angle with the value of exactly 1 radian. You can find more information about this constant in Quincey.
Try it on Compiler Explorer
"},{"location":"users_guide/use_cases/interoperability_with_other_libraries/","title":"Interoperability with Other Libraries","text":"mp-units makes it easy to cooperate with similar entities of other libraries. No matter if we want to provide interoperability with a simple home-grown strongly typed wrapper type (e.g., Meter, Timestamp, ...) or with a feature-rich quantities and units library, we have to provide specializations of:
quantity_like_traits for external quantity-like type,quantity_point_like_traits for external quantity_point-like type.Before we delve into the template specialization details, let's first decide if we want the conversions to happen implicitly or if explicit ones would be a better choice. Or maybe the conversion should be implicit in one direction only (e.g., into mp-units abstractions) while the explicit conversions in the other direction should be preferred?
There is no one unified answer to the above questions. Everything depends on the use case.
Typically, the implicit conversions are allowed in cases where:
In all other scenarios, we should probably enforce explicit conversions.
The kinds of inter-library conversions can be easily configured in partial specializations of conversion traits in the mp-units library. To require an explicit conversion, the return type of the conversion function should be wrapped in convert_explicitly<T>. Otherwise, convert_implicitly<T> should be used.
For example, let's assume that some company has its own Meter strong-type wrapper:
struct Meter {\n int value;\n};\nAs every usage of Meter is at least as good and safe as the usage of quantity<si::metre, int>, and as there is no significant runtime performance penalty, we would like to allow the conversion to mp_units::quantity to happen implicitly.
On the other hand, the quantity type is much safer than the Meter, and that is why we would prefer to see the opposite conversions stated explicitly in our code.
To enable such interoperability, we must define a partial specialization of the quantity_like_traits<T> type trait. Such specialization should provide:
reference that provides the quantity reference (e.g., unit),rep type that specifies the underlying storage type,to_numerical_value(T) static member function returning a quantity's raw value of rep type packed in either convert_explicitly or convert_implicitly wrapper.from_numerical_value(rep) static member function returning T packed in either convert_explicitly or convert_implicitly wrapper.For example, for our Meter type, we could provide the following:
template<>\nstruct mp_units::quantity_like_traits<Meter> {\n static constexpr auto reference = si::metre;\n using rep = decltype(Meter::value);\n static constexpr convert_implicitly<rep> to_numerical_value(Meter m) { return m.value; }\n static constexpr convert_explicitly<Meter> from_numerical_value(rep v) { return Meter{v}; }\n};\nAfter that, we can check that the QuantityLike concept is satisfied:
static_assert(mp_units::QuantityLike<Meter>);\nand we can write the following:
void print(Meter m) { std::cout << m.value << \" m\\n\"; }\n\nint main()\n{\n using namespace mp_units;\n using namespace mp_units::si::unit_symbols;\n\n Meter height{42};\n\n // implicit conversions\n quantity h1 = height;\n quantity<isq::height[m], int> h2 = height;\n\n std::cout << h1 << \"\\n\";\n std::cout << h2 << \"\\n\";\n\n // explicit conversions\n print(Meter(h1));\n print(Meter(h2));\n}\nNote
No matter if we decide to use implicit or explicit conversions, the mp-units will not allow unsafe operations to happen.
If we extend the above example with unsafe conversions, the code will not compile, and we will have to fix the issues first before the conversion may be performed:
UnsafeFixedquantity<isq::height[m]> h3 = height;\nquantity<isq::height[mm], int> h4 = height;\nquantity<isq::height[km], int> h5 = height; // Compile-time error (1)\n\nstd::cout << h3 << \"\\n\";\nstd::cout << h4 << \"\\n\";\nstd::cout << h5 << \"\\n\";\n\nprint(Meter(h3)); // Compile-time error (2)\nprint(Meter(h4)); // Compile-time error (3)\nprint(Meter(h5));\ndouble to int is not value-preserving.quantity<isq::height[m]> h3 = height;\nquantity<isq::height[mm], int> h4 = height;\nquantity<isq::height[km], int> h5 = quantity{height}.force_in(km);\n\nstd::cout << h3 << \"\\n\";\nstd::cout << h4 << \"\\n\";\nstd::cout << h5 << \"\\n\";\n\nprint(Meter(value_cast<int>(h3)));\nprint(Meter(h4.force_in(m)));\nprint(Meter(h5));\nTo play with quantity point conversions, let's assume that we have a Timestamp strong type in our codebase, and we would like to start using mp-units to work with this abstraction.
struct Timestamp {\n int seconds;\n};\nAs we described in The Affine Space chapter, timestamps should be modeled as quantity points rather than regular quantities.
To allow the conversion between our custom Timestamp type and the quantity_point class template we need to provide the following in the partial specialization of the quantity_point_like_traits<T> type trait:
reference that provides the quantity point reference (e.g., unit),point_origin that specifies the absolute point, which is the beginning of our measurement scale for our points,rep type that specifies the underlying storage type,to_numerical_value(T) static member function returning a raw value of the quantity being the offset of the point from the origin packed in either convert_explicitly or convert_implicitly wrapper.from_numerical_value(rep) static member function returning T packed in either convert_explicitly or convert_implicitly wrapper.For example, for our Timestamp type, we could provide the following:
template<>\nstruct mp_units::quantity_point_like_traits<Timestamp> {\n static constexpr auto reference = si::second;\n static constexpr auto point_origin = default_point_origin(reference);\n using rep = decltype(Timestamp::seconds);\n static constexpr convert_implicitly<rep> to_numerical_value(Timestamp ts) { return ts.seconds; }\n static constexpr convert_explicitly<Timestamp> from_numerical_value(rep v) { return Timestamp(v); }\n};\nAfter that, we can check that the QuantityPointLike concept is satisfied:
static_assert(mp_units::QuantityPointLike<Timestamp>);\nand we can write the following:
void print(Timestamp ts) { std::cout << ts.seconds << \" s\\n\"; }\n\nint main()\n{\n using namespace mp_units;\n using namespace mp_units::si::unit_symbols;\n\n Timestamp ts{42};\n\n // implicit conversion\n quantity_point qp = ts;\n\n std::cout << qp.quantity_from_zero() << \"\\n\";\n\n // explicit conversion\n print(Timestamp(qp));\n}\nIn the C++ standard library, we have two types that handle quantities and model the affine space. Those are:
std::chrono::duration - specifies quantities of time,std::chrono::time_point - specifies quantity points of time.The mp-units library comes with built-in interoperability with those types. It is enough to include the mp-units/systems/si/chrono.h file to benefit from it. This file provides:
quantity_like_traits and quantity_point_like_traits that provide support for implicit conversions between std and mp_units types in both directions,chrono_point_origin<Clock> point origin for std clocks,to_chrono_duration and to_chrono_time_point dedicated conversion functions that result in types exactly representing mp-units abstractions.Important
Only a quantity_point that uses chrono_point_origin<Clock> as its origin can be converted to the std::chrono abstractions:
inline constexpr struct ts_origin final : relative_point_origin<chrono_point_origin<system_clock> + 1 * h> {} ts_origin;\ninline constexpr struct my_origin final : absolute_point_origin<isq::time> {} my_origin;\n\nquantity_point qp1 = sys_seconds{1s};\nauto tp1 = to_chrono_time_point(qp1); // OK\n\nquantity_point qp2 = chrono_point_origin<system_clock> + 1 * s;\nauto tp2 = to_chrono_time_point(qp2); // OK\n\nquantity_point qp3 = ts_origin + 1 * s;\nauto tp3 = to_chrono_time_point(qp3); // OK\n\nquantity_point qp4 = my_origin + 1 * s;\nauto tp4 = to_chrono_time_point(qp4); // Compile-time Error (1)\n\nquantity_point qp5{1 * s};\nauto tp5 = to_chrono_time_point(qp5); // Compile-time Error (2)\nmy_origin is not defined in terms of chrono_point_origin<Clock>.zeroth_point_origin is not defined in terms of chrono_point_origin<Clock>.Here is an example of how interoperability described in this chapter can be used in practice:
using namespace std::chrono;\n\nsys_seconds ts_now = floor<seconds>(system_clock::now());\n\nquantity_point start_time = ts_now;\nquantity speed = 925. * km / h;\nquantity distance = 8111. * km;\nquantity flight_time = distance / speed;\nquantity_point exp_end_time = start_time + flight_time;\n\nsys_seconds ts_end = value_cast<int>(exp_end_time.in(s));\n\nauto curr_time = zoned_time(current_zone(), ts_now);\nauto mst_time = zoned_time(\"America/Denver\", ts_end);\n\nstd::cout << \"Takeoff: \" << curr_time << \"\\n\";\nstd::cout << \"Landing: \" << mst_time << \"\\n\";\nThe above may print the following output:
Takeoff: 2023-11-18 13:20:54 UTC\nLanding: 2023-11-18 15:07:01 MST\nThe mp-units allows us to implement nice and terse code targeting a specific C++ version and configuration. Such code is easy to write and understand but might not be portable to some older environments.
However, sometimes, we want to develop code that can be compiled on a wide range of various compilers and configurations. This is why the library also exposes and uses special preprocessor macros that can be used to ensure the wide compatibility of our code.
Note
Those macros are used in our short example applications as those are meant to be built on all of the supported compilers. Some still do not support std::format, C++ modules, or C++ versions newer than C++20.
Depending on your compiler's conformance, you can choose to use any of the below styles to write your code using mp-units:
C++23C++20C++20 with header filesC++20 with header files + libfmtWide Compatibility#include <format>\n#include <iostream>\nimport mp_units;\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n#include <format>\n#include <iostream>\nimport mp_units;\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <format>\n#include <iostream>\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << std::format(...) << \"\\n\";\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#include <fmt/format.h>\n#include <iostream>\n\n// ...\n\ninline constexpr struct horizontal_length final : quantity_spec<horizontal_length, isq::length> {} horizontal_length;\n\n// ...\n\nstd::cout << fmt::format(...) << \"\\n\";\n#include <iostream>\n#include <mp-units/ext/format.h>\n#ifdef MP_UNITS_MODULES\n#include <mp-units/compat_macros.h>\nimport mp_units;\n#else\n#include <mp-units/format.h>\n#include <mp-units/ostream.h>\n#include <mp-units/systems/international.h>\n#include <mp-units/systems/isq.h>\n#include <mp-units/systems/si.h>\n#endif\n\n// ...\n\nQUANTITY_SPEC(horizontal_length, isq::length);\n\n// ...\n\nstd::cout << MP_UNITS_STD_FMT::format(...) << \"\\n\";\nTip
Depending on your preferences, you can either write:
This chapter describes only the most essential tools the mp-units users need. All the compatibility macros can be found in the mp-units/compat_macros.h header file.
Tip
The mp-units/compat_macros.h header file is implicitly included when we use \"legacy\" headers in our translation units. However, it has to be explicitly included when we use C++20 modules, as those do not propagate preprocessor macros.
"},{"location":"users_guide/use_cases/wide_compatibility/#QUANTITY_SPEC","title":"QUANTITY_SPEC(name, ...)","text":"Quantity specification definitions benefit from an explicit object parameter added in C++23 to remove the need for CRTP idiom, which significantly simplifies the code.
This macro benefits from the new C++23 feature if available. Otherwise, it uses the CRTP idiom under the hood.
"},{"location":"users_guide/use_cases/wide_compatibility/#mp_units_std_fmt","title":"MP_UNITS_STD_FMT","text":"Some of the supported compilers do not support std::format and related tools. Also, despite using a conformant compiler, some projects still choose to use fmtlib as their primary formatting facility (e.g., to benefit from additional features provided with the library).
This macro resolves to either the std or fmt namespace, depending on the value of MP_UNITS_API_STD_FORMAT CMake option.
To include the header files of the underlying text formatting framework, the following include should be used:
#include <mp-units/ext/format.h>\nThe mp-units library internally does contract checking by default. It can be disabled with a Conan or CMake option. However, when enabled, it can use either gsl-lite or ms-gsl. To write a code that is independent from the underlying framework, the following preprocessor macros are exposed:
MP_UNITS_EXPECTS(expr)MP_UNITS_EXPECTS_DEBUG(expr)MP_UNITS_ASSERT(expr)MP_UNITS_ASSERT_DEBUG(expr)Their meaning is consistent with respective gsl-lite.
Also, to include the header files of the underlying framework, the following include should be used:
#include <mp-units/ext/contracts.h>\nIn case we are working with a legacy/unsafe interface, we may need to extract the numerical value of a quantity and pass it to some third-party legacy unsafe interfaces.
In such situations we can use .numerical_value_in(Unit) member function:
void legacy_check_speed_limit(int speed_in_km_per_h);\nlegacy_check_speed_limit((180 * km / (2 * h)).numerical_value_in(km / h));\nSuch a getter will explicitly enforce the usage of a correct unit required by the underlying interface, which reduces a significant number of safety-related issues.
The above code will not compile in case value truncation may happen. To solve the issue, we need to either use a value-preserving representation type or force the truncating conversion with .force_numerical_value_in(Unit):
legacy_check_speed_limit((140 * mi / (2 * h)).force_numerical_value_in(km / h));\nThe getters mentioned above always return by value as a quantity value conversion may be required to adjust it to the target unit. In case a user needs a reference to the underlying storage .numerical_value_ref_in(Unit) should be used:
void legacy_set_speed_limit(int* speed_in_km_per_h) { *speed_in_km_per_h = 100; }\nquantity<km / h, int> speed_limit;\nlegacy_set_speed_limit(&speed_limit.numerical_value_ref_in(km / h));\nThis member function again requires a target unit to enforce safety. This overload does not participate in overload resolution if the provided unit has a different scaling factor than the current one.
"},{"location":"blog/archive/2024/","title":"2024","text":""},{"location":"blog/archive/2023/","title":"2023","text":""},{"location":"blog/category/wg21/","title":"WG21","text":""},{"location":"blog/category/releases/","title":"Releases","text":""},{"location":"users_guide/examples/tags_index/","title":"Tags Index","text":"Note
mp-units usage example applications are meant to be built on all of the supported compilers. This is why they benefit from the Wide Compatibility mode.
Tip
All usage examples in this chapter are categorized with appropriate tags to simplify navigation and search of relevant code. You can either read all the examples one-by-one in the order provided by the documentation authors or, thanks to the tagging system, jump straight to the example that is the most interesting for you.
"},{"location":"users_guide/examples/tags_index/#cgs-system","title":"CGS System","text":"avg_speed12
13
14
-15#include <exception>
-#include <iostream>
-#ifdef MP_UNITS_MODULES
-import mp_units;
-#else
-#include <mp-units/ostream.h>
-#include <mp-units/systems/cgs.h>
-#include <mp-units/systems/international.h>
-#include <mp-units/systems/isq.h>
-#include <mp-units/systems/si.h>
-#endif
-
-namespace {
-
-using namespace mp_units;
+15#ifdef MP_UNITS_IMPORT_STD
+import std;
+#else
+#include <exception>
+#include <iostream>
+#endif
+#ifdef MP_UNITS_MODULES
+import mp_units;
+#else
+#include <mp-units/ostream.h>
+#include <mp-units/systems/cgs.h>
+#include <mp-units/systems/international.h>
+#include <mp-units/systems/isq.h>
+#include <mp-units/systems/si.h>
+#endif
Next, we define two functions calculating average speed based on quantities of fixed units and integral and floating-point representation types, respectively, and a third function @@ -2140,22 +2140,20 @@
avg_speed26
27
28
-29
-30constexpr quantity<si::metre / si::second, int> fixed_int_si_avg_speed(quantity<si::metre, int> d,
- quantity<si::second, int> t)
-{
- return d / t;
-}
-
-constexpr quantity<si::metre / si::second> fixed_double_si_avg_speed(quantity<si::metre> d, quantity<si::second> t)
-{
- return d / t;
-}
-
-constexpr QuantityOf<isq::speed> auto avg_speed(QuantityOf<isq::length> auto d, QuantityOf<isq::time> auto t)
-{
- return d / t;
-}
+29namespace {
+
+using namespace mp_units;
+
+constexpr quantity<si::metre / si::second, int> fixed_int_si_avg_speed(quantity<si::metre, int> d,
+ quantity<si::second, int> t)
+{
+ return d / t;
+}
+
+constexpr quantity<si::metre / si::second> fixed_double_si_avg_speed(quantity<si::metre> d, quantity<si::second> t)
+{
+ return d / t;
+}
We also added a simple utility to print our results:
| avg_speed.cpp | ||
|---|---|---|
| ||
Now, let's analyze how those three utility functions behave with different sets of arguments. First, we are going to use quantities of SI units and integral representation:
@@ -2187,22 +2185,20 @@avg_speed48
49
50
-51
-52void example()
-{
- using namespace mp_units::si::unit_symbols;
+51 std::cout << "Average speed of a car that makes " << distance << " in " << duration << " is " << result_in_kmph
+ << ".\n";
+}
- // SI (int)
- {
- constexpr auto distance = 220 * km;
- constexpr auto duration = 2 * h;
-
- std::cout << "SI units with 'int' as representation\n";
-
- print_result(distance, duration, fixed_int_si_avg_speed(distance, duration));
- print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
- print_result(distance, duration, avg_speed(distance, duration));
- }
+void example()
+{
+ using namespace mp_units::si::unit_symbols;
+
+ // SI (int)
+ {
+ constexpr auto distance = 220 * km;
+ constexpr auto duration = 2 * h;
+
+ std::cout << "SI units with 'int' as representation\n";
The above provides the following output:
// SI (double)
- {
- constexpr auto distance = 220. * km;
- constexpr auto duration = 2. * h;
-
- std::cout << "\nSI units with 'double' as representation\n";
-
- // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed
- print_result(distance, duration, fixed_int_si_avg_speed(value_cast<int>(distance), value_cast<int>(duration)));
- print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
- print_result(distance, duration, avg_speed(distance, duration));
- }
+64 print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
+ print_result(distance, duration, avg_speed(distance, duration));
+ }
+
+ // SI (double)
+ {
+ constexpr auto distance = 220. * km;
+ constexpr auto duration = 2. * h;
+
+ std::cout << "\nSI units with 'double' as representation\n";
+
+ // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed
Conversion from floating-point to integral representation types is considered value-truncating @@ -2285,38 +2281,40 @@
avg_speed93
94
95
-96 print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
+ print_result(distance, duration, avg_speed(distance, duration));
+ }
- constexpr auto distance = 140 * mi;
- constexpr auto duration = 2 * h;
-
- std::cout << "\nInternational mile with 'int' as representation\n";
-
- // it is not possible to make a lossless conversion of miles to meters on an integral type
- // (explicit cast needed)
- print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));
- print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
- print_result(distance, duration, avg_speed(distance, duration));
- }
-
- // International mile (double)
- {
- using namespace mp_units::international::unit_symbols;
+ // International mile (int)
+ {
+ using namespace mp_units::international::unit_symbols;
+
+ constexpr auto distance = 140 * mi;
+ constexpr auto duration = 2 * h;
+
+ std::cout << "\nInternational mile with 'int' as representation\n";
+
+ // it is not possible to make a lossless conversion of miles to meters on an integral type
+ // (explicit cast needed)
+ print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));
+ print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
+ print_result(distance, duration, avg_speed(distance, duration));
+ }
- constexpr auto distance = 140. * mi;
- constexpr auto duration = 2. * h;
-
- std::cout << "\nInternational mile with 'double' as representation\n";
-
- // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed
- // also it is not possible to make a lossless conversion of miles to meters on an integral type
- // (explicit cast needed)
- print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));
- print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
- print_result(distance, duration, avg_speed(distance, duration));
- }
+ // International mile (double)
+ {
+ using namespace mp_units::international::unit_symbols;
+
+ constexpr auto distance = 140. * mi;
+ constexpr auto duration = 2. * h;
+
+ std::cout << "\nInternational mile with 'double' as representation\n";
+
+ // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed
+ // also it is not possible to make a lossless conversion of miles to meters on an integral type
+ // (explicit cast needed)
+ print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));
One important difference here is the fact that as it is not possible to make a lossless conversion of miles to meters on a quantity using an integral representation type, so this time, we need a @@ -2364,37 +2362,37 @@
avg_speed124
125
126
-127 {
- constexpr auto distance = 22'000'000 * cgs::centimetre;
- constexpr auto duration = 7200 * cgs::second;
-
- std::cout << "\nCGS units with 'int' as representation\n";
-
- // it is not possible to make a lossless conversion of centimeters to meters on an integral type
- // (explicit cast needed)
- print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));
- print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
- print_result(distance, duration, avg_speed(distance, duration));
- }
-
- // CGS (double)
- {
- constexpr auto distance = 22'000'000. * cgs::centimetre;
- constexpr auto duration = 7200. * cgs::second;
-
- std::cout << "\nCGS units with 'double' as representation\n";
-
- // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed
- // it is not possible to make a lossless conversion of centimeters to meters on an integral type
- // (explicit cast needed)
- print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));
-
- print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
- print_result(distance, duration, avg_speed(distance, duration));
- }
-}
-
-} // namespace
+127 print_result(distance, duration, avg_speed(distance, duration));
+ }
+
+ // CGS (int)
+ {
+ constexpr auto distance = 22'000'000 * cgs::centimetre;
+ constexpr auto duration = 7200 * cgs::second;
+
+ std::cout << "\nCGS units with 'int' as representation\n";
+
+ // it is not possible to make a lossless conversion of centimeters to meters on an integral type
+ // (explicit cast needed)
+ print_result(distance, duration, fixed_int_si_avg_speed(distance.force_in(m), duration));
+ print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
+ print_result(distance, duration, avg_speed(distance, duration));
+ }
+
+ // CGS (double)
+ {
+ constexpr auto distance = 22'000'000. * cgs::centimetre;
+ constexpr auto duration = 7200. * cgs::second;
+
+ std::cout << "\nCGS units with 'double' as representation\n";
+
+ // conversion from a floating-point to an integral type is a truncating one so an explicit cast is needed
+ // it is not possible to make a lossless conversion of centimeters to meters on an integral type
+ // (explicit cast needed)
+ print_result(distance, duration, fixed_int_si_avg_speed(value_cast<m, int>(distance), value_cast<int>(duration)));
+
+ print_result(distance, duration, fixed_double_si_avg_speed(distance, duration));
+ print_result(distance, duration, avg_speed(distance, duration));
Again, we observe value_cast being used in the same places and consistent truncation errors
in the text output:
avg_speed134
135
136
-137hello_units10
11
12
-13#include <mp-units/compat_macros.h>
#include <mp-units/ext/format.h>
-#include <iomanip>
-#include <iostream>
-#ifdef MP_UNITS_MODULES
-import mp_units;
-#else
-#include <mp-units/format.h>
-#include <mp-units/ostream.h>
-#include <mp-units/systems/international.h>
-#include <mp-units/systems/isq.h>
-#include <mp-units/systems/si.h>
-#endif
+#ifdef MP_UNITS_IMPORT_STD
+import std;
+#else
+#include <iomanip>
+#include <iostream>
+#endif
+#ifdef MP_UNITS_MODULES
+import mp_units;
+#else
+#include <mp-units/format.h>
+#include <mp-units/ostream.h>
+#include <mp-units/systems/international.h>
Also, to shorten the definitions, we "import" all the symbols from the mp_units namespace.
| hello_units.cpp | |||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
The above lines explicitly opt into using unit symbols from two systems of units. As this introduces a lot of short identifiers into the current scope, it is not done @@ -2156,13 +2156,13 @@
| | ||||||||||||
23 & 24 create a quantity of kind isq::length / isq::time with the numbers
@@ -2189,14 +2189,22 @@ hello_units34
35
36
-37 std::cout << v1 << '\n'; // 110 km/h
- std::cout << std::setw(10) << std::setfill('*') << v2 << '\n'; // ***70 mi/h
- std::cout << MP_UNITS_STD_FMT::format("{:*^10}\n", v3); // *110 km/h*
- std::cout << MP_UNITS_STD_FMT::format("{:%N in %U of %D}\n", v4); // 70 in mi/h of LT⁻¹
- std::cout << MP_UNITS_STD_FMT::format("{::N[.2f]}\n", v5); // 30.56 m/s
- std::cout << MP_UNITS_STD_FMT::format("{::N[.2f]U[dn]}\n", v6); // 31.29 m⋅s⁻¹
- std::cout << MP_UNITS_STD_FMT::format("{:%N}\n", v7); // 31
-}
+37
+38
+39
+40
+41 constexpr quantity v5 = v3.in(m / s);
+ constexpr quantity v6 = value_cast<m / s>(v4);
+ constexpr quantity v7 = value_cast<int>(v6);
+
+ std::cout << v1 << '\n'; // 110 km/h
+ std::cout << std::setw(10) << std::setfill('*') << v2 << '\n'; // ***70 mi/h
+ std::cout << MP_UNITS_STD_FMT::format("{:*^10}\n", v3); // *110 km/h*
+ std::cout << MP_UNITS_STD_FMT::format("{:%N in %U of %D}\n", v4); // 70 in mi/h of LT⁻¹
+ std::cout << MP_UNITS_STD_FMT::format("{::N[.2f]}\n", v5); // 30.56 m/s
+ std::cout << MP_UNITS_STD_FMT::format("{::N[.2f]U[dn]}\n", v6); // 31.29 m⋅s⁻¹
+ std::cout << MP_UNITS_STD_FMT::format("{:%N}\n", v7); // 31
+}
The above presents various ways to print a quantity.
Both stream insertion operations and std::format facilities are supported.
si_constants12
13#include <mp-units/compat_macros.h>
#include <mp-units/ext/format.h>
-#include <iostream>
-#ifdef MP_UNITS_MODULES
-import mp_units;
-#else
-#include <mp-units/format.h>
-#include <mp-units/systems/si.h>
-#endif
-
-template<class T>
- requires mp_units::is_scalar<T>
-inline constexpr bool mp_units::is_vector<T> = true;
+#ifdef MP_UNITS_IMPORT_STD
+import std;
+#else
+#include <iostream>
+#endif
+#ifdef MP_UNITS_MODULES
+import mp_units;
+#else
+#include <mp-units/format.h>
+#include <mp-units/systems/si.h>
+#endif
As always, we start with the inclusion of all the needed header files. After that, for the simplicity of this example, we @@ -2138,30 +2138,38 @@
si_constants34
35
36
-37int main()
-{
- using namespace mp_units;
- using namespace mp_units::si;
- using namespace mp_units::si::unit_symbols;
-
- std::cout << "The seven defining constants of the SI and the seven corresponding units they define:\n";
- std::cout << MP_UNITS_STD_FMT::format("- hyperfine transition frequency of Cs: {} = {::N[.0]}\n",
- 1. * si2019::hyperfine_structure_transition_frequency_of_cs,
- (1. * si2019::hyperfine_structure_transition_frequency_of_cs).in(Hz));
- std::cout << MP_UNITS_STD_FMT::format("- speed of light in vacuum: {} = {::N[.0]}\n",
- 1. * si2019::speed_of_light_in_vacuum,
- (1. * si2019::speed_of_light_in_vacuum).in(m / s));
- std::cout << MP_UNITS_STD_FMT::format("- Planck constant: {} = {::N[.8e]}\n",
- 1. * si2019::planck_constant, (1. * si2019::planck_constant).in(J * s));
- std::cout << MP_UNITS_STD_FMT::format("- elementary charge: {} = {::N[.9e]}\n",
- 1. * si2019::elementary_charge, (1. * si2019::elementary_charge).in(C));
- std::cout << MP_UNITS_STD_FMT::format("- Boltzmann constant: {} = {::N[.6e]}\n",
- 1. * si2019::boltzmann_constant, (1. * si2019::boltzmann_constant).in(J / K));
- std::cout << MP_UNITS_STD_FMT::format("- Avogadro constant: {} = {::N[.8e]}\n",
- 1. * si2019::avogadro_constant, (1. * si2019::avogadro_constant).in(one / mol));
- std::cout << MP_UNITS_STD_FMT::format("- luminous efficacy: {} = {}\n",
- 1. * si2019::luminous_efficacy, (1. * si2019::luminous_efficacy).in(lm / W));
-}
+37
+38
+39
+40
+41template<class T>
+ requires mp_units::is_scalar<T>
+inline constexpr bool mp_units::is_vector<T> = true;
+
+int main()
+{
+ using namespace mp_units;
+ using namespace mp_units::si;
+ using namespace mp_units::si::unit_symbols;
+
+ std::cout << "The seven defining constants of the SI and the seven corresponding units they define:\n";
+ std::cout << MP_UNITS_STD_FMT::format("- hyperfine transition frequency of Cs: {} = {::N[.0]}\n",
+ 1. * si2019::hyperfine_structure_transition_frequency_of_cs,
+ (1. * si2019::hyperfine_structure_transition_frequency_of_cs).in(Hz));
+ std::cout << MP_UNITS_STD_FMT::format("- speed of light in vacuum: {} = {::N[.0]}\n",
+ 1. * si2019::speed_of_light_in_vacuum,
+ (1. * si2019::speed_of_light_in_vacuum).in(m / s));
+ std::cout << MP_UNITS_STD_FMT::format("- Planck constant: {} = {::N[.8e]}\n",
+ 1. * si2019::planck_constant, (1. * si2019::planck_constant).in(J * s));
+ std::cout << MP_UNITS_STD_FMT::format("- elementary charge: {} = {::N[.9e]}\n",
+ 1. * si2019::elementary_charge, (1. * si2019::elementary_charge).in(C));
+ std::cout << MP_UNITS_STD_FMT::format("- Boltzmann constant: {} = {::N[.6e]}\n",
+ 1. * si2019::boltzmann_constant, (1. * si2019::boltzmann_constant).in(J / K));
+ std::cout << MP_UNITS_STD_FMT::format("- Avogadro constant: {} = {::N[.8e]}\n",
+ 1. * si2019::avogadro_constant, (1. * si2019::avogadro_constant).in(one / mol));
+ std::cout << MP_UNITS_STD_FMT::format("- luminous efficacy: {} = {}\n",
+ 1. * si2019::luminous_efficacy, (1. * si2019::luminous_efficacy).in(lm / W));
+}
The main part of the example prints all of the SI-defining constants. While analyzing the output of this program (provided below), we can easily notice that a direct printing of the quantity provides