A compile-time enabled Modern C++ library that provides compile-time dimensional analysis and unit/quantity manipulation.

Overview

GitHub license Conan CI CMake CI GitHub Workflow Documentation Conan stable Conan testing

mp-units - A Units Library for C++

The mp-units library is the subject of ISO standardization for C++23/26. More on this can be found in ISO C++ paper P1935 and CppCon 2020 talk. We are actively looking for parties interested in field trialing the library.

Documentation

An extensive project documentation including installation instructions and user's guide can be found on mp-units GitHub Pages.

TL;DR

mp-units is a compile-time enabled Modern C++ library that provides compile-time dimensional analysis and unit/quantity manipulation. The basic idea and design heavily bases on std::chrono::duration and extends it to work properly with many dimensions.

Here is a small example of possible operations:

#include <units/isq/si/area.h>
#include <units/isq/si/frequency.h>
#include <units/isq/si/length.h>
#include <units/isq/si/speed.h>
#include <units/isq/si/time.h>

using namespace units::isq::si::references;

// simple numeric operations
static_assert(10 * km / 2 == 5 * km);

// unit conversions
static_assert(1 * h == 3600 * s);
static_assert(1 * km + 1 * m == 1001 * m);

// dimension conversions
inline constexpr auto kmph = km / h;
static_assert(1 * km / (1 * s) == 1000 * (m / s));
static_assert(2 * kmph * (2 * h) == 4 * km);
static_assert(2 * km / (2 * kmph) == 1 * h);

static_assert(2 * m * (3 * m) == 6 * m2);

static_assert(10 * km / (5 * km) == 2);

static_assert(1000 / (1 * s) == 1 * kHz);

Try it on the Compiler Explorer.

This library requires some C++20 features (concepts, classes as NTTPs, ...). Thanks to them the user gets a powerful but still easy to use interface and all unit conversions and dimensional analysis can be performed without sacrificing on accuracy. Please see the below example for a quick preview of basic library features:

#include <units/format.h>
#include <units/isq/si/international/length.h>
#include <units/isq/si/international/speed.h>
#include <units/isq/si/length.h>
#include <units/isq/si/speed.h>
#include <units/isq/si/time.h>
#include <units/quantity_io.h>
#include <iostream>

using namespace units::isq;

constexpr Speed auto avg_speed(Length auto d, Time auto t)
{
  return d / t;
}

int main()
{
  using namespace units::isq::si::literals;
  using namespace units::isq::si::references;
  using namespace units::aliases::isq::si::international;

  constexpr Speed auto v1 = 110 * (km / h);
  constexpr Speed auto v2 = mi_per_h(70.);
  constexpr Speed auto v3 = avg_speed(220_q_km, 2_q_h);
  constexpr Speed auto v4 = avg_speed(si::length<si::international::mile>(140), si::time<si::hour>(2));
#if UNITS_DOWNCAST_MODE == 0
  constexpr Speed auto v5 = quantity_cast<si::speed<si::metre_per_second>>(v3);
  constexpr Speed auto v6 = quantity_cast<si::dim_speed, si::metre_per_second>(v4);
#else
  constexpr Speed auto v5 = quantity_cast<si::speed<si::metre_per_second>>(v3);
  constexpr Speed auto v6 = quantity_cast<si::metre_per_second>(v4);
#endif
  constexpr Speed auto v7 = quantity_cast<int>(v6);

  std::cout << v1 << '\n';                                  // 110 km/h
  std::cout << v2 << '\n';                                  // 70 mi/h
  std::cout << fmt::format("{}", v3) << '\n';               // 110 km/h
  std::cout << fmt::format("{:*^14}", v4) << '\n';          // ***70 mi/h****
  std::cout << fmt::format("{:%Q in %q}", v5) << '\n';      // 30.5556 in m/s
  std::cout << fmt::format("{0:%Q} in {0:%q}", v6) << '\n'; // 31.2928 in m/s
  std::cout << fmt::format("{:%Q}", v7) << '\n';            // 31
}

Try it on the Compiler Explorer.

Issues
  • Poll: Dimensionless quantity (quantity of dimension one)

    Poll: Dimensionless quantity (quantity of dimension one)

    ISO 80000-1:2009(E)

    • Quantity for which all the exponents of the factors corresponding to the base quantities in its quantity dimension are zero.
    • The measurement units and values of quantities of dimension one are numbers, but such quantities convey more information than a number.
    • Some quantities of dimension one are defined as the ratios of two quantities of the same kind.

    Assuming:

    auto q1 = quantity<metre, double>() / quantity<metre, double>();
    auto q2 = quantity<second, double>() / quantity<second, double>();
    

    What the result should be?

    (please vote only once by clicking on the correct bar above)

    • Option 1 (current library design)

      static_assert(std::is_same_v<q1, double>);
      static_assert(std::is_same_v<q2, double>);
      auto q = q1 + q2;
      static_assert(std::is_same_v<q, double>);
      
    • Option 2

      static_assert(std::is_same_v<q1::dimension, dimension<>>);
      static_assert(std::is_same_v<q2::dimension, dimension<>>);
      auto q = q1 + q2;
      static_assert(std::is_same_v<q::dimension, dimension<>>);
      
    • Option 3

      static_assert(std::is_same_v<q1::dimension, dimension<exp<base_dim_length, 0>>>);
      static_assert(std::is_same_v<q2::dimension, dimension<exp<base_dim_time, 0>>>);
      // auto q = q1 + q2;  // does not compile
      

      Please note that in such a case:

      auto q1 = 10mps * 2s;     // length
      auto q2 = q1 / 2m;        // dimensionless<length>
      auto q = 10mps * 2s / 2m; // dimensionless<velocity>
      
    help wanted Polls 
    opened by mpusz 46
  • What are the minimum requirements for a standard units library?

    What are the minimum requirements for a standard units library?

    Q: What are the minimum requirements for a standard units library?

    A: Modelling the S.I. system as closely as possible. The way that is implemented is not really relevant. The S.I is a global standard.

    Problem: Unfortunately the general user has no voice on the c++ committee.

    I worked on a quantity /units library for boost since way back in 2003. I need a library that modelled S.I units.

    My original problem was that I was working on an app to design small wind turbines, using doubles for quantities and getting fed up with checking what units each variable was in, which wasted a lot of time. The library I wrote later solved that issue very nicely. All Si units.

    I see that @mpusz started around the same place except for working on a gliding app. All SI units. https://github.com/mpusz/Condor2Nav I understand the motive exactly.

    Again engineering, not Theoretical Physics. All S.I. Units.

    The library that can (apparently) do all that that Theoretical Phyiscists want is now in Boost but what was created there didn't actually elegantly answer a problem for which there was a general need to be solved - modelling the SI. For the general user, Boost.Units it is way to cumbersome and hard to understand and use. It is time to tell the Physicists to go away and fix their Units library on Boost and to produce their own globally recognised standard, before we spend more of the general users time arguing about their exotic needs.

    That theme of a Physicists making impossible demands about their "essential needs" then disappearing once they are met needs to be remembered. General users need SI units more than they need Natural units. Remember there is no global standard for Natural units. Each physicist enjoys showing why their own version is superior. A library for the general user just doesn't need to support that. And we dont have time to argue about it.

    mp-units should drastically limit its scope so that it caters for the average user who uses SI units, not "smart people", language lawyers or physicists, else there is no way it will or should get in to the C++ standard. What is left will be easier to maintain and certainly more likely to write standard documentation for.

    It would be great if mp_units was a general framework but in practise the minimum is that there needs to be the ability to work with SI quantities, that is simple and intuitive to use. Ultimately the standard is about the interface not the implementation.

    It is time to pare away the std units candidate to the bare minimum requirements

    Just model the SI system, following the docs as closely as possible ( so no angle as dimension for example). Stick to same Rep concept as std::chronos::duration. If anyone complains that the Rep type is no good, tell them to provide a solution fixing it for chrono duration.

    opened by kwikius 28
  • Use Magnitude instead of ratio in unit implementations

    Use Magnitude instead of ratio in unit implementations

    This PR doesn't aim to convert every last use case. Rather, the goal is to perform the smallest "reasonable" change such that the repo still builds.

    We bundle a few auxiliary changes which could have been separate PRs, but which I included here to reduce the total time-to-land. To reduce reviewers' cognitive load, I've retained them as separate "checkpoint commits". Reviewers can start at the first commit and step through for ease of reading. These auxiliary changes include:

    • Supporting subtraction and spaceship operators in ratio

    • Implementing the "common Magnitude" functionality, which is equivalent to the "largest even divisor" logic we've borrowed from std::chrono in every applicable case, but which is simpler for Magnitudes

    • Loosening the requirements on the Rep of a Magnitude, which is necessary to maintain support for non-is_arithmetic Reps. NOTE: there is some remaining work here to express everything in terms of treat_as_floating_point, which we can either do in this PR, or later, as reviewers prefer.

    The "bulk" of the PR simply performs fairly mechanical migrations from ratio to as_magnitude<ratio>() in various template arguments. Some corner cases and concepts (e.g., UnitRatio) simply melt away, because we don't need them in a Magnitude-based world. The only "asterisk" in this migration is a few test cases in the formatting, where the current implementation produces an equivalent but different representation. I've commented these out, and we can deal with them later.

    Follow-on work includes:

    • Hunting down remaining uses of ratio in template arguments
    • Removing exp
    • Making degrees and revolutions for angle units

    Partially addresses #300.

    opened by chiphogg 27
  • Added ASCII-only output support

    Added ASCII-only output support

    Dear Mr. Mateusz Pusz,

    Much of C++ template programming with C++20 features is still a bit overwhelming for me at this point in time.

    I do not fully understand how the library is written, but I can rely on what I already know about it and my intuition to understand certain parts. I think I get the gist of it.

    I am using this library for SPICE circuit generation using custom templates. I have generator classes that are responsible for rendering the custom templates into SPICE circuit text.

    Initializing my generator: RCCircuitGenerator generator {5ns, 2ms, 5V, 1ms, 10kR, 10nF};

    The formatting string for the line starting with "RLOAD" (see below) looks like this: RLOAD 1 2 {:%Q%q}

    The following SPICE RC circuit text would be generated:

    RC_CIRCUIT
    .TRAN 5ns 2ms
    VSRC 1 0 PULSE 0 5V 0 0 0 1ms
    RLOAD 1 2 10kΩ
    CCHARGE 2 0 10nF
    .END
    

    However, the SPICE simulator library I am using, ngspice, expect ASCII encoding. The simulation crashes when this circuit is passed to the library.

    With the changes I have provided, when the formatting string for the line starting with "RLOAD" looks like this: RLOAD 1 2 {:%Q%a}

    Then the following SPICE RC circuit text would be generated:

    RC_CIRCUIT
    .TRAN 5ns 2ms
    VSRC 1 0 PULSE 0 5V 0 0 0 1ms
    RLOAD 1 2 10kohm
    CCHARGE 2 0 10nF
    .END
    

    And the SPICE simulation then works.

    I hope that my modifications adhere to the style and philosophy of this library as closely as possible.

    Please let me know of any modifications you would like to me perform first if you would like to merge this pull request eventually.

    Thank you very much.

    Ramzi Sabra

    opened by yasamoka 27
  • Hidden Friends issue

    Hidden Friends issue

    Hidden Friends are good because they help with overload resolution and thus are suggested for usage in a modern C++ design.

    However, for quantity it produces issues with implicit conversions. The second assert of the following code compiles fine even though it shouldn't: https://godbolt.org/z/kSrqHT.

    When non-friend version is used it correctly fails to compile: https://godbolt.org/z/32s4cj

    We could provide template parameters for both arguments of a hidden friend implementation: https://godbolt.org/z/2uMsPB. However, in this case we end up with an ambiguous overload set. So we have to constrain it: https://godbolt.org/z/RKaopR. With this, we achieved what we wanted but with a cost of a more complicated signature.

    Should we provide constrained hidden friend version of the operator or non-friend one with all its overload resolution issues?

    enhancement help wanted 
    opened by mpusz 24
  • Scalar concept should be renamed

    Scalar concept should be renamed

    The 'units::Scalar' concept definition has nothing to do with any external definition of scalar and is very misleading, https://github.com/mpusz/units/blob/master/src/include/units/quantity.h#L63 should be renamed to RegularNotQuantity or something similar especially since Vector is an allowed rep type https://github.com/mpusz/units/blob/master/example/linear_algebra.cpp#L205

    opened by kwikius 21
  • Have you considered to add a dimension-point in the design?

    Have you considered to add a dimension-point in the design?

    std::chrono is based on the difference between a point on the time dimension (time_point) and the difference between two such points, a quantity (a duration for the time dimension).

    Do you plan to add such a dimension-point in your library?

    enhancement question 
    opened by viboes 21
  • Support seamless interop between `ratio` and rational `Magnitude`

    Support seamless interop between `ratio` and rational `Magnitude`

    We provide two new functions, numerator(m) and denominator(m), for a Magnitude m. They fulfill the following conditions:

    1. numerator(m) and denominator(m) are always integer Magnitudes.
    2. If m is rational, then m == numerator(m) / denominator(m).

    If m is not rational, then the numerator and denominator are not especially meaningful (there is no uniquely defined "leftover irrational part"). However, we choose a convention that matches how humans would write a mixed number. For example, sqrt(27/16) would have a numerator of 3, denominator of 4, and a "leftover part" of sqrt(3), matching the "human" way of writing this as [(3 * sqrt(3)) / 4]. This has no use yet, but it may later be useful in printing the Magnitude of an anonymous Unit for end users.

    To further reduce friction for the upcoming migration, we provide a conversion from a Magnitude to a ratio. We restrict this operation to rational Magnitudes, and guard this with a static_assert.

    opened by chiphogg 19
  • Add vector space representation for magnitudes

    Add vector space representation for magnitudes

    This is the beginning of the implementation for #300, laying the first foundations. This seems like a good point to check in and align on direction before we get too far along. For general context:

    Things we include here:

    • Concepts for Magnitude, and BasePower (a Magnitude is made up of a canonicalized parameter pack of BasePowers).
    • End user interfaces for making magnitudes:
      • as_magnitude<ratio>(): the main way to make a Magnitude from a rational number. This handles the "heavy lifting" of converting to a prime factorization.
      • base_power<T>{ratio}: we handle irrational bases by introducing a type T, with a static long double member value which must be positive.
    • Enhanced ratio functionality: addition, negation, and implicit construction.

    Work yet undone:

    • A mechanism for applying a magnitude to a given value. (We'll probably want to break out the rational and irrational parts separately, so we can give exact results as often as possible. We'll also want to think carefully about what types we use in intermediate computations---for example, not everyone will want to use long double, and even double can be problematic for some embedded applications.)
    • Actually migrating existing uses to use Magnitude instead of ratio.

    Once we get to something that looks like the right direction, I can flesh out these other items.

    opened by chiphogg 19
  • Installation issue

    Installation issue

    Hello, I am new to Conan, so maybe that is causing my problem, but I cannot get cmake to run. On line 30 of the top level cmake file there is a command to include a directory that does not exist is the source tree. What is this supposed to point to?

    units/CMakeLists.txt include(common/cmake/tools)

    Here is the directory, so maybe after loading the path do include tools.cmake?

    image

    support 
    opened by LeeRuns 19
  • Poll: UDLs vs constants

    Poll: UDLs vs constants

    The more I think about it the more I think that UDLs may not be the right tool for the job. Yeah, we used it in std::chrono and it seems nice to write auto v = 120km / 2h;. However, they could be replaced with constants. For example:

    namespace si {
    inline namespace unit_constants { // is it a good name?
    
    inline constexpr length<metre> m(1);
    
    }
    }
    

    Here are a few issues that I see with UDLs:

    1. UDLs are only for compile-time known values. Currently with UDLs:

      using namespace units::si;
      auto v1 = 120km / 2h;
      auto v2 = length<kilometre>(length) / time<hour>(duration);
      

      with constants those 2 cases would look like:

      auto v1 = 120 * km / 2 / h;
      auto v2 = length * km / duration / h;
      

      Constants treat both cases in a unified way. It is also worth to notice that we work mostly with runtime variables and compile-time known values appear only in physical constants and unit tests.

    2. UDLs for some units may be impossible to achieve in C++. I already found issues with F (farad), J (joule), W (watt), K (kelvin), d (day), l or L (litre), erg, ergps. It is probably still not the complete list here. All of those problems originated from the fact that those numeric symbols are already used in literals (sometimes compiler extensions but still). I am afraid that at for some of those cases we will not be able to fix it or workaround it in the C++ specification. None of those issues affect constants.

    3. UDLs cannot be disambiguated with the namespace name:

      using namespace si;
      auto d = 1cm;   // quantity<si::dim_length, si::centimetre>
      
      using namespace cgs;
      auto d = 1cm;  // quantity<cgs::dim_length, si::centimetre>
      
      using namespace si;
      using namespace cgs;
      auto d = 1cm;   // FAILS TO COMPILE
      

      With constants it is simple:

      using namespace si;
      using namespace cgs;
      auto d1 = 1 * si::cm;   // quantity<si::dim_length, si::centimetre>
      auto d2 = 1 * cgs::cm;  // quantity<cgs::dim_length, si::centimetre>
      

    So maybe we should prefer constants over UDLs? If so should they be put to an inner inlined namespace (like literals)?

    Let's vote: (please vote only once by clicking on the correct bar above)

    help wanted Polls 
    opened by mpusz 19
  • Can't seem to run tests with updated installation instructions

    Can't seem to run tests with updated installation instructions

    Previously, I had been using a build/ subdirectory as the target for my conan install. The new instructions install directly to the project root, so I removed build/, and followed those.

    Everything... succeeds, apparently. I get no error messages on the install:

    $ conan install . -pr ~/.conan/profiles/mp-units-gcc -s compiler.cppstd=20 -c mp-units:user.build:all=True -c user.build:skip_docs=True -b outdated -u
    Configuration:
    [settings]
    arch=x86_64
    arch_build=x86_64
    build_type=Release
    compiler=gcc
    compiler.cppstd=20
    compiler.libcxx=libstdc++11
    compiler.version=10
    os=Linux
    os_build=Linux
    [options]
    [build_requires]
    [env]
    CC=/usr/bin/gcc-10
    CXX=/usr/bin/g++-10
    [conf]
    tools.cmake.cmaketoolchain:generator=Ninja
    user.build:skip_docs=True
    mp-units:user.build:all=True
    
    fmt/8.1.1: WARN: Can't update, no package in remote
    fmt/8.1.1: Package is up to date
    gsl-lite/0.40.0: Package is up to date
    conanfile.py (mp-units/0.8.0): Installing package
    Requirements
        fmt/8.1.1 from 'conancenter' - Cache
        gsl-lite/0.40.0 from 'conancenter' - Cache
    Packages
        fmt/8.1.1:7964c93dea718ad24d022304697914d04a7eb801 - Cache
        gsl-lite/0.40.0:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 - Cache
    
    Installing (downloading, building) binaries...
    fmt/8.1.1: Already installed!
    gsl-lite/0.40.0: Already installed!
    conanfile.py (mp-units/0.8.0): Generator txt created conanbuildinfo.txt
    conanfile.py (mp-units/0.8.0): Generator cmake_paths created conan_paths.cmake
    conanfile.py (mp-units/0.8.0): Calling generate()
    conanfile.py (mp-units/0.8.0): WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
    conanfile.py (mp-units/0.8.0): WARN: Using the new toolchains and generators without specifying a build profile (e.g: -pr:b=default) is discouraged and might cause failures and unexpected behavior
    conanfile.py (mp-units/0.8.0): Aggregating env generators
    conanfile.py (mp-units/0.8.0): Generated conaninfo.txt
    conanfile.py (mp-units/0.8.0): Generated graphinfo
    

    I also get no errors on the build:

    $ conan build .
    Using lockfile: '/home/chogg/github/units/conan.lock'
    Using cached profile from lockfile
    conanfile.py (mp-units/0.8.0): Calling build()
    conanfile.py (mp-units/0.8.0): CMake command: cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE="/home/chogg/github/units/build/generators/conan_toolchain.cmake" -DCMAKE_POLICY_DEFAULT_CMP0091="NEW" -DCMAKE_BUILD_TYPE="Release" "/home/chogg/github/units/./src"
    -- Using Conan toolchain: /home/chogg/github/units/build/generators/conan_toolchain.cmake
    -- Conan toolchain: C++ Standard 20 with extensions OFF
    -- The CXX compiler identification is GNU 10.3.0
    -- Detecting CXX compiler ABI info
    -- Detecting CXX compiler ABI info - done
    -- Check for working CXX compiler: /usr/bin/g++-10 - skipped
    -- Detecting CXX compile features
    -- Detecting CXX compile features - done
    -- UNITS_AS_SYSTEM_HEADERS: OFF
    -- Conan: Component target declared 'gsl::gsl-lite'
    -- UNITS_DOWNCAST_MODE: ON
    -- UNITS_USE_LIBFMT: ON
    -- Conan: Component target declared 'fmt::fmt'
    -- Configuring done
    -- Generating done
    CMake Warning:
      Manually-specified variables were not used by the project:
    
        CMAKE_POLICY_DEFAULT_CMP0091
    
    
    -- Build files have been written to: /home/chogg/github/units/build/Release
    conanfile.py (mp-units/0.8.0): CMake command: cmake --build "/home/chogg/github/units/build/Release" '--' '-j8'
    ninja: no work to do.
    

    However, if I change the source code so as to deliberately make a test fail, I get exactly the same output. That, along with ninja's (defiant or naive) declaration that it has "no work to do", makes me think that the tests are not being run.


    Caveats

    I have a very poor understanding of conan generally. I'm spoiled at work with a devtools team and a well-maintained bazel installation. I don't know how to supply options to individual runs of conan build.

    opened by chiphogg 1
  • Reevalute the use of the downcasting facility on units

    Reevalute the use of the downcasting facility on units

    The use of the downcasting facility on units is at odds with

    It is therefore important not to use the unit alone to specify the quantity. This applies not only to technical texts, but also, for example, to measuring instruments (i.e. the instrument read-out needs to indicate both the unit and the quantity measured). -- Extract from https://www.bipm.org/en/publications/si-brochure

    This is quoted at https://github.com/mpusz/units/issues/32#issuecomment-1092376525. I do not think the library should, for example, transform an unit of s⁻¹ to Hz. That conversion should be explicitly specified by the user where it matters, because they carry different information.

    Dropping the use of downcasting facility on units will also remove the source of conflicts between equivalent units that currently want to be downcasted to from the same set of base units.

    opened by JohelEGP 0
  • "MacOS Apple Clang 13" failing in CI

    "MacOS Apple Clang 13" configuration started to crash the compiler in the CI: https://github.com/mpusz/units/runs/7608877183?check_suite_focus=true#logs

    Unfortunately, I do not have access to Apple platforms. @fdischner, could you please try to check what is the source of the issue? If not possible to fix it, we can disable that example from the Apple Clang build but it is good to check if that is the only problem or if maybe more files are affected.

    continuous integration 
    opened by mpusz 1
  • Simplify common magnitude use cases

    Simplify common magnitude use cases

    Most of the magnitudes is the user's code will be the power of 10, only some will be the power of 2, and only a few a power of pi. Other magnitudes probably will nearly not exist. We should optimize for this case so the user does not end up with an error like:

    required for the satisfaction of 'Area<units::quantity<units::unknown_dimension<units::exponent<units::isq::si::dim_length, -1, 1> >, units::scaled_unit<units::magnitude<units::base_power<long int>{2, units::ratio{-3, 1, 0}}, units::base_power<long int>{5, units::ratio{-3, 1, 0}}>(), units::unknown_coherent_unit>, double> >'
    

    Also please note that this error comes from gcc10. gcc11 and gcc12 tend to shorten it making it impossible to know what we are dealing with:

    required for the satisfaction of 'Area<auto [requires units::isq::Area<<placeholder>, >]>' [with auto [requires units::isq::Area<<placeholder>, >] = units::quantity<units::unknown_dimension<units::exponent<units::isq::si::dim_length, -1, 1> >, units::scaled_unit<{}, units::unknown_coherent_unit>, double>]
    

    This impacts user experience a lot.

    See the code in: https://godbolt.org/z/E5b1c54zv.

    opened by mpusz 7
Releases(v0.7.0)
  • v0.7.0(May 11, 2021)

    • (!) refactor: ScalableNumber renamed to Representation
    • (!) refactor: output stream operators moved to the units/quantity_io.h header file
    • (!) refactor: Refactored the library file tree
    • (!) refactor: quantity::count() renamed to quantity::number()
    • (!) refactor: data system renamed to isq::iec80000 (quantity names renamed too)
    • (!) refactor: *deduced_unit renamed to *derived_unit
    • (!) refactor: got rid of a noble_derived_unit
    • refactor: quantity (kind) point updated to reflect latest changes to quantity
    • refactor: basic concepts, quantity and quantity_cast refactored
    • refactor: abs() definition refactored to be more explicit about the return type
    • feat: quantity (point) kind support added (thanks @johelegp)
    • feat: quantity references support added (thanks @johelegp)
    • feat: quantity aliases support addded
    • feat: interoperability with std::chrono::duration and other units libraries
    • feat: CTAD for dimensionless quantity added
    • feat: modulation_rate support added (thanks @go2sh)
    • feat: SI prefixes for isq::iec80000 support added (thanks @go2sh)
    • feat: a possibility to disable quantity UDLs support with UNITS_NO_LITERALS preprocessor define
    • feat: a support to define ISQ derived dimensions in terms of different number or order of components
    • perf: preconditions check do not influence the runtime performance of a Release build
    • perf: quantity_cast() generates less assembly instructions
    • perf: temporary string creation removed from quantity::op<<()
    • perf: value initialization for quantity value removed (left with a default initialization)
    • perf: limited the equivalent trait usage
    • perf: limited the C++ Standard Library headers usage
    • perf: rvalue references support added for constructors and getters
    • (!) fix: exp() has sense only for dimensionless quantities
    • (!) fix: dim_torque now properly divides by an angle (instead of multiply) + default unit name change
    • fix: quantity's operators fixed to behave like the underlying types do
    • fix: quantity_cast() fixed to work correctly with representation types not convertible from std::intmax_t
    • fix: ambiguous case for empty type list resolved
    • fix: downcasting facility for non-default-constructible types
    • fix: restore user-warnings within the library implementation
    • fix: the text symbol of foot_pound_force and foot_pound_force_per_second
    • fix: quantity modulo arithmetics fixed
    • (!) build: Conan testing version is now hosted on Artifactory
    • (!) build: Linear Algebra is now hosted on its Artifactory
    • (!) build: BUILD_DOCS CMake option renamed to UNITS_BUILD_DOCS
    • build: doxygen updated to 1.8.20
    • build: catch2 updated to 2.13.4
    • build: fmt updated to 7.1.3
    • build: ms-gsl replaced with gsl-lite/0.38.0
    • build: Conan generator switched to cmake_find_package_multi
    • build: Conan CMakeToolchain support added
    • build: CMake scripts cleanup
    • build: ccache support added
    • ci: CI switched from Travis CI to GitHub Actions
    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Sep 13, 2020)

    • feat: quantity_point support added (thanks @johelegp)
    • feat: Added angle as SI base dimension (thanks @kwikius)
    • feat: si::angular_velocity support added (thanks @mikeford3)
    • feat: FPS system added (thanks @mikeford3)
    • feat: Added support for mathematical function exp(quantity)
    • feat: Localization support for text output added (thanks @rbrugo)
    • feat: Added STL random number distribution wrappers (thanks @yasamoka)
    • (!) refactor: Refactored and cleaned up the library file tree
    • (!) refactor: q_* UDL renamed to _q_*
    • (!) refactor: UDLs with "per" in name renamed from *p* to *_per_*
    • (!) refactor: ratio changed to the NTTP kind
    • (!) refactor: exp and Exp renamed to exponent and Exponent
    • (!) refactor: Scalar concept renamed to ScalableNumber
    • (!) refactor: Dimensionless quantities redesigned to be of a quantity type
    • refactor: math.h function signatures refactored to use a Quantity concept (thanks @kwikius)
    • refactor: [[nodiscard]] added to many functions
    • fix: si::day unit symbol fixed to d (thanks @komputerwiz)
    • fix: si::mole unit symbol fixed to mol (thanks @mikeford3)
    • (!) build: gcc-9 is no longer supported (at least gcc-10 is required)
    • build: Visual Studio 16.7 support added
    • build: linear_algebra updated to 0.7.0/stable
    • build: fmt updated to 7.0.3
    • build: range-v3 updated to 0.11.0
    • build: catch2 updated to 2.13.0
    • build: doxygen updated to 1.8.18
    • build: ms-gsl 3.1.0 dependency added
    • build: Removed the dependency on a git submodule with common CMake scripts
    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(May 17, 2020)

    • Major refactoring and rewrite of the library
    • Units are now independent from dimensions
    • Dimensions now depend on units (base or coherent units are provided in a class template)
    • Quantity gets a Dimension template parameter again (as unit does not provide information about its dimension anymore)
    • Spaceship operator support added
    • Added official CGS system support
    • Added official data information system support
    • Repository file tree cleanup
    • ratio refactored to contain Exp template parameter (thanks a lot @oschonrock!)
    • SI fundamental constants added
    • q_ prefix applied to all the UDLs (thanks @kwikius)
    • unknown_unit renamed to unknown_coherent_unit
    • Project documentation greatly extended and switched to Sphinx
    • A few more usage examples added
    • ASCII-only output support added (thanks @yasamoka)
    • Representation values formatting extended (thanks @rbrugo)
    • Output streams formatting support added
    • Linear algebra from std::experimental::math support added
    • Named SI units and their dimensions added (thanks @rbrugo
    • libfmt updated to 6.2.0
    • Added absolute functions and epsilon to math.h (thanks @mikeford3)
    • Added a lot of prefixes to named units and introduced alias_unit (thanks @yasamoka)
    • Linking with Conan targets only when they exists (#98)
    • All physical dimensions and units put into physical namespace
    • CMake improvements
    • Velocity renamed to speed

    Many thanks to GitHub users @oschonrock, @kwikius, and @i-ky for their support in drafting a new library design.

    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Nov 17, 2019)

    • Support for derived dimensions in exp added
    • Added pow() and sqrt() operations on quantities
    • units removed from a std::experimental namespace
    • Downcasting facility refactored so the user does not have to write the boilerplate code anymore
    • From now on base dimensions should inherit from base_dimension class template
    • Added unit symbols definitions to base_dimension and derived units
    • Added support for operator<< on quantity
    • fmt support added
    • Derived unit factory helpers refactored
    • Refactored the way prefixed units are defined
    Source code(tar.gz)
    Source code(zip)
  • v0.3.1(Sep 18, 2019)

  • v0.3.0(Sep 17, 2019)

    • The design as described on CppCon 2019 talk (https://youtu.be/0YW6yxkdhlU)
    • Applied the feedback from the Cologne evening session
      • upcasting_traits renamed to downcasting_traits
      • Dimension template parameter removed from quantity
    • units moved to a std::experimental namespace
    • Leading underscore prefix removed from UDLs
    • Added a few more derived dimensions
    • meter renamed to metre
    • Missing operator* added
    • Predefined dimensions moved to a dedicated directory
    • dimension_ prefix removed from names of derived dimensions
    • cmcstl2 library updated to 2019.09.19
    • base_dimension is a value provided as const& to the exp type
    • integrated with Compiler Explorer
    • gsl-lite dependency removed
    • Fractional dimension exponents support added
    • QuantityOf concept introduced
    • quantity_cast<U, Rep>() support added
    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Sep 17, 2019)

    • The design as described on C++Now 2019 talk (https://youtu.be/wKchCktZPHU)
    • Added C++20 features supported by gcc-9.1 (std::remove_cvref_t, down with typename, std::type_identity)
    • Compile-time performance optimizations (type_list, common_ratio, ratio, conditional_t)
    Source code(tar.gz)
    Source code(zip)
  • v0.1.0(Sep 17, 2019)

Owner
Mateusz Pusz
Software architect, chief engineer, security champion, and C++ trainer with more than 14 years of experience in designing, writing and maintaining C++ code.
Mateusz Pusz
Windows user-land hooks manipulation tool.

MineSweeper Windows user-land hooks manipulation tool. Highlights Supports any x64/x86 Windows DLL (actually, any x64/x86 Windows PE for that matter)

Arsenii Pustovit 129 Jul 28, 2022
cavi is an open-source library that aims to provide performant utilities for closed hierarchies (i.e. all class types of the hierarchy are known at compile time).

cavi cavi is an open-source library that aims to provide performant utilities for closed hierarchies (i.e. all class types of the hierarchy are known

Baber Nawaz 5 Mar 9, 2022
A header only C++ library that provides type safety and user defined literals for physical units

SI - Type safety for physical units A header only c++ library that provides type safety and user defined literals for handling pyhsical values defined

Dominik Berner 379 Jul 21, 2022
Compile and execute C "scripts" in one go!

c "There isn't much that's special about C. That's one of the reasons why it's fast." I love C for its raw speed (although it does have its drawbacks)

Ryan Jacobs 2k Aug 7, 2022
LibOS is a modern C++17 library that makes OS-specific features cross-platform.

LibOS is a modern C++17 library that makes OS-specific features cross-platform. Ever tried to get Windows version after Windows 8? Or to send ke

Gavrilikhin Daniil 27 Jun 15, 2022
The lightweight and modern Map SDK for Android and iOS

Open Mobile Maps The lightweight and modern Map SDK for Android (6.0+) and iOS (10+) openmobilemaps.io Getting started Readme Android Readme iOS Featu

Open Mobile Maps 89 Jul 6, 2022
An attempt to restore and adapt to modern Win10 version the Rootkit Arsenal original code samples

rootkit-arsenal-guacamole An attempt to restore and adapt to modern Win10 version the Rootkit Arsenal original code samples All projects have been por

Matteo Malvica 51 Jul 25, 2022
The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.

The C++ REST SDK is a Microsoft project for cloud-based client-server communication in native code using a modern asynchronous C++ API design. This project aims to help C++ developers connect to and interact with services.

Microsoft 7k Aug 4, 2022
The most powerful and customizable binary pattern scanner written on modern C++

Sig The most powerful and customizable binary pattern scanner written on modern C++ ✔ Capabilities: Support for all common pattern formats: Pattern +

Александр 135 Jul 21, 2022
A Template Engine for Modern C++

Inja is a template engine for modern C++, loosely inspired by jinja for python. It has an easy and yet powerful template syntax with all variables, lo

pantor 1.1k Aug 6, 2022
Mustache text templates for modern C++

About Mustache implementation for modern C++ (requires C++11) Header only Zero dependencies Templated string type for compatibility with any STL-like

Kevin Wojniak 289 Jul 26, 2022
Pretty Printer for Modern C++

Highlights Single header file Requires C++17 MIT License Quick Start Simply include pprint.hpp and you're good to go. #include <pprint.hpp> To start p

Pranav 865 Jul 27, 2022
The libxo library allows an application to generate text, XML, JSON, and HTML output using a common set of function calls. The application decides at run time which output style should be produced.

libxo libxo - A Library for Generating Text, XML, JSON, and HTML Output The libxo library allows an application to generate text, XML, JSON, and HTML

Juniper Networks 242 Jul 19, 2022
This library support run-time type casting faster than dynamic_cast ( similar to unreal engine's CastTo )

Fast Runtime Type Casting This library give you C++ Fast Runtime Type Casting faster than dynamic_cast ( similar to Unreal Engine's CastTo, IsChildOf

SungJinKang 7 Jun 11, 2022
Sqrt OS is a simulation of an OS scheduler and memory manager using different scheduling algorithms including Highest Priority First (non-preemptive), Shortest Remaining Time Next, and Round Robin.

A CPU scheduler determines an order for the execution of its scheduled processes; it decides which process will run according to a certain data structure that keeps track of the processes in the system and their status. A process, upon creation, has one of the three states: Running, Ready, Blocked (doing I/O, using other resources than CPU or waiting on unavailable resource).

Abdallah Hemdan 18 Apr 15, 2022
Advanced, modular, coupled geomorpohology simulator for real-time procedural terrain generation.

SoilMachine Advanced, modular, coupled geomorpohology simulator for real-time procedural terrain generation in C++. Visualization with TinyEngine. Art

Nick McDonald 110 Aug 5, 2022
provide SFML Time utilities in pure C++20, no dependencies

SFML-Time-utilities-without-SFML provide SFML Time utilities in pure C++20, no dependencies Example int main() { Clock clock; Sleep(1000);

null 1 Apr 28, 2022
DateTime Class to Express Time

Time is an eternal topic. How to express time is very important. The C + + class represents the date and time, which is very easy to use.

null 1 Dec 7, 2021