produces an unreadable mess of a linker error, when:
The function is not invoked during compile-time (v is not constexpr, in my original case reading from a .json file...)
And v is either a scalar_t or a more complex unit type (failing types commented out in print_dynamic() in attached file)
Invoking these for constexpr values turns them into compile-time errors of the functions being "used but never defined".
I take it that this behaviour is intentional? The only reference I've found to this is in the release notes of 2.3.0:
Adds std::cout support for units with no defined abbreviation (they show up as a combination of SI base units)
But there is no further information on why they would not be defined. Since the whole point of the library is about being safe at compile-time, I would expect that the abbreviation could also be constructed at compile-time, since all of the types are known at compile-time. Obviously the name does not always exist for all unit combinations.
Would it be feasible to have one or more of the following?
Also have the compilation failure (with a good error message) on non-constexpr values, instead of letting it get to link step?
Abbreviation available at compile-time, name empty if not available, would require string-like constexpr objects?
scalar.name() == "scalar", scalar.abbreviation() == "" / dimensionless.name() == "dimensionless", dimensionless.abbreviation() == "", unless something more special exists, such as for decibels?
Tested with:
Units 2.3.1, Clang 14.0
Units 2.3.3, GCC 9.4.0
Invoking any of the following:
units::name(v)
units::abbreviation(v)
v.name()
v.abbreviation()
produces an unreadable mess of a linker error, when:
v
is not constexpr, in my original case reading from a .json file...)v
is either a scalar_t or a more complex unit type (failing types commented out inprint_dynamic()
in attached file)Invoking these for constexpr values turns them into compile-time errors of the functions being "used but never defined". I take it that this behaviour is intentional? The only reference I've found to this is in the release notes of 2.3.0:
But there is no further information on why they would not be defined. Since the whole point of the library is about being safe at compile-time, I would expect that the abbreviation could also be constructed at compile-time, since all of the types are known at compile-time. Obviously the name does not always exist for all unit combinations.
Would it be feasible to have one or more of the following?
scalar.name() == "scalar"
,scalar.abbreviation() == ""
/dimensionless.name() == "dimensionless"
,dimensionless.abbreviation() == ""
, unless something more special exists, such as for decibels?Tested with: Units 2.3.1, Clang 14.0 Units 2.3.3, GCC 9.4.0
Unreadable linker error:
Compile-time error:
Code: maincpp.txt