majorexception's comments

I don't think there's real difference between Python and C. With Python you can't make your program use more than 4 GB of address space if you run it with a 32-bit interpreter. You have to swap the interpreter. In C the same goes for the compiler. And yes, you can inspect the upper limit by looking at the width of size_t, but it will be seen differently with 32 and 64-bit compilers although the program will be the same. And you _can_ make program behave differently basing on size_t's width, but you're not required to. It doesn't change that fundamentally Python is no more Turing-complete than C just because you can't do it in Python (that's my assumption, I don't know Python well enough actually).

Maybe it all boils down to how CPUs work, and maybe it's safe to say that the incompleteness comes from the CPU implementation? You can of course argue that Python interpreters are written in C/C++, but of course we can imagine they can be written in assembly.

Edit: after I read some other comments I think I see the point - that indeed the problem is the implementation (on CPU).

I did that, but then adding 0_degC + 0_degC gave 273.15_degC. I think that would be surprising to many people. In reality I don't remember ever having to deal with physics formulas that used °C instead of Kelvins, so the only time I need to use °C is when presenting the temperature in the UI:

    temperature.in<si::Celsius>()

Something like this:

    auto
    operator"" _rpmPerVolt (long double x) {
        return decltype (1_rpm / 1_V)(x);
    }

I have a macro for that:

    #define SI_DEFINE_LITERAL(xUnit, xliteral) \
     [[nodiscard]] \
     constexpr Quantity<units::xUnit> \
     operator"" xliteral (long double value) \
     {  \
         return Quantity<units::xUnit> (value); \
     } \
     \
     [[nodiscard]] \
     constexpr Quantity<units::xUnit> \
     operator"" xliteral (unsigned long long value) \
     { \
         return Quantity<units::xUnit> (value); \
     }

    // Base SI units:
    SI_DEFINE_LITERAL (Meter, _m)
    SI_DEFINE_LITERAL (Kilogram, _kg)
    SI_DEFINE_LITERAL (Second, _s)
    SI_DEFINE_LITERAL (Ampere, _A)
    SI_DEFINE_LITERAL (Kelvin, _K)
    SI_DEFINE_LITERAL (Mole, _mol)
    SI_DEFINE_LITERAL (Candela, _cd)
    SI_DEFINE_LITERAL (Radian, _rad)

...and a loong list of other common units here.

The additional types are defined like this, in another file:

    using Foot          = ScaledUnit<Meter, std::ratio<1'200, 3'937>>;
    using Mile          = ScaledUnit<Meter, std::ratio<1'609'344, 1'000>>;
    using NauticalMile  = ScaledUnit<Meter, std::ratio<1'852, 1>>;
    using Inch          = ScaledUnit<Meter, std::ratio<254, 10'000>>;

And then I use SI_DEFINE_LITERAL (NauticalMile, _nm); etc.

Yup. So I explicitly deleted operators for °C, so things like 5_degC + 10_degC won't compile.

I have a project for which I wrote a simple units library. I don't think I'd be able to write any physics-related project now without using it (or a similar library). My Quantity class has a set of 8 parameters (7 SI base units and a hack that allows conversion between Hz and radians) + additional Scale and Offset parameters. Scale allows representing units other than SI (like Nautical Miles), Offset is for units like Celsius, for which 0°C == 273.15 K.

I can do things like:

    si::Length length = 15_m + 12_nm; // _nm for Nautical Miles
    si::Area area = 1_m * 1_km; // Equals to 1000_m2
    si::Power power = 1_m / 1_sec / 1_sec; // Compilation error, 1_m/s² is not a si::Power

I don't have every possible User-Defined Literal, of course, so I end up doing this for less common units:

    using SomeLocalTypeName = decltype(1_rpm / 1_V);

Something to thing about, when designing such library:

* What is 0_degC + 1_degC? 1_degC or… 273.15_K + 274.15_K = 547.3_K = 274.15_degC? I forbid operations between units if any of them has Offset parameter different than 0. I'm not sure if this is the good solution, though.

* Nm (Newton-meters) is the same unit as Joules. ;-)

Hmm. I have 4-core i7-4770, but the UI on this thing lags a lot, all widgets generally feels sluggish. Such graphics operations don't require a lot of CPU, though, remember that we used to have 200 MHz Pentiums?

On Firefox it's even worse, looks like it was rendered by 4 MHz Apple II. :|

But if it allows easy porting of a Java app to a browser, then this is still great stuff. Not the most responsive UI, but in case of emergency, why not?