cout << 2.0_m * 2.0_m * 2.0_m * 2.0_m << endl; about units

[lvv]

There are too many combination of units and their powers to be able to define all them for printing. It would be great if units would be able to print without definition.

For example for speed, instead of using meters_per_second_t defined abbreviation of "mps", this library could use power of core units in speed definition (meters^1) * (second^-1) and should print "m/s" or "m s⁻¹" (yes, with unicode).

This is just a suggestion. I actually don't know how this library works or if it possible or not.

[dharmatech]

I don't have an immediate need for 4th dimensional space units, so no worries. :-) I just noticed this behaviour in some experiments and was suprised. I'll close the issue for now.

Seems like 16 m^4 would be OK if you ever decide to add a default output format.

Anyway, I'm having fun exploring your units library. Thanks!

[nholthaus]

So this is actually expected behavior. Unit abbreviations will only be shown on cout for units which have been defined. There's not a good way to do that without human intervention (I mean I guess I could output a long list of SI units + powers but is that really helpful?).

At least as far as the physics that I understand, there are only 3 dimensions of 'length', so m^4 has no meaning/definition.

That said, you'll certainly find this is also the case for real units that I haven't previously heard of. In those cases, you can:

1. Add them to your own code using UNIT_ADD, and/or
2. Report them as issues, linking to an authoritative definition, ad I'll add them to a future release.

[dharmatech]

For reference, here's how Mathematica 10 displays the various unit powers:

[nholthaus]

well If Mathematica can do it...

[nholthaus]

@lvv This feature is going to be added in version 2.3. My current thought is output will include all non-zero exponents in standard SI order, with a hat symbol, e.g.:

m s^-1 or kg m s^-2

This would just affect printing, not unit definition, which pretty much already worked the way you suggested.

I've been staying away from unicode. I did some early experiments with it (I wanted to use the degree symbol for angles and temperatures), but literals don't support it, and there were a few other issues. It just doesn't seem like std c++ is really unicode friendly right now. I know it's a huge bummer for non-english programs, and I'm sorry about that.

That said, if there are things that can be improved in the library to ease the task of localization, feel free to send a PR and I'll consider it. All the code I get paid to write is written in English for an American audience so I'm not really very familiar with those types of considerations.

[lvv]

Yes, we can not use Unicode in literals. I was talking only about printing. C++ can easily can do this. Using hat is reasonable fallback for cases when we are on Windows or when locale is not UTF-8. Yes, it is extra work to check all this but output will be beautiful with unicode.

But even with hats-only, it will be improvement.

[nholthaus]

This is a bit trickier than I originally anticipated, because everyone's implicit assumption is that the undefined unit is an even multiple SI base units.

however, non-SI units need to be handled as well:
cout << 2.0_ft * 2.0_ft * 2.0_ft * 2.0_ft << endl;

this needs to show 0.138095597 m^4, not 16 m^4. That means a conversion needs to be done on the output that wasn't previously necessary. ft^4 isn't possible because as far as the library is concerned all length units are meters.

[nholthaus]

@dharmatech @lvv FYI this feature has been adopted in the v2.3.x development branch as of c8569bb. It will be part of the v2.3.0 production release.

Once the library goes C++17 (no ETA on that) I'll try again to update the output with unicode literals. For now it uses carrot notation.

Thank you very much for your contributions!