ts826848
ts826848
I think the warning comes from `String::copy`: ``` /Users/bc/code/test-project/external/doctest/doctest/doctest.h:1189:9: note: Calling constructor for 'Result' DOCTEST_DO_BINARY_EXPRESSION_COMPARISON(==, " == ", DOCTEST_CMP_EQ) //!OCLINT bitwise operator in conditional ^ /Users/bc/code/test-project/external/doctest/doctest/doctest.h:1051:16: note: expanded from macro...
For what it's worth, the v3.x branch also displays this behavior. I'm not sure removing implicit constructors would completely solve the problem either, since an explicit constructor still runs into...
I suspect this behavior is unintended. `units::math::exp()` uses `operator()()`: https://github.com/nholthaus/units/blob/ea6d126942cb3225a341568ab57ec52513977875/include/units.h#L4467-L4472 ```cpp return dimensionless::scalar_t(std::exp(x())); // ^^ ``` `operator()()` returns the "raw" underlying value, completely disregarding any information that is encoded in...
Sorry it took so long; I submitted #288 to try to address your issue. Still have to make a version for v3.x as well, but that's something for another day...
I think #262 and #265 fix this issue? Strictly speaking, it's still a recursive implementation, but they're tail-recursive and at least based on quick checks on godbolt compilers can transform...
In my specific case, I ran into issues compiling a project with Nuitka when mssql-cli was installed in the same virtualenv.
This smells like [an issue due to `` and/or `` defining `min` and `max` macros](https://stackoverflow.com/q/5004858), which conflict with functions of the same name. If the issue is indeed the same,...
It appears the old behavior [might have been a bug](https://github.com/nholthaus/units/pull/295#issuecomment-1271676338), as the original intent was for `to()` and `value()` to produce the same result and the old behavior of `value()`...
I suppose I have a related question - the `unit` constructor for built-in types and `operator=()` for built-in types behave differently, since the former uses the provided value as-is while...
I wonder whether there actually *can* be a general scalable solution. I think the solution that has the least potential for confusion in this situation is to have custom functions...