Closed nholthaus closed 3 years ago
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 remove_ref
.
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.
fixes #159
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?
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 std::chrono::seconds
.
yeah good point. It's just a more difficult refactor, but it shouldn't be a problem
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 <units/concentration.h>
. And that the singular name part of the UNIT_ADD
macro will become essentially unused, I believe.
@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.
@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?
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.
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
...
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 < notifications@github.com> 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 https://github.com/nholthaus/units/pull/211#issuecomment-703178380, 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 nholthaus@gmail.com 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 < notifications@github.com> 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 https://github.com/nholthaus/units/pull/211#issuecomment-703178380, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACOYOHYVKM2YY6Q4MQWXRTLSI62B7ANCNFSM4GB5RXCQ .
@johelegp meant to ask you about this:
Why don't we want const references to pass the dimension trait?