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

docs: 2.2 release announcement updated

Browse Source
This commit is contained in:
Mateusz Pusz
2024-04-17 12:16:40 +01:00
parent 94b4d0a3e3
commit da9340005f
1 changed files with 42 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

49
docs/blog/posts/2.2.0-released.md
View File

@@ -1,6 +1,6 @@
--- ---
draft: true draft: true
date: 2024-01-09 date: 2024-04-17
authors: authors:
- mpusz - mpusz
categories: categories:
@@ -35,7 +35,7 @@ the C++ modules' support is still really limited.
- Ninja 1.11 - Ninja 1.11
- clang-17 - clang-17
In the upcoming months, hopefully the situation will improve with the gcc-14 release and In the upcoming months, hopefully, the situation will improve with the gcc-14 release and
bug fixes in MSVC. bug fixes in MSVC.
!!! note !!! note
@@ -68,7 +68,7 @@ In this release, we also highly limited the number of CMake targets (**breaking
correspond exactly to the C++ modules they provide. This means that many smaller partial targets correspond exactly to the C++ modules they provide. This means that many smaller partial targets
were removed. We also merged text output targets with the core library's definition. were removed. We also merged text output targets with the core library's definition.
The table below specifies where we can find now the contents of previously available CMake targets: The table below specifies where we can now find the contents of previously available CMake targets:
| Before | Now | | Before | Now |
|---------------------------|---------------------| |---------------------------|---------------------|
@@ -95,6 +95,41 @@ _mp-units/compat_macros.h_. This header file should be explicitly included befor
modules if we want to benefit from the [Wide Compatibility tools](../../users_guide/use_cases/wide_compatibility.md). modules if we want to benefit from the [Wide Compatibility tools](../../users_guide/use_cases/wide_compatibility.md).
## Better control over the library's API
With this release, nearly all of the Conan and CMake build options were refactored with the intent
of providing better control over the library's API.
Previously, the library used the latest available feature set supported by a specific
compiler. For example,
[`quantity_spec` definitions would use CRTP](../../users_guide/framework_basics/systems_of_quantities.md#defining-quantities)
on an older compiler or provide a simpler API on a newer one thanks to the C++23 `this` deduction
feature. This could lead to surprising results where the same code written by the user would
compile fine on one compiler but not the other.
From this release, all API extensions have their corresponding configuration options in Conan and
CMake. With this, a user has full control over the API exposed by the library. Those options expose
three values:
- `True` - The feature is always enabled (the configuration error will happen if the compiler does
not support this feature)
- `False` - The feature is disabled, and an older alternative is always used.
- `Auto` - The feature is automatically enabled if the compiler supports it (old behavior).
Additionally, some CMake options were renamed to better express the impact on our users
(**breaking change**). For example, now CMake options include:
- `MP_UNITS_API_*` - options affecting the library's API,
- `MP_UNITS_BUILD_*` - options affecting the build process,
- `MP_UNITS_DEV_*` - options primarily useful for the project developers or people who want to
compile our unit tests and examples.
!!! info
To learn more, please refer to the [Build options](../../getting_started/installation_and_usage.md#build-options)
chapter.
## Simplified quantity point support ## Simplified quantity point support
This release significantly simplifies the usage of quantity points and affine space abstractions This release significantly simplifies the usage of quantity points and affine space abstractions
@@ -124,7 +159,7 @@ As we can see above, the new design allows
of the implicit point origin. Otherwise, an explicit origin still always has to be provided during of the implicit point origin. Otherwise, an explicit origin still always has to be provided during
initialization. initialization.
Also, we introduced a possibility to specify a default point origin in the units definition. Also, we introduced the possibility of specifying a default point origin in the unit definition.
With that, we could provide proper temperature scales without forcing the user to always use With that, we could provide proper temperature scales without forcing the user to always use
the origins explicitly. Also, a new member function, `.quantity_from_zero(),` was introduced the origins explicitly. Also, a new member function, `.quantity_from_zero(),` was introduced
that always returns the quantity from the unit's specific point origin or from the absolute that always returns the quantity from the unit's specific point origin or from the absolute
@@ -188,14 +223,14 @@ requires the Unicode symbol to be provided as a UTF-8 literal:
## Improved text output ## Improved text output
With this release we can print not only whole quantities but also just their units or dimensions. With this release, we can print not only whole quantities but also just their units or dimensions.
Also, we fixed the `std::format` support so users can now enjoy full C++20 compatibility and Also, we fixed the `std::format` support so users can now enjoy full C++20 compatibility and
don't have to use [fmtlib](https://github.com/fmtlib/fmt) anymore. don't have to use [fmtlib](https://github.com/fmtlib/fmt) anymore.
We have also changed the grammar for quantities formatting (**breaking change**). It introduces We have also changed the grammar for quantities formatting (**breaking change**). It introduces
the composition of underlying formatters that finally allows us to properly format user-defined the composition of underlying formatters that finally allows us to properly format user-defined
representation types (assuming they have `std::format` support). Additionally, thanks to a representation types (assuming they have `std::format` support). Additionally, thanks to a
new `%?` token we can provide a custom format string that will properly print quantity of any unit. new `%?` token, we can provide a custom format string that will properly print quantity of any unit.
Here is a small preview of what is now available: Here is a small preview of what is now available:
@@ -237,7 +272,7 @@ quantity points.
## Even better error messages ## Even better error messages
This release made a few small refactorings that without changing the user-facing API allowed us This release made a few small refactorings that, without changing the user-facing API, allowed us
to improve the readability of the generated types that can be observed in the compilation errors. to improve the readability of the generated types that can be observed in the compilation errors.
Example 1 (clang): Example 1 (clang):