Skip to content
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

Merged
merged 30 commits into from
Oct 4, 2020
Merged

Conversation

nholthaus
Copy link
Owner

No description provided.

@nholthaus
Copy link
Owner Author

@JohelEGP meant to ask you about this:

[  FAILED  ] TypeTraits.is_data_unit (0 ms)
[ RUN      ] TypeTraits.is_data_transfer_rate_unit
/home/travis/build/nholthaus/units/unitTests/main.cpp:603: Failure
Value of: (traits::is_data_transfer_rate_unit_v<const gigabytes_per_second<double>&>)
  Actual: false
Expected: true

Why don't we want const references to pass the dimension trait?

@JohelEGP
Copy link
Contributor

JohelEGP commented Nov 5, 2018

For the same reason we don't want it working on pointers. They're pointer/references to types, not the types themselves.

@coveralls
Copy link

coveralls commented Nov 5, 2018

Coverage Status

Coverage decreased (-100.0%) to 0.0% when pulling 93f3a3e on v3.x-rename-conversion-factors into 65b00fd on v3.x.

@nholthaus
Copy link
Owner Author

nholthaus commented Nov 5, 2018

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 remove_ref.

@JohelEGP
Copy link
Contributor

JohelEGP commented Nov 5, 2018

That's alright, but it becomes a gotcha where it appears to work like the standard's design. Note all the other occurrences of tests in #208 that need to be updated after 484a58b.

@@ -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()))
Copy link
Contributor

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?

Copy link
Owner Author

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.

Copy link
Contributor

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.

@nholthaus
Copy link
Owner Author

fixes #159

@@ -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`. \ \ \ \ \
Copy link
Contributor

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.

@JohelEGP
Copy link
Contributor

JohelEGP commented Nov 5, 2018

fixes #159

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?

@nholthaus
Copy link
Owner Author

no I was planning on using the singular form. Do you have a preference?

@JohelEGP
Copy link
Contributor

JohelEGP commented Nov 5, 2018

Well, I thought the natural form in english was the plural spelling. Just like std::chrono::seconds.

@nholthaus
Copy link
Owner Author

yeah good point. It's just a more difficult refactor, but it shouldn't be a problem


static_assert(has_equivalent_conversion_factor(
Copy link
Contributor

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.


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));
Copy link
Contributor

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);
Copy link
Contributor

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.

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);
Copy link
Contributor

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 units 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.

Copy link
Owner Author

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?

Copy link
Contributor

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.

@@ -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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This private is redundant.

@JohelEGP
Copy link
Contributor

JohelEGP commented Nov 6, 2018

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.

@nholthaus
Copy link
Owner Author

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.

@JohelEGP
Copy link
Contributor

JohelEGP commented Nov 6, 2018

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 <units/concentration.h>. And that the singular name part of the UNIT_ADD macro will become essentially unused, I believe.

@nholthaus
Copy link
Owner Author

@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.

Copy link
Contributor

@JohelEGP JohelEGP left a 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.

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>) \
Copy link
Contributor

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 ##.

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>>>));
Copy link
Contributor

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.

@@ -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(
Copy link
Contributor

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.

@nholthaus
Copy link
Owner Author

@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 strong_t is also a struct instead of an alias template?

@JohelEGP
Copy link
Contributor

JohelEGP commented Oct 3, 2020

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.

@JohelEGP
Copy link
Contributor

JohelEGP commented Oct 3, 2020

GCC 10.2 compiled it successfully and only a locale test failed:

...
1: /home/johel/Documents/C++/Forks/units/unitTests/main.cpp:2524: Failure
1:       Expected: "de_DE.utf8"
1: To be equal to: setlocale(6, "de_DE.utf8")
1:       Which is: NULL
1: /home/johel/Documents/C++/Forks/units/unitTests/main.cpp:2529: Failure
1:       Expected: point_de
1:       Which is: '.' (46, 0x2E)
1: To be equal to: ','
1:       Which is: ',' (44, 0x2C)
1: /home/johel/Documents/C++/Forks/units/unitTests/main.cpp:2535: Failure
1:       Expected: "2,5 km"
1: To be equal to: units::length::to_string(de).c_str()
1:       Which is: "2.5 km"
...
1: [  FAILED  ] UnitType.to_string_locale
...

@nholthaus
Copy link
Owner Author

nholthaus commented Oct 3, 2020 via email

@nholthaus
Copy link
Owner Author

nholthaus commented Oct 4, 2020 via email

@nholthaus nholthaus merged commit f9e2eca into v3.x Oct 4, 2020
@nholthaus nholthaus deleted the v3.x-rename-conversion-factors branch October 4, 2020 00:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants