mpusz/mp-units
1
0
Fork 1
mirror of https://github.com/mpusz/mp-units.git synced 2025-08-03 20:34:26 +02:00
Code Issues Packages Projects Releases Wiki Activity

docs: minor fixes

Browse Source
This commit is contained in:
Mateusz Pusz
2024-02-15 22:18:39 +01:00
parent 755a09d100
commit d5474cc095
3 changed files with 10 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/getting_started/faq.md
View File

@@ -25,6 +25,10 @@ Many reasons make UDLs a poor choice for a physical units library:
static_assert(std::is_same_v<decltype(d2)::rep, long double>);
```
When such UDL is intermixed in arithmetics with any quantity type of a shorter representation
type, it will always expand it to the longest one. In other words, such long type spreads until
all types use it everywhere.
3. While increasing the coverage for the library, we learned that many unit symbols conflict with
built-in types or numeric extensions. A few of those are: `F` (farad), `J` (joule), `W` (watt),
`K` (kelvin), `d` (day), `l` or `L` (litre), `erg`, `ergps`. Usage of the `_` prefix would make

2
docs/users_guide/framework_basics/interface_introduction.md
View File

@@ -81,7 +81,7 @@ without having to introduce hundreds of types to predefine them.
## Value-based equations
The **mp-units** library is based on C++20, significantly improving user experience. One of
such improvements are value-based equations.
such improvements is the usage of value-based equations.
As we have learned above, the entities are being used as values in the code, and they compose.
Moreover, derived entities can be defined in the library using such value-based equations.

13
docs/users_guide/use_cases/interoperability_with_other_libraries.md
View File

@@ -182,13 +182,10 @@ type trait:
For example, for our `Timestamp` type, we could provide the following:
```cpp
inline constexpr struct TimestampOrigin :
mp_units::absolute_point_origin<TimestampOrigin, mp_units::isq::time> {} TimestampOrigin;
template<>
struct mp_units::quantity_point_like_traits<Timestamp> {
static constexpr auto reference = si::second;
static constexpr auto point_origin = TimestampOrigin;
static constexpr auto point_origin = default_point_origin(reference);
using rep = decltype(Timestamp::seconds);
static constexpr convert_implicitly<quantity<reference, rep>> to_quantity(Timestamp ts)
@@ -203,7 +200,7 @@ struct mp_units::quantity_point_like_traits<Timestamp> {
};
```
After that, we can check that the [`QuantityLike`](../framework_basics/concepts.md#QuantityLike)
After that, we can check that the [`QuantityPointLike`](../framework_basics/concepts.md#QuantityPointLike)
concept is satisfied:
```cpp
@@ -226,7 +223,7 @@ int main()
// implicit conversion
quantity_point qp = ts;
std::cout << qp.quantity_from(TimestampOrigin) << "\n";
std::cout << qp.quantity_from_zero() << "\n";
// explicit conversion
print(Timestamp(qp));
@@ -286,7 +283,7 @@ Here is an example of how interoperability described in this chapter can be used
```cpp
using namespace std::chrono;
std::chrono::sys_seconds ts_now = floor<seconds>(system_clock::now());
sys_seconds ts_now = floor<seconds>(system_clock::now());
quantity_point start_time = ts_now;
quantity speed = 925. * km / h;
@@ -294,7 +291,7 @@ quantity distance = 8111. * km;
quantity flight_time = distance / speed;
quantity_point exp_end_time = start_time + flight_time;
std::chrono::sys_seconds ts_end = value_cast<int>(exp_end_time.in(s));
sys_seconds ts_end = value_cast<int>(exp_end_time.in(s));
auto curr_time = zoned_time(current_zone(), ts_now);
auto mst_time = zoned_time("America/Denver", ts_end);