diff --git a/0.3.5/404.html b/0.3.5/404.html new file mode 100644 index 00000000..f0a2dcf8 --- /dev/null +++ b/0.3.5/404.html @@ -0,0 +1,1703 @@ + + + +
+ + + + + + + + + + + + + + + + + + +There are plenty of other open source C++ units libraries, many quite well established. However, +the tradeoffs required to use these libraries can be so significant that many people can’t or won’t +use them. For example: the compiler errors may be inscrutable or overwhelming; the compilation +process may become unacceptably slow; or, the required C++ standard may simply be too new for +a user.
+Au is an accessible, production-tested alternative. We provide a number of rare or outright novel +features, with a small compile time footprint — and we’re compatible with every C++ version back +to the mature and widely available C++14 standard. Key features include:
+Zero
type: novel, fluent handling of construction, comparison, and sign handling for
+ quantities.<iostream>
support.au::
.We’ll consider several of the most prominent alternatives in more detail. While there are many +more libraries, the ones we consider here +are included for being especially pioneering or popular (or both). Here, we list those libraries, +indicate which version we considered, and say a few words about why we included it in the analysis.
+Here’s a more detailed comparison to the alternatives listed above. We’ll use the following +legend1:
+ + +Legend | ++ | Lacks feature / poor support |
+ Fair / basic support |
+ Good / solid support |
+ Best support (of libraries considered here) |
+
---|
These are the first criteria to consider. They will tell you whether you can even use the library +at all, and if so, how hard it will be to obtain.
++ | Boost | +nholthaus | +bernedom/SI | +mp-units | +Au | +
---|---|---|---|---|---|
+
+
+ C++ Version Compatibility+The minimum C++ standard required to use the library. + |
+ C++98 | +C++14 | +C++17 | +C++20 | +C++14 | +
+
+
+ Ease of Acquisition+Ease of including this library in projects using a wide variety of build environments + |
+ Part of boost | +Single, self-contained header | +Available on conan | +Available on conan and vcpkg | +
+ Supports single-header delivery, with features: +
|
+
Note
+These ratings are written with all users and projects in mind. Keep in mind that what +matters for you is your project.
+For example: mp-units gets low accessibility ratings because of its steep C++20 minimum +requirement, and its dependence on a package manager to make the installation easy. However, if +your project is already compatible with C++20, and already uses conan, then these “low” +ratings would be completely irrelevant for you.
+Next: how will this library change the generic developer experience? Leaving aside any library +features, conventions, or implementation strategies, there are two main impacts to developer +experience.
+Your program will take longer to compile, because the compiler is doing more work to produce + essentially the same program.
+You will get more compiler errors that developers will need to understand and fix.
+These costs can bring significant benefits, but we still want them to be as small as possible.
++ | Boost | +nholthaus | +bernedom/SI | +mp-units | +Au | +
---|---|---|---|---|---|
+
+
+ Compilation Speed+The extra time the library adds to compiling a translation unit, compared to no units library. +
|
+ + | Very slow, but can be greatly improved by removing I/O support and most units | ++ | + | Possibly "best", but will need to assess all libraries on the same code | +
+
+
+ Compiler Error Readability++ The ability to understand errors when the library catches a mistake it was + designed to catch. + +
|
+ + + Infamously challenging + + | +Positional dimensions | +Alias for unit template | +
+
|
+
+
|
+
At this point, you’ve assessed:
+Now we’re ready to compare the libraries “as units libraries” — that is, in terms of their core +features.
+Note
+The features are listed, very roughly, in order of importance. Counting up the colors in each +column won’t give an accurate picture. The rows near the top matter more — sometimes, much +more — than the rows further down.
+Of course, what matters the most for you are your use cases and criteria!
++ | Boost | +nholthaus | +bernedom/SI | +mp-units | +Au | +
---|---|---|---|---|---|
+
+
+ Conversion Safety+Guarding against unit conversions that are likely to produce large errors. ++ (For example: we can convert an integer number of feet to inches, but not vice + versa.) + + |
+ + | + Integer Reps unsafe + | ++ Integer Reps unsafe + | +
+ Policy consistent
+ with std::chrono library
+ |
+
+ Meets `std::chrono` baseline, plus:
+
|
+
+
+
+ Unit Safety++ The ability to judge the unit-correctness of every individual line of code + by inspection, in isolation. + +
|
+ + | + | + | Only contains unit-safe interfaces | +Only contains unit-safe interfaces | +
+
+
+ Low Friction+How easy it is to develop with the library. Criteria include: +
|
+
+
|
+
+
|
+
+
|
+
+
|
+
+
|
+
+
+
+ Composability++ The ability to fluently combine the abstractions for units and prefixes to form + new units on the fly. + + |
+
+
|
+ No | +No | +
+
|
+
+
|
+
+
+
+ Unit-aware I/O++ The ability to print quantities along with information about their units. + Examples: + +
|
+
+
|
+
+
|
+
+
|
+
+
|
+
+
|
+
+
+
+ Mixed-Rep Support+The ease of freely mixing different storage types ("Reps") in the same program. + |
+ + | Possible, but user-facing types use a global "preferred" Rep. | ++ | + | + |
+
+
+ Unit-aware math++ Unit-aware versions of common mathematical functions (`max`, `abs`, `sin`, + `round`, and so on). + + |
+
+
|
+
+
|
+ No | +
+
|
+
+
|
+
+
+
+ Generic Dimensions++ The ability to write (template) functions that operate on any dimensionally + consistent inputs. + ++ (For example, a function that takes any length and time quantities, and returns + the appropriate speed quantity.) + + |
+ + Generic + templates, constrained with traits + | ++ Generic + templates, constrained with traits + | +Generic templates, constrained with traits | +Concepts excel here | ++ Currently clunky. Could be better by adding concepts in extra + C++20-only file, without compromising C++14 support. + | +
+
+
+ Extensibility+How easy it is to add new units, dimensions, or systems. + |
+ + Can + add new units and dimensions + | +
+
|
+ Can add new units and dimensions | +Can even handle, e.g., systems of "natural" units | ++ Can add new units + and dimensions + | +
+
+
+ Ease of Migration++ Support for two migration use cases: + +
|
+ No interop with other units libraries | +No interop with other units libraries | +No interop with other units libraries | +
+
|
+
+
|
+
+
+
+ Point Types++ Support for "point-like" quantities, also known as + "affine space + types". + + |
+
+ absolute
+ wrapper for unit
+ |
+ + Optional "offset" for units, but can't distinguish quantity from + point. + | +None; would be hard to add, since units conflated with quantity type | ++ Custom origins really easy to use and compose + | ++ |
+
+
+ Magnitudes++ The features of the representation for different units' sizes. Key features + include: + +
|
+ + Close: lacks only irrationals, basis, and instance arithmetic. Ahead of its time! + | ++ Uses ratio plus "pi powers": good angle handling, but vulnerable to overflow + | +`std::ratio` only, with no solution for pi | ++ Full support for Magnitudes + | ++ Formerly, Au alone was best, but we shared Magnitudes with mp-units + | +
+
+
+ Embedded Friendliness++ Support common embedded use cases. Key examples include: + +
|
+ Assumed to be good, based on mixed-Rep support | +
+ Can trim by excluding <iostream> , but integer-Rep support is poor.
+ |
+
+
|
+ Assumed to be good, based on mixed-Rep support | +
+ Best choice of all:
+
|
+
+
+
+ Abbreviated construction++ The ability to construct a Quantity using the symbol for its unit. + + +
+ This is most commonly done with user-defined literals (UDLs), such as
+ |
+ + | User-defined literals (UDLs) | +User-defined literals (UDLs) | ++ Unit symbols + | ++ + Unit symbols + + | +
+
+
+ Linear algebra++ Good interoperability with matrix and vector libraries, such as Eigen + ++ Most libraries can work with Eigen, but only if Eigen is patched: Quantity types + break several of Eigen's deeply embedded assumptions. + + |
+ + | + | + | + Experimental support for Quantity + Character; can use matrix types as Rep + | ++ Planned to add: #70 + | +
+
+
+ Rep Variety+The range of different storage types ("Reps") permitted. +
|
+ Supports custom numeric types | ++ Effectively floating-point only (integer types unsafe) + | +
+
|
+ + Well defined + Representation + concept + | +
+
|
+
+
+
+ Zero+
+ Quantity support for constructing from, and comparing with, |
+ + Guidance: + use + default constructor to construct, but no special facility for comparison + | +Supports copysign() , but no special construction or comparison |
+ No special construction or comparison | +
+ zero() member |
+
+ Can use ZERO
+ to construct or compare any quantity
+ |
+
+
+
+ Angles++ First-class support for angular quantities, including degrees and radians. + + |
+ + Curiously imprecise + pi + value + | ++ |
+
|
+ Simultaneous support for both strongly-typed and "pure SI" angles | ++ |
+
+
+ Physical constants+
|
+ Includes built-in constants as quantities | +Includes built-in constants as quantities | ++ | + "Faster + than lightspeed" constants + | +
+
|
+
+
+
+ Non-linear scales (such as dB)+Support for logarithmic "units", such as decibels or nepers + |
+ + | + | + | + | + Plan to support someday; see + #41. + | +
+
+
+ "Kind" Types++ Any feature which supports robustly distinguishing between units that have the + same dimension and magnitude. + ++ For example, "hertz" and "becquerel" both have the same dimension and magnitude + as "inverse seconds", but some libraries may prevent users from mixing them. + + |
+ + | + | + | + | No plans at present to support. | +
+
+
+ Explicit Systems of Measurement++ Support for different systems, each with their own (possibly incompatible) + collection of dimensions. + + |
+ + | Single, implicit global system | ++ | + | + Single, implicit global system. (Intentional design tradeoff: reduces learning curve, + and makes compiler errors shorter.) + | +
+
+
+ Abstract Units/Dimensions++ |
+ + | Types exist, but conflated with quantity names | +No separate types for units | +
+
|
+
+
|
+
+
+
+ Macro Usage++ Avoidance of macros, especially in user-facing code. + + |
+ Common in user-facing APIs | +Common in user-facing APIs | +Very few, and confined to implementation helpers | +
+
|
+ No macros | +
Users may have expected a “traffic light” style, green/yellow/red color scheme. However, +these traditional color schemes have poor accessibility for colorblind readers. The present color +scheme was designed to be colorblind-friendly. ↩
+