wg21 | Various documents and code related to proposals for WG21

I'm using the SG14 flat_map as a container.

As per a standard map, it takes Key and Value template parameters.

Unlike a standard map, however, it doesn't store std::pair in a binary search tree, but rather stores the keys and values in two separate containers (additional template arguments which default to std::vector)

Let's take P1907 as an example. Is it accepted into the C++ standard? To which version? When?

consider the coroutine's ReturnObject below and note the comments before the method ReturnObject::promise_type::return_void :

I am trying to initialize a span — that is, a list of pointers to const data. However, the rules for const conversion amongst pointers and span<>'s available constructors are thwarting me.

I'm sure there's a way to do it, but I cannot find the right casting/invocation.

Aside: I'm actually not using C++20, but tcb::span, which uses the older P0122R7 set of constructors, with (pointer,size) rather than iterators. But I suspect getting something working on C++20 will get me in the right direction.

The below example demonstrates what I'm trying to do, and some failed attempts at fixing it:

Live link on Godbolt

Another question discusses the legitimacy for the optimizer to remove calls to new: Is the compiler allowed to optimize out heap memory allocations?. I have read the question, the answers, and N3664.

From my understanding, the compiler is allowed to remove or merge dynamic allocations under the "as-if" rule, i.e. if the resulting program behaves as if no change was made, with respect to the abstract machine defined in the standard.

I tested compiling the following two-files program with both clang++ and g++, and -O1 optimizations, and I don't understand how it is allowed to to remove the allocations.

The standard defines several 'happens before' relations that extend the good old 'sequenced before' over multiple threads:

[intro.races]

11 An evaluation A simply happens before an evaluation B if either

(11.1) — A is sequenced before B, or
(11.2) — A synchronizes with B, or
(11.3) — A simply happens before X and X simply happens before B.

[Note 10: In the absence of consume operations, the happens before and simply happens before relations are identical. — end note]

12 An evaluation A strongly happens before an evaluation D if, either

(12.1) — A is sequenced before D, or
(12.2) — A synchronizes with D, and both A and D are sequentially consistent atomic operations ([atomics.order]), or
(12.3) — there are evaluations B and C such that A is sequenced before B, B simply happens before C, and C is sequenced before D, or
(12.4) — there is an evaluation B such that A strongly happens before B, and B strongly happens before D.

[Note 11: Informally, if A strongly happens before B, then A appears to be evaluated before B in all contexts. Strongly happens before excludes consume operations. — end note]

^{(bold mine)}

The difference between the two seems very subtle. 'Strongly happens before' is never true for matching pairs or release-acquire operations (unless both are seq-cst), but it still respects release-acquire syncronization in a way, since operations sequenced before a release 'strongly happen before' the operations sequenced after the matching acquire.

Why does this difference matter?

'Strongly happens before' was introduced in C++20, and pre-C++20, 'simply happens before' used to be called 'strongly happens before'. Why was it introduced?

[atomics.order]/4 says that the total order of all seq-cst operations is consistent with 'strongly happens before'.

Does it mean that it's not consistent with 'simply happens before'? If so, why not?

I'm ignoring the plain 'happens before', because it differs from 'simply happens before' only in its handling of memory_order_consume, the use of which is temporarily discouraged, since apparently most (all?) major compilers treat it as memory_order_acquire.

I've already seen this Q&A, but it doesn't explain why 'strongly happens before' exists, and doesn't fully address what it means (it just states that it doesn't respect release-acquire syncronization, which isn't completely the case).

Found the proposal that introduced 'simply happens before'.

I don't fully understand it, but it explains following:

• 'Strongly happens before' is a weakened version of 'simply happens before'.
• The difference is only observable when seq-cst is mixed with aqc-rel on the same variable (I think, it means when an acquire load reads a value from a seq-cst store, or when an seq-cst load reads a value from a release store). But the exact effects of mixing the two are still unclear to me.

Some ranges adaptors such as filter_­view, take_­while_­view and transform_view use std::optional's cousin copyable-box to store the callable object:

So I have code that uses std::weak_ptr and maintains them in an std::set, and that works just fine -- and has worked for the last 5 or 7 years. Recently I thought I'd fiddle with using them in an std::unordered_set (well, actually in an f14::F14ValueSet) and for that, I would need a hash of it. As of now, there is no std::hash, so what should I do instead?

The answer seems to be "just hash the control block", as implied by this question and reply: Why was std::hash not defined for std::weak_ptr in C++0x?, but how do I get access to the control block? In glibc, it's located at __weak_ptr<>::_M_refcount._M_pi-> but that's private (and implementation specific). What else can I do?

One answer is "just wait": maybe someday there will be a standard owner_hash() for std::weak_ptr, but I'd prefer something available now.

I am trying to generate unique IDs from template template parameters. I tried this function