How to initialize quantity with value, and get numeric value back out.

[Cazadorro]

Previous to 2.0, it was easy to initialize quantities with values, and extract values (with .number()). Now there doesn't appear to be a straight forward constructor to actually create quantities.

I know I can use unit symbols in order to do create new quantities (e.g. 1.0 * m), but there are many scenarios where that is simply not feasible, especially in library code. I dug into quantities source code and found there to be to be no straight forward constructor from raw numeric types. I'm fine if it's some sort of weird value_cast thing, but I can't find that either. Additionally I can't find a way to get a numeric value out of these types, no .number(), .value() etc... Is there not even a way to static cast?

I looked at this #454 and there's no explanation of how to get what I want as well.

I should be able to do

mp_units::quantity<unit, std::uint64_t> foo(0ull); 

or
mp_units::quantity<unit, std::uint64_t> foo = some_sort_of_cast(0ull);

The above post seems to imply I'd be forced to use the unit symbols here?

[JohelEGP]

If you're OK with CTAD, you can use quantity(1, kHz): https://godbolt.org/z/9qqnWhPTj.
To get the value back, call .numerical_value_in(kHz) (see https://mpusz.github.io/mp-units/latest/users_guide/use_cases/working_with_legacy_interfaces/).

[Cazadorro]

Thanks! That does help

A big problem I have with that is that I have to import the unit symbol, and I don't want to expose that on the namespace level (which other could cause unit symbol name conflicts if I used using inside my own namespace, and is just irresponsible regardless) which means that I'd have to fully qualify kHz. So effectively I'm forced to do quantity(mp_units::si::unit_symbols::kHz) and .numerical_value_in(mp_units::si::unit_symbols::kHz) or i'm forced to repeat using namespace mp_units::xxx::unit_symbols; inside every function I have for every unit system I use. What is stopping something like:

    template<typename unit, typename T> 
    auto make_quantity(T value){
        return quantity(value, unit{}); 
   }

   quantity = make_quantity<my_namespace::units, std::uint64_t>(123ull) ;

and

    
    template<typename unit, typename T> 
    auto number_from_quantity(quantity<unit, T> quantity){
        return quantity.numerical_value_in(unit{});
   }

    std::uint64_t number = number_from_quantity(quantity); 

from being in this library?

[JohelEGP]

For the latter one, safety.
Changing the unit from kHz to MHz at the point of declaration will change the extracted number at some later line/other file.
That's not always OK, so you're required to repeat the unit at the call site when extracting the number.

[chiphogg]

I believe it would be more idiomatic to take the unit as a value in your template --- for example:

template<Unit auto u, typename T> 
auto make_quantity(T value) {
    return quantity(value, u); 
}

You could also simply multiply by that unit, just as if it were a unit symbol.

[chiphogg]

Do you have an example use case for library code that you can't write? You say that it's infeasible for unit symbols specifically, but maybe we could figure out a different way to write it, with something other than symbols, that would be more feasible.

Same question for use cases where we want to "just get the underlying number, regardless of units". I'm very skeptical of these in particular. One of the only ones I know is for printing quantities --- and even here, it's not correct unless we also handle the unit directly next to it (i.e., by printing a label). I think this will be a general property.

[mpusz]

Hi @Cazadorro! Thanks for your feedback.

We can't construct a quantity from a raw value anymore because of safety. See FAQ in our documentation for more details. You can also find the following chapters interesting:

• explicit is not explicit enough
• Safe quantity numerical value getters

If I understand your problem correctly, you do not want to import all the symbols to your namespace like:

namespace my {

using namespace mp_units::si::unit_symbols;

}

as this would export those to your customers, who may again do:

using namespace my;

I wouldn't be so worried about it. First, it is considered a bad practice in C++. Second, you may do one of the alternatives:

1. Import only the units you care about in your domain, which should provide fewer collisions:

namespace my {

using mp_units::si::unit_symbols::kHz;

}

2. Provide a unit_symbols opt-in subnamespace as well so the imported units are not a direct part of the namespace if users import it in their projects:

namespace my::unit_symbols {

using namespace mp_units::si::unit_symbols;

}

3. Don't use symbols at all. You can always type a proper unit name (not its symbol):

quantity q1(42, mp_units::si::kilo<mp_units::si::hertz>);
quantity q2 = 42 *  mp_units::si::kilo<mp_units::si::hertz>;

4. Import the entire si namespace:

namespace my {

using mp_units::si;

}

quantity q1(42, kilo<hertz>);
quantity q2 = 42 * kilo<hertz>;

This actually will also allow the following:

using namespace my::unit_symbols;
quantity q1(42, kHz);
quantity q2 = 42 * kHz;

5. Don't export anything and blame it on us 😉. Said otherwise, ask users to use unit symbols from the mp_units namespace.

Also, there is one thing that I would point out here. It seems that you do not want to expose units to your users. Does it mean that all the quantities you use in a project are of the same unit? In such a case you can provide a simple factory function for them:

template<typename T> 
quantity<mp_units::si::kilo<mp_units::si::hertz>, T> make_quantity(T value)
{
  return value * mp_units::si::kilo<mp_units::si::hertz>;
}

You can also provide a simple helper to return the underlying value:

template<typename T> 
const T& get_value(const quantity<mp_units::si::kilo<mp_units::si::hertz>, T>& q)
{
  return q.numerical_value_ref_in(mp_units::si::kilo<mp_units::si::hertz>);
}

I hope that one of the above would be an acceptable solution for you.

[Cazadorro]

Nope, the problem isn't that I think it will conflict in a users usage of using, it's that it may conflict within our own namespace. There are already unit symbols that conflict with si and iec80000 and pre-existing unrelated units, so unit symbol namespace exposure is actually unworkable. Additionally we have aliases of units and custom units put into one namespace. Developers of the library shouldn't have to understand mp-units file structure if they don't need to add new units, especially since mp units is not stable from our perspective (and headers have changed multiple times), so we need a way were can manage this instability from one place.

So we can just use the constexpr struct constructor and the value extractor with the constexpr unit tag, it's just about the namespaceing.

I think the issue actually comes down to us aliasing the whole quantity instead of of the unit, so we do something like:

typename<T>
using meters = mp_units::quantity<mp_units::si::metre, T>;

When it seems like you'd prefer us to just alias mp_units::si::metre, which would solve our problems (though aliasing wouldn't actually work since it's a value so we have to copy I guess?). The problem with that is then we have to expose quantity directly in our interfaces, and the whole "MSVC stopped caring about C++ development causing bugs in their compiler" thing that stopped this library from working on MSVC threw a bomb into the idea of depending heavily on how this library works. We need to plausibly be able to change libraries if this library ends up in another situation like that again (for example, depends on a version of GCC that isn't available on RHEL 8), it's harder to do that with out hiding quantity.

[chiphogg]

Preserving "migrateability" is a worthy goal. We have some experience doing that safely and at scale, going from nholthaus to Au.

I should warn you that I don't think using a single-home shim for mp-units, which could be swapped out to be a shim for some other library, would actually give you this in practice. The reason is that the interfaces that end users use --- say, for creating the quantities, or getting the value out --- will be very different. Which I think is your whole point! 🙂 And it explains why you want to have simple "no unit name" interfaces in each direction. But in my experience, there will be other interface differences too, and doing a single library swap as an "implementation detail change" will never work at scale.

What has worked for us is the ability to define correspondences between the types in different units libraries. So far, I have only seen this feature in Au and mp-units. (Here are the docs for Au; I don't know the mp-units docs well enough, but they're there.) In this way, you can seamlessly pass one library's types to interfaces using the other library, which lets you break up the migration to be more manageable.

[mpusz]

When we fine-tune the smaller remaining bits with each new version, we are more and more committed to interfaces' stability and backward compatibility. Even if we introduce new features depending on a new standard version, we try hard to provide a C++20 way of doing this. It results with compatibility preprocessor macros, but there is no way to do it otherwise.

From the upcoming mp-units 2.3.0, in case a breaking change in the new release is expected to have a large impact on the users we also try to provide both interfaces. A new one with changed signatures and an old one marked as [[deprecated]] for 2 upcoming releases.

Typically when a specific compiler is supported it will not change without a very good reason. Looking into the C++26 feature list, we do not see major game-changers that would cause us to start working on a new incompatible mp-units version as it was the case with mp-units V2. If we benefit from new features (e.g., reflection) we are committed to also provide a backward compatible way to do so if only possible.

typename<T>
using meters = mp_units::quantity<mp_units::si::metre, T>;

metre<T> is probably not a good solution as it does not scale. This is why we abandoned this approach of the mp-units 0.8. Consider how many of those aliases you have to provide just for popular speed units. Other quantities involving more units in its equations may be even more challenging.

though aliasing wouldn't actually work since it's a value so we have to copy I guess?)

You can either do a using-declaration or just copy an object of tag type to your namespace.

[mpusz]

I don't know the mp-units docs well enough, but they're there.) In this way, you can seamlessly pass one library's types to interfaces using the other library, which lets you break up the migration to be more manageable.

More information about that can be found in the Interoperability with Other Libraries chapter.

[Cazadorro]

When we fine-tune the smaller remaining bits with each new version, we are more and more committed to interfaces' stability and backward compatibility. Even if we introduce new features depending on a new standard version, we try hard to provide a C++20 way of doing this. It results with compatibility preprocessor macros, but there is no way to do it otherwise.

From the upcoming mp-units 2.3.0, in case a breaking change in the new release is expected to have a large impact on the users we also try to provide both interfaces. A new one with changed signatures and an old one marked as [[deprecated]] for 2 upcoming releases.

Typically when a specific compiler is supported it will not change without a very good reason. Looking into the C++26 feature list, we do not see major game-changers that would cause us to start working on a new incompatible mp-units version as it was the case with mp-units V2. If we benefit from new features (e.g., reflection) we are committed to also provide a backward compatible way to do so if only possible.

typename<T>
using meters = mp_units::quantity<mp_units::si::metre, T>;

metre<T> is probably not a good solution as it does not scale. This is why we abandoned this approach of the mp-units 0.8. Consider how many of those aliases you have to provide just for popular speed units. Other quantities involving more units in its equations may be even more challenging.

though aliasing wouldn't actually work since it's a value so we have to copy I guess?)

You can either do a using-declaration or just copy an object of tag type to your namespace.

Alright, we're just going to be exposing quantity and aliasing the structs if there's a commitment to usability.