These are not new things, hence the term &quot;legacy&quot;. This is simply how the cppreference site chooses to reconcile the fact that C++20 will have two different things that are both &quot;concepts&quot; called &quot;RandomAccessIterator&quot; (well, until C++20 decided to rename their version `random_access_iterator`).

Pre-C++20, a &quot;concept&quot; was just a set of requirements in the standard that represented the behavior expected of certain template parameters. In C++20, with concepts becoming an actual language feature, that needed to shift. The problem is that the Ranges `concept` of &quot;`RandomAccessIterator`&quot; is *not the same* as the old-style &quot;concept&quot; of &quot;RandomAccessIterator&quot;.

Since C++ considers them both to be &quot;concepts&quot; (though only the newer one is a `concept` in the language sense), they would both have the same page name on the Wiki. And MediaWiki doesn&#39;t really allow that.

So the maintainers of the site settled on using &quot;Legacy&quot; to differentiate them. Note that the actual *standard* doesn&#39;t use this &quot;Legacy&quot; prefix.

Note that the C++20 standard does have a prefix for the older concepts: &quot;Cpp17&quot;. So the old concept would be &quot;Cpp17RandomAccessIterator&quot;. That was not deemed appropriate for Cppreference for obvious reasons.

I know how to create a simple countdown timer in Java. But I&#39;d like to create this one in Kotlin. 

```lang-kotlin
package android.os;

new CountDownTimer(20000, 1000) {
    public void onTick(long millisUntilFinished) {
        mTextField.setText(&quot;seconds remaining: &quot; + millisUntilFinished / 1000);
    }
    public void onFinish() {
        mTextField.setText(&quot;Time&#39;s finished!&quot;);
    }
}.start();
```

How can I do it using Kotlin?


  [1]: https://stackoverflow.com/questions/54827455/how-to-implement-timer-with-kotlin-coroutines

How to create a simple countdown timer in Kotlin?

I&#39;m using JEST for unit testing my express routes.

While running the `yarn test` all my test case are getting passed, but I&#39;m getting an error 

    Jest did not exit one second after the test run has completed.
    
    This usually means that there are asynchronous operations that weren&#39;t stopped in your tests. Consider running Jest with `--detectOpenHandles` to troubleshoot this issue.

I used `async` &amp; `done`, but still it throws the above error. 

Below is my spec code. Please help

**routes.spec.ts**

    const request = require(&#39;supertest&#39;);
    describe(&#39;Test the root path&#39;, () =&gt; {
      const app = require(&#39;./index&#39;);
    
      test(&#39;GET /gql/gql-communication-portal/release-notes&#39;, async (done) =&gt; {
        const response = await request(app).get(&#39;/gql/gql-communication-portal/release-notes&#39;);
        expect(response.status).toBe(200);
        done();
      });
    });


Jest did not exit one second after the test run has completed using express

I noticed that most if not all containers now require their `::iterator` type to satisfy `LegacySomethingIterator` instead of `SomethingIterator`. 

For example, `std::vector&lt;&gt;::iterator` [now requires](https://en.cppreference.com/w/cpp/container/vector):

&gt; `iterator` 	[_LegacyRandomAccessIterator_](https://en.cppreference.com/w/cpp/named_req/RandomAccessIterator)


This seems to be the same for most of the other containers, all requiring their iterators to go from `SomethingIterator` to `LegacySomethingIterator`.

There are also the &quot;new&quot; requirements that took the names of the old requirements, such as [`RandomAccessIterator`](https://en.cppreference.com/w/cpp/experimental/ranges/iterator/RandomAccessIterator), why were these added? It seems to me that the new variants just shadow the legacy variants, no differences.

Why were new ones created in the first place, their requirements look the same to me. Why don&#39;t the new ones just replace the old requirements instead of right now having 2 different names for them (e.g. `RandomAccessIterator` and `LegacyRandomAccessIterator`)?

New iterator requirements

I noticed that most if not all containers now require their <code>::iterator</code> type to satisfy <code>LegacySomethingIterator</code> instead of <code>SomethingIterator</code>.
For example, <code>std::vector&#x3C;>::iterator</code> <a href="https://en.cppreference.com/w/cpp/container/vector" target="_blank" rel="noopener noreferrer">now requires</a>:
> <code>iterator</code> 	<a href="https://en.cppreference.com/w/cpp/named_req/RandomAccessIterator" target="_blank" rel="noopener noreferrer">LegacyRandomAccessIterator</a>
This seems to be the same for most of the other containers, all requiring their iterators to go from <code>SomethingIterator</code> to <code>LegacySomethingIterator</code>.
There are also the "new" requirements that took the names of the old requirements, such as <a href="https://en.cppreference.com/w/cpp/experimental/ranges/iterator/RandomAccessIterator" target="_blank" rel="noopener noreferrer"><code>RandomAccessIterator</code></a>, why were these added? It seems to me that the new variants just shadow the legacy variants, no differences.
Why were new ones created in the first place, their requirements look the same to me. Why don't the new ones just replace the old requirements instead of right now having 2 different names for them (e.g. <code>RandomAccessIterator</code> and <code>LegacyRandomAccessIterator</code>)?

I am studying C++ and I saw a range-based `for` loop like this:

    for (int i : {1,2,3,4,5})
        std::cout &lt;&lt; i &lt;&lt; &#39; &#39;;

What is the temporary `{1,2,3,4,5}` in the for loop behind the scenes?




What is the following list of behind the scenes inside the range-based for loop?

&lt;!-- language: cxx --&gt;

    template &lt;typename CRTP&gt;
    struct Pre {
        CRTP &amp; operator++();
    };

    template &lt;typename CRTP&gt;
    struct Post {
        CRTP operator++(int);
    };

    struct Derived
        : Pre&lt;Derived&gt;
        , Post&lt;Derived&gt;
    {};

    int main() {
        Derived d;
        d++;
        ++d;
    }
    
I get these errors from GCC:

&lt;!-- language: none --&gt;

    &lt;source&gt;: In function &#39;int main()&#39;:
    &lt;source&gt;:18:10: error: request for member &#39;operator++&#39; is ambiguous
            d++;
            ^~
    &lt;source&gt;:8:14: note: candidates are: CRTP Post&lt;CRTP&gt;::operator++(int) [with CRTP = Derived]
            CRTP operator++(int);
                ^~~~~~~~
    &lt;source&gt;:3:16: note:                 CRTP&amp; Pre&lt;CRTP&gt;::operator++() [with CRTP = Derived]
            CRTP &amp; operator++();
                    ^~~~~~~~
    &lt;source&gt;:19:11: error: request for member &#39;operator++&#39; is ambiguous
            ++d;
            ^
    &lt;source&gt;:8:14: note: candidates are: CRTP Post&lt;CRTP&gt;::operator++(int) [with CRTP = Derived]
            CRTP operator++(int);
                ^~~~~~~~
    &lt;source&gt;:3:16: note:                 CRTP&amp; Pre&lt;CRTP&gt;::operator++() [with CRTP = Derived]
            CRTP &amp; operator++();
                    ^~~~~~~~

Pre-decrement and post-decrement operators cause similar errors. No such errors with Clang. Any ideas what could be wrong or how to work around this?

GCC can&#39;t differentiate between operator++() and operator++(int)

I know that an *&quot;undefined behaviour&quot;* in C++ can pretty much allow the compiler to do anything it wants. However, I had a crash that surprised me, as I assumed that the code was safe enough.

In this case, the real problem happened only on a specific platform using a specific compiler, and only if optimization was enabled.

I tried several things in order to reproduce the problem and simplify it to the maximum. Here&#39;s an extract of a function called `Serialize`, that would take a bool parameter, and copy the string `true` or `false` to an existing destination buffer.

Would this function be in a code review, there would be no way to tell that it, in fact, could crash if the bool parameter was an uninitialized value?

    // Zero-filled global buffer of 16 characters
    char destBuffer[16];
    
    void Serialize(bool boolValue) {
        // Determine which string to print based on boolValue
        const char* whichString = boolValue ? &quot;true&quot; : &quot;false&quot;;
        
        // Compute the length of the string we selected
        const size_t len = strlen(whichString);
        
        // Copy string into destination buffer, which is zero-filled (thus already null-terminated)
        memcpy(destBuffer, whichString, len);
    }

If this code is executed with clang 5.0.0 + optimizations, it will/can crash.

The expected ternary-operator `boolValue ? &quot;true&quot; : &quot;false&quot;` looked safe enough for me, I was assuming, &quot;Whatever garbage value is in `boolValue` doesn&#39;t matter, since it will evaluate to true or false anyhow.&quot;

I have setup a [Compiler Explorer example](https://godbolt.org/z/DoFmhA) that shows the problem in the disassembly, here the complete example. *Note: in order to repro the issue, the combination I&#39;ve found that worked is by using Clang 5.0.0 with -O2 optimisation.*

    #include &lt;iostream&gt;
    #include &lt;cstring&gt;
    
    // Simple struct, with an empty constructor that doesn&#39;t initialize anything
    struct FStruct {
        bool uninitializedBool;
        
       __attribute__ ((noinline))  // Note: the constructor must be declared noinline to trigger the problem
       FStruct() {};
    };
    
    char destBuffer[16];
    
    // Small utility function that allocates and returns a string &quot;true&quot; or &quot;false&quot; depending on the value of the parameter
    void Serialize(bool boolValue) {
        // Determine which string to print depending if &#39;boolValue&#39; is evaluated as true or false
        const char* whichString = boolValue ? &quot;true&quot; : &quot;false&quot;;
        
        // Compute the length of the string we selected
        size_t len = strlen(whichString);
        
        memcpy(destBuffer, whichString, len);
    }
    
    int main()
    {
        // Locally construct an instance of our struct here on the stack. The bool member uninitializedBool is uninitialized.
        FStruct structInstance;
        
        // Output &quot;true&quot; or &quot;false&quot; to stdout
        Serialize(structInstance.uninitializedBool);
        return 0;
    }

The problem arises because of the optimizer: It was clever enough to deduce that the strings &quot;true&quot; and &quot;false&quot; only differs in length by 1. So instead of really calculating the length, it uses the value of the bool itself, which *should* technically be either 0 or 1, and goes like this:

    const size_t len = strlen(whichString); // original code
    const size_t len = 5 - boolValue;       // clang clever optimization

While this is &quot;clever&quot;, so to speak, my question is: **Does the C++ standard allow a compiler to assume a bool can only have an internal numerical representation of &#39;0&#39; or &#39;1&#39; and use it in such a way?**

Or is this a case of implementation-defined, in which case the implementation assumed that all its bools will only ever contain 0 or 1, and any other value is undefined behaviour territory?

Does the C++ standard allow for an uninitialized bool to crash a program?

[tag:c++14] introduced generic lambdas that made it possible to write following:

    auto func = [](auto a, auto b){
        return a + b;
    };
    auto Foo = func(2, 5);
    auto Bar = func(&quot;hello&quot;, &quot;world&quot;);

It is very clear that this generic lambda `func` works just like a templated function `func` would work.

Why did the C++ committee decide to add template syntax for generic lamda?



What is the need of template lambda introduced in C++20 when C++14 already has generic lambda?

One of the corners of C++20 concepts is that there are certain situations in which you have to write `requires requires`. For instance, this example from [\[expr.prim.req\]/3](http://eel.is/c++draft/expr#prim.req-3):

&gt; A _requires-expression_ can also be used in a _requires-clause_ ([temp]) as a way of writing ad hoc constraints on template arguments such as the one below:
&gt;
&gt; 
    template&lt;typename T&gt;
      requires requires (T x) { x + x; }
        T add(T a, T b) { return a + b; }

&gt; The first requires introduces the _requires-clause_, and the second introduces the _requires-expression_. 

What is the technical reason behind needing that second `requires` keyword? Why can&#39;t we just allow writing:

    template&lt;typename T&gt;
      requires (T x) { x + x; }
        T add(T a, T b) { return a + b; }

&lt;sub&gt;(Note: please don&#39;t answer that the grammar `requires` it)&lt;/sub&gt;

Why do we require requires requires?

In Rust, the main tool for abstraction are *traits*. In C++, there are two tools for abstractions: abstract classes and templates. To get rid of some of the disadvantages of using templates (e.g. hard to read error messages), C++ introduced *concepts* which are [&quot;named sets of requirements&quot;](https://en.cppreference.com/w/cpp/language/constraints). 

Both features *seem* to be fairly similar: 

- Defining a trait/concept is done by listing requirements. 
- Both can be used to bound/restrict generic/template type parameters.
- Rust traits and C++ templates with concepts are both monomorphized (I know Rust traits can also be used with dynamic dispatch, but that&#39;s a different story). 

But from what I understand, there are also notable differences. For example, C++&#39;s concepts seem to define a set of expressions that have to be valid instead of listing function signatures. But there is a lot of different and confusing information out there (maybe because concepts only land in C++20?). That&#39;s why I&#39;d like to know: **what exactly are the differences between and the similarities of C++&#39;s concepts and Rust&#39;s traits?**

Are there features that are only offered by either concepts or traits? E.g. what about Rust&#39;s associated types and consts? Or bounding a type by multiple traits/concepts? 

What are the similarities and differences between C++&#39;s concepts and Rust&#39;s traits?

Working with C++20&#39;s `concept`s I noticed that `std::unique_ptr` appears to fail to satisfy the [`std::equality_comparable_with&lt;std::nullptr_t,...&gt;`][equality_comparable_with] concept. From [`std::unique_ptr`][unique_ptr]&#39;s definition, it is supposed to implement the following when in C++20:

```cpp
template&lt;class T1, class D1, class T2, class D2&gt;
bool operator==(const unique_ptr&lt;T1, D1&gt;&amp; x, const unique_ptr&lt;T2, D2&gt;&amp; y);

template &lt;class T, class D&gt;
bool operator==(const unique_ptr&lt;T, D&gt;&amp; x, std::nullptr_t) noexcept;
```

This requirement _should_ implement symmetric comparison with `nullptr` -- which from my understanding is sufficient for satisfying `equality_comparable_with`. 

Curiously, this issue appears to be consistent on all the major compilers. The following code is rejected from Clang, GCC, and MSVC:

```cpp
// fails on all three compilers
static_assert(std::equality_comparable_with&lt;std::unique_ptr&lt;int&gt;,std::nullptr_t&gt;);
```

&lt;kbd&gt;[Try Online](https://gcc.godbolt.org/z/4W631dxz7)&lt;/kbd&gt;

However the same assertion with `std::shared_ptr` is accepted:

```cpp
// succeeds on all three compilers
static_assert(std::equality_comparable_with&lt;std::shared_ptr&lt;int&gt;,std::nullptr_t&gt;);
```

&lt;kbd&gt;[Try Online](https://gcc.godbolt.org/z/PessKoPqY)&lt;/kbd&gt;

[equality_comparable_with]: https://en.cppreference.com/w/cpp/concepts/equality_comparable
[unique_ptr]: https://en.cppreference.com/w/cpp/memory/unique_ptr/operator_cmp

Unless I&#39;m misunderstanding something, this appears to be a bug.
My question is whether this is a coincidental bug in the three compiler implementations, or is this a defect in the C++20 standard?

**Note:** I&#39;m tagging this [tag:language-lawyer] in case this happens to be a defect.

Why is unique_ptr not equality_comparable_with nullptr_t in C++20?


In C++20, we are now able to constrain the `auto` keyword to only be of a specific type. So if I had some code that looked like the following without any constraints:
```
auto something(){
  return 1;
}

int main(){
  const auto x = something();
  return x;
}
```
The variable `x` here is deduced to be an `int`. However, with the introduction of C++20, we can now constrain the `auto` to be a certain type like this:
```
std::integral auto something(){
  return 0;
}

int main(){
  const auto x = something();
  return x;
}
```
Doesn&#39;t this defeat the purpose of `auto` here? If I really need a `std::integral` datatype, couldn&#39;t I just omit the `auto` completely? Am I misunderstanding the use of `auto` completely?



Doesn&#39;t constraining the &quot;auto&quot; in C++ defeat the purpose of it?

I&#39;ve recently read about ``[[nodiscard]]`` in C++17, and as far as I understand it&#39;s a new feature (design by contract?) which forces you to use the return value. This makes sense for controversial functions like `std::launder` (nodiscard since C++20), but I wonder why `std::move` isn&#39;t defined like so in C++17/20. Do you know a good reason or is it because C++20 isn&#39;t finalised yet?

Why is std::move not [[nodiscard]] in C++20?

In C++17, this code is illegal:

    constexpr int foo(int i) {
        return std::integral_constant&lt;int, i&gt;::value;
    }

That&#39;s because even if `foo` can be evaluated at compile-time, the compiler still needs to produce the instructions to execute it at runtime, thus making the template instantiation impossible.

In C++20 we will have `consteval` functions, which are required to be evaluated at compile-time, so the runtime constraint should be removed. Does it mean this code will be legal?

    consteval int foo(int i) {
        return std::integral_constant&lt;int, i&gt;::value;
    }

Will consteval functions allow template parameters dependent on function arguments?

[C++20][1] introduced the `std::ssize()` free function as below:

```c++
template &lt;class C&gt;
    constexpr auto ssize(const C&amp; c)
        -&gt; std::common_type_t&lt;std::ptrdiff_t,
                              std::make_signed_t&lt;decltype(c.size())&gt;&gt;;
```

A possible implementation seems using `static_cast`, to convert the return value of the `size()` member function of cl*ass C* into its signed counterpart.

Since the `size()` member function of C always returns non-negative values, why would anyone want to store them in signed variables? In case one really wants to, it is a matter of simple `static_cast`. 

Why is `std::ssize()` introduced in C++20?

  [1]: https://en.wikipedia.org/wiki/C%2B%2B20


Content Type	Original Author	Original Content on Stackoverflow
Question	Hatted Rooster	View Question on Stackoverflow
Solution 1 - C++	Nicol Bolas	View Answer on Stackoverflow

New iterator requirements

C++ Problem Overview

C++ Solutions

Solution 1 - C++

Jest did not exit one second after the test run has completed using express

How to create a simple countdown timer in Kotlin?

Attributions