Yep, that's my pull request. :-) At the moment, it's usable if you build the microsoft/STL repo with VS 2022 17.4 Preview 3 or later. When VS 2022 17.5 Preview 1 ships (in the very near future; can't say when exactly), it will be "in box" without the need to build our GitHub repo.
It will still be necessary to build the std.ixx source file (to produce std.ifc and std.obj for consumption; we will never ship prebuilt IFCs/OBJs for the standard modules). It takes maybe 3-5 seconds and doesn't need to be rebuilt until you change your compiler options or upgrade your toolset. Build system support for doing this automatically is a work in progress.
Although we have test coverage running that exercises every header of the Standard Library through `import std;`, we're still working on fixing various compiler bugs, especially in complicated scenarios (e.g. using Ranges through modules). My hope is that the experience will be solid by the time that VS 2022 17.5 is released for production.
std::format is available, with all C++20 Defect Reports implemented, in VS 2019 16.11.14 (and all later 16.11.x) and VS 2022 17.2 (and all later 17.x).
It’s actually inverse cube for magnets - see https://en.wikipedia.org/wiki/Force_between_magnets : “One characteristic of a dipole field is that the strength of the field falls off inversely with the cube of the distance from the magnet's center.”
constexpr bool test_is_even() {
assert(is_even(0));
assert(!is_even(1));
// … more test coverage
return true;
}
int main() {
test_is_even(); // runtime coverage
static_assert(test_is_even()); // compile-time coverage
This lets us run all test cases at both runtime and compiletime. (The static_assert performs constant evaluation, and if an assert within test_is_even would fail, it won’t be a constant expression.)
> I'm curious if anybody is working to make C++ faster to compile.
Yes - C++20 added support for modules to the Core Language (both "header units" and "named modules"; header units are an intermediate step between classic includes and named modules), and support for header units to the Standard Library. Compiler/library support is a work in progress (MSVC's STL, which I work on, is the furthest along - see https://github.com/microsoft/STL/issues/1694 for status), but header units are showing significant improvements in compiler throughput (build speed). This looks like `import <vector>;` in your source code (with significant build system changes to build vector as a header unit, producing vector.ifc and vector.obj).
There's a proposal under review for C++23 to add named modules for the Standard Library, see https://wg21.link/p2465r2 . If this is accepted, `import std;` (or `import std.compat;`) will be the one-line way to use the entire C++ Standard Library with (what we hope will be) even better compiler throughput.
The primary limitation of header units and especially named modules is macros: neither can be influenced by macros defined in the source file, and named modules can't emit macros at all. Thus, one will still need to `#include <cassert>` in addition to `import std;` if you want the `assert()` macro.
Produce-consume ends up not working for almost all starting conditions. A lot of tiles seem tuned for a game where players leave their dice around, particularly as goods on planets, but it turns out you don't really need more than 9 dice. Players spend much of the game fishing for 6-devs, especially 6-devs that reward the player for playing a bunch of devs. If you don't get those, you can try to win with the 6-devs that reward you for playing a bunch of planets, but it's tough. Random access to starting conditions that do something, cheap planets that give red dice, and dev-oriented 6-devs ends up feeling bad, since these tiles are so much better than the other tiles.
I didn't play with expansions because they aren't on the phone app. This might be unfair, because I'm comparing it to Race with expansions.
I opened the spreadsheet, and now I can't remove it from my list of Google Sheets (unlike most shared spreadsheets). Am I missing some obscure way to remove it, despite the Remove option being grayed out? (It does respect the "Owned by me" filter so this isn't the end of the world.)
It will still be necessary to build the std.ixx source file (to produce std.ifc and std.obj for consumption; we will never ship prebuilt IFCs/OBJs for the standard modules). It takes maybe 3-5 seconds and doesn't need to be rebuilt until you change your compiler options or upgrade your toolset. Build system support for doing this automatically is a work in progress.
Although we have test coverage running that exercises every header of the Standard Library through `import std;`, we're still working on fixing various compiler bugs, especially in complicated scenarios (e.g. using Ranges through modules). My hope is that the experience will be solid by the time that VS 2022 17.5 is released for production.