-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
V3.x rename conversion factors #211
Conversation
…nit types in conversion factors.
…p for removing predefined conversion factors.
…cause we know that int dB units don't work
@JohelEGP meant to ask you about this:
Why don't we want const references to pass the dimension trait? |
For the same reason we don't want it working on pointers. They're pointer/references to types, not the types themselves. |
I feel like this is one of those "c++ defaults are backwards" situations. The reason for the existence of dimension traits is for sfinae/concepts, where you may save a conversion over defaulting to common_type, etc. So all I really want to know is, "is this the dimension of unit that I want". 99% of the time const/ref/ptr doesn't matter for the concept to be valid (at least in my usage), so it seems better to check that in addition the 1% of the time than have to wrap most calls to the trait with |
include/units/core.h
Outdated
@@ -2508,8 +2511,8 @@ namespace units | |||
std::enable_if_t<detail::is_time_conversion_factor<Cf> && detail::is_losslessly_convertible<Rep, T>, int> = | |||
0> | |||
constexpr unit(const std::chrono::duration<Rep, Period>& value) noexcept | |||
: linearized_value(NumericalScale::linearize(units::convert<unit>( | |||
units::unit<units::conversion_factor<Period, dimension::time>, Rep>(value.count()))())) | |||
: linearized_value(NumericalScale::linearize(units::convert<unit>(units::unit<units::conversion_factor<Period, dimension::time>, Rep>(value.count())) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This line is longer than the Clang Format limit. Why don't you turn it on to run on every save?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's on, I think visual studio's implemention isn't very good. I've seen it crap out a few times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been looking into automating it in a Travis build. I'll get back to you when I'm successful.
fixes #159 |
include/units/core.h
Outdated
@@ -510,14 +513,14 @@ namespace units | |||
#define UNIT_ADD_DIMENSION_TRAIT(unitdimension) \ | |||
/** @ingroup TypeTraits*/ \ | |||
/** @brief `UnaryTypeTrait` for querying whether `T` represents a unit of unitdimension*/ \ | |||
/** @details The base characteristic is a specialization of the template `std::bool_constant`. \ | |||
/** @details The base characteristic is a specialization of the template `std::bool_constant`. \ \ \ \ \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see what you mean WRT MSVC's Clang Fromat.
I'm not sure if it works with you even though it's disabled, but that needs to go in the first comment. That said, aren't you renaming the units to their plural spelling? |
no I was planning on using the singular form. Do you have a preference? |
Well, I thought the natural form in english was the plural spelling. Just like |
yeah good point. It's just a more difficult refactor, but it shouldn't be a problem |
|
||
static_assert(has_equivalent_conversion_factor( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hadn't updated these tests to test unit
too, and not only the strong types.
unitTests/main.cpp
Outdated
|
||
EXPECT_EQ((std::hash<dimensionless<double>>()(3.14)), std::hash<double>()(3.14)); | ||
EXPECT_EQ((std::hash<unit<dimensionless_unit, double>>()(3.14)), std::hash<double>()(3.14)); | ||
EXPECT_EQ((std::hash<dimensionless<int>>()(42)), (std::hash<unit<dimensionless_unit, int>>()(42))); | ||
EXPECT_EQ((std::hash<dimensionless<double>>()(3.14)), std::hash<double>()(3.14)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. You'll see that the line above is now equal to this one. And below, too, at the tests for the ordering operators.
|
||
const unit<meters, int> c_m(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Around here they were intentional, too.
unitTests/main.cpp
Outdated
foot<double> a_ft(3.28084); | ||
second<double> a_sec(10.0); | ||
const meter<int> d_m(1), e_m(2); | ||
const std::common_type_t<meter<int>, foot<int>> j(d_m); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine since the common type of unit
s are tested above, but generally I don't think there were undesirable uses of unit
left that weren't testing unit
and not the strong types.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should I revert c8d935f, or would you rather patch up the tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reverting seems the better option.
include/units/core.h
Outdated
@@ -2437,7 +2440,7 @@ namespace units | |||
* - \ref constantUnits "constant units" | |||
*/ | |||
template<class ConversionFactor, typename T = UNIT_LIB_DEFAULT_TYPE, class NumericalScale = linear_scale> | |||
class unit : NumericalScale, units::detail::_unit | |||
class unit : public ConversionFactor, private NumericalScale, units::detail::_unit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This private
is redundant.
I don't think I have anything else to share. Reviewing this allowed me to notice a few things, as stated in the new issues. |
I've been looking at the revert and actually I don't think are probably too many more places than what you pointed out where we shouldn't be using strong unit types. I like to keep the tests close to the intended usage of the syntax, and have 'bootstrapped' them a few times. We messed up the meanings of a few tests, but I'm fully confident that we didn't break any functionality. let's fix the few we need to after the name refactor. |
Note that if you change the name of the units to their plural spelling, parts of my opinion in #212 will be applied due to how the macros are used in |
@JohelEGP the latest push fails one of the strong tests, but I'm not sure if something is wrong, or if the test is no longer valid because of how we define unit conversions in terms of other units in this branch. May want to take a look at the refactored |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry this is late. I made some review comments, but didn't know I had to explicitly submit them until recently.
include/units/core.h
Outdated
UNIT_ADD(namespaceName, giga##nameSingular, giga##namePlural, G##abbreviation, giga<namePlural>) \ | ||
UNIT_ADD(namespaceName, tera##nameSingular, tera##namePlural, T##abbreviation, tera<namePlural>) \ | ||
UNIT_ADD(namespaceName, peta##nameSingular, peta##namePlural, P##abbreviation, peta<namePlural>) | ||
UNIT_ADD(namespaceName, femto##nameSingular##, femto##namePlural, f##abbreviation, femto<nameSingular##_t>) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JohelEGP the latest push fails one of the strong tests, but I'm not sure if something is wrong, or if the test is no longer valid because of how we define unit conversions in terms of other units in this branch. May want to take a look at the refactored
METRIC_PREFIXES
macro.
Maybe it's this added ##
.
unitTests/main.cpp
Outdated
EXPECT_TRUE((std::is_same_v<square_meter, traits::strong_t<squared<meter>>>)); | ||
EXPECT_TRUE((std::is_same_v<meter_conversion_factor, | ||
traits::strong_t<conversion_factor<std::ratio<1>, dimension::length>>>)); | ||
EXPECT_TRUE((std::is_same_v<kilometer_conversion_factor, traits::strong_t<kilo<meter_conversion_factor>>>)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@JohelEGP the latest push fails one of the strong tests, but I'm not sure if something is wrong, or if the test is no longer valid because of how we define unit conversions in terms of other units in this branch. May want to take a look at the refactored
METRIC_PREFIXES
macro.
I checked, and meter_conversion_factor
should be changed to meter_t
.
include/units/core.h
Outdated
@@ -2508,8 +2525,9 @@ namespace units | |||
std::enable_if_t<detail::is_time_conversion_factor<Cf> && detail::is_losslessly_convertible<Rep, T>, int> = | |||
0> | |||
constexpr unit(const std::chrono::duration<Rep, Period>& value) noexcept | |||
: linearized_value(NumericalScale::linearize(units::convert<unit>( | |||
units::unit<units::conversion_factor<Period, dimension::time>, Rep>(value.count()))())) | |||
: linearized_value(NumericalScale::linearize( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This linearize
call can be replaced by accessing the .linearized_value
of its argument.
@JohelEGP I re-tried this branch with the gcc 10.1 and the strong_t alias template still gives us trouble. Could we refactor this in such way that |
…/units into v3.x-rename-conversion-factors
…/units into v3.x-rename-conversion-factors
I'm back online. I'll try compiling it with GCC 10.2. Can you give me a github reference as to what's wrong with |
GCC 10.2 compiled it successfully and only a locale test failed:
|
sorry, I think I figured it out looking at the generated macro code, things
were confusing being in the middle of the rename.
We should figure out if we actually need to revert strong types or not
though. I don't really remember what we thought was wrong, and things seem
to be working on the surface.
…On Sat, Oct 3, 2020 at 7:49 PM Johel Ernesto Guerrero Peña < ***@***.***> wrote:
I'm back online. I'll try compiling it with GCC 10.2. Can you give me a
github reference as to what's wrong with strong_t? Besides my issue to
revert it. It's been a long while, after all, so I need the context.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#211 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACOYOHYVKM2YY6Q4MQWXRTLSI62B7ANCNFSM4GB5RXCQ>
.
|
that's fine, the locale just isn't installed
…On Sat, Oct 3, 2020 at 7:59 PM Nicolas Holthaus ***@***.***> wrote:
sorry, I think I figured it out looking at the generated macro code,
things were confusing being in the middle of the rename.
We should figure out if we actually need to revert strong types or not
though. I don't really remember what we thought was wrong, and things seem
to be working on the surface.
On Sat, Oct 3, 2020 at 7:49 PM Johel Ernesto Guerrero Peña <
***@***.***> wrote:
> I'm back online. I'll try compiling it with GCC 10.2. Can you give me a
> github reference as to what's wrong with strong_t? Besides my issue to
> revert it. It's been a long while, after all, so I need the context.
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#211 (comment)>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ACOYOHYVKM2YY6Q4MQWXRTLSI62B7ANCNFSM4GB5RXCQ>
> .
>
|
No description provided.