C++20 introduced &quot;destroying [`operator delete`](https://en.cppreference.com/w/cpp/memory/new/operator_delete)&quot;: new overloads of `operator delete` that take a tag-type [`std::destroying_delete_t`](https://en.cppreference.com/w/cpp/memory/new/destroying_delete_t) parameter.

What exactly is this and when is it useful?

What is &quot;destroying operator delete&quot; in C++20?

There are already two compilers that support C++ modules:

 - Clang: http://clang.llvm.org/docs/Modules.html
 - MS VS 2015: http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx

When starting a new project now, what should I pay attention to in order to be able to adopt the modules feature when it is eventually released in my compiler?

Is it possible to use modules and still maintain compatibility with older compilers that do not support it?

How should I write my C++ to be prepared for C++ modules?

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

In the CPP reference [documentation][1],


  [1]: https://en.cppreference.com/w/cpp/language/types

I noticed for `char`

&gt; The character types are large enough to represent any UTF-8 eight-bit
&gt; code unit (since C++14)

and for `char8_t`

&gt; type for UTF-8 character representation, required to be large enough
&gt; to represent any UTF-8 code unit (8 bits)


Does that mean both are the same type? Or does `char8_t` have some other feature?


Is C++20 &#39;char8_t&#39; the same as our old &#39;char&#39;?

The C++20 feature `std::source_location` is used to capture information about the context in which a function is called. 
When I try to use it with a variadic template function, I encountered a problem: I can&#39;t see a place to put the `source_location` parameter.

The following doesn&#39;t work because variadic parameters have to be at the end:

    // doesn&#39;t work
    template &lt;typename... Args&gt;
    void debug(Args&amp;&amp;... args,
               const std::source_location&amp; loc = std::source_location::current());

The following doesn&#39;t work either because the caller will be screwed up by the parameter inserted in between:

    // doesn&#39;t work either, because ...
    template &lt;typename... Args&gt;
    void debug(const std::source_location&amp; loc = std::source_location::current(),
               Args&amp;&amp;... args);

    // the caller will get confused
    debug(42); // error: cannot convert 42 to std::source_location

I was informed in a [comment](https://stackoverflow.com/questions/57540155/issue-converting-a-macro-with-variable-args-into-constexpr-variadic-templa#comment101546068_57540155) that `std::source_location` works seamlessly with variadic templates, but I struggle to figure out how.  How can I use `std::source_location` with variadic template functions?

How to use source_location in a variadic template function?

According to [cppreference](https://en.cppreference.com/w/cpp/types/type_info/operator_cmp), `std::type_info::operator!=` gets removed with C++20, however, `std::type_info::operator==` apparently remains.

What&#39;s the reasoning behind? I might agree on comparing for inequality being meaningless, but then comparing for equality would be just as meaningless as well, wouldn&#39;t it?

Similarly, `operator!=` of many other standard library types, including containers such as [`std::unordered_map::operator!=`][2] and [`std::unordered_set::operator!=`][3] will be removed in C++20 according to cppreference.

Having to write `if(!(id1 == id2))` doesn&#39;t make any code any clearer compared to `if(id1 != id2)`, in contrast, just the opposite...

[2]: https://en.cppreference.com/w/cpp/container/unordered_map/operator_cmp
[3]: https://en.cppreference.com/w/cpp/container/unordered_set/operator_cmp

Why is operator!= removed in C++20 for many standard library types?

As mentioned in a similarly worded question ([Why use bind over lambdas in c++14?][1]) The answer was - no reason (and also mentioned why it would be better to use lambdas).

My question is - if in C++14 there was no longer a reason to use bind, why did the standards committee found it necessary to add [`std::bind_front`](https://en.cppreference.com/w/cpp/utility/functional/bind_front) in C++20? 

Does it now have any new advantage over a lambda?


  [1]: https://stackoverflow.com/questions/17363003/why-use-stdbind-over-lambdas-in-c14

Why use `std::bind_front` over lambdas in C++20?

i have read the new c++20 feature `no_unique_address` several times and i hope if some one can explain and illustrate with an example better than this example below taken from c++ reference. 

&gt; Explanation Applies to the name being declared in the declaration of a
&gt; non-static data member that&#39;s not a bit field.
&gt; 
&gt; Indicates that this data member need not have an address distinct from
&gt; all other non-static data members of its class. This means that if the
&gt; member has an empty type (e.g. stateless Allocator), the compiler may
&gt; optimise it to occupy no space, just like if it were an empty base. If
&gt; the member is not empty, any tail padding in it may be also reused to
&gt; store other data members.

```
#include &lt;iostream&gt;
 
struct Empty {}; // empty class
 
struct X {
    int i;
    Empty e;
};
 
struct Y {
    int i;
    [[no_unique_address]] Empty e;
};
 
struct Z {
    char c;
    [[no_unique_address]] Empty e1, e2;
};
 
struct W {
    char c[2];
    [[no_unique_address]] Empty e1, e2;
};
 
int main()
{
    // e1 and e2 cannot share the same address because they have the
    // same type, even though they are marked with [[no_unique_address]]. 
    // However, either may share address with c.
    static_assert(sizeof(Z) &gt;= 2);
 
    // e1 and e2 cannot have the same address, but one of them can share with
    // c[0] and the other with c[1]
    std::cout &lt;&lt; &quot;sizeof(W) == 2 is &quot; &lt;&lt; (sizeof(W) == 2) &lt;&lt; &#39;\n&#39;;
}
```

 1. can some one explain to me what is the purpose behind this feature and when should i use it?
 2. *e1 and e2 cannot have the same address, but one of them can share with c[0] and the other with c[1]* can some one explain? why do we have such kind of relation ?

 

what is the new feature in c++20 [[no_unique_address]]?

Related to questions [How do I check for C++11 support?][1] and [https://stackoverflow.com/questions/38456127/what-is-the-value-of-cplusplus-for-c17][2]

How can I inquire whether the compiler can handle / is set up to use C++20? I know that it is, in principle, possible to inquire the C++ version by:

    #if __cplusplus &gt; ???
      // C++20 code here
    #endif

What should `???` be for C++20?


  [1]: https://stackoverflow.com/questions/5047971/how-do-i-check-for-c11-support
  [2]: https://stackoverflow.com/questions/38456127/what-is-the-value-of-cplusplus-for-c17

How do I check for C++20 support? What is the value of __cplusplus for C++20?

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?

According to [cppreference][1], the `operator!=` of many standard library types, including [`std::unordered_map::operator!=`][2] and [`std::unordered_set::operator!=`][3] is *removed* in C++20.

**What is the committee&#39;s rationale behind the decision?** Won&#39;t this make the comparison support asymmetric?


  [1]: http://en.cppreference.com/w/cpp
  [2]: https://en.cppreference.com/w/cpp/container/unordered_map/operator_cmp
  [3]: https://en.cppreference.com/w/cpp/container/unordered_set/operator_cmp

Removed operator!= in C++20 standard library

    #include &lt;compare&gt;
    
    struct A
    {
        int n;
    
        auto operator&lt;=&gt;(A const&amp; other) const
        {
            if (n &lt; other.n)
            {
                return std::strong_ordering::less;
            }
            else if (n &gt; other.n)
            {
                return std::strong_ordering::greater;
            }
            else
            {
                return std::strong_ordering::equal;
            }
        }
    
        // compile error if the following code is commented out.
        // bool operator==(A const&amp; other) const
        // { return n == other.n; }
    };
    
    int main()
    {   
        A{} == A{};
    }

See [online demo][1]

**Why must I provide** `operator ==` **when** `operator &lt;=&gt;` **is enough?**

  [1]: https://godbolt.org/z/x7T7r86zc

Why must I provide &#39;operator ==&#39; when &#39;operator &lt;=&gt;&#39; is enough?

Is it possible in &quot;modern C++&quot; (C++17 or greater) to pass a string literal as a parameter to a C++ template?

I realize you could do this with constructor argument; I just thought it would be more convenient to have it as a template argument, rather than buried deep in the cpp file. I was curious if maybe this was a new feature of modern C++. See Pseudo code below of what I&#39;m trying to do:

Pseudo-code Example:

    // Header File /////////////////////////
    template&lt;constexpr string Name&gt;
    class ModuleBase {
    public:
        ModuleBase();
        string name;
    };

    class xyz : ModuleBase&lt;&quot;xyz&quot;&gt; {
    public:
        xyz();
    };

    // Cpp File //////////////////////////
    template&lt;string_literal Name&gt;
    ModuleBase&lt;Name&gt;::ModuleBase() {
        name = Name;
    }

    xyz::xyz() : ModuleBase() {

    }


Is it possible in modern C++ to pass a string literal as a parameter to a C++ template?

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?

According to the last meeting of the ISO C++ Committee, [bit-cast][1] will be introduced in C++20 standard.

I know that `reinterpret_cast` is not suitable for this job due to [type aliasing rules][2] but my question is why did they choose not to extend the `reinterpret_cast` to treat the object like it bit sequence representation and preferred to give this functionality as a new language construct?


  [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0476r2.html
  [2]: https://en.cppreference.com/w/cpp/language/reinterpret_cast#Type_aliasing

C++20 bit_cast vs reinterpret_cast

While I was trying to learn about **C++** operators, I stumbled upon a strange comparison operator on [cppreference.com][1],&lt;sup&gt;*&lt;/sup&gt; in a table that looked like this:

![enter image description here][2]

&quot;Well, if these are common operators in C++, I better learn them&quot;, I thought. But all my attempts to elucidate this mystery were unsuccessful. Even here, on Stack Overflow I had no luck in my search.

## Is there a connection between **&lt;=&gt;** and **C++**?

And if there is, what does this operator do exactly?

&lt;sub&gt;* In the meantime cppreference.com updated that page and now contains information about the`&lt;=&gt;`operator.&lt;/sub&gt;

  [1]: http://en.cppreference.com/w/cpp/language/operator_comparison
  [2]: https://i.stack.imgur.com/bqEv0.jpg
  [3]: http://en.cppreference.com/mwiki/index.php?title=cpp/language/operator_comparison&amp;oldid=1408

What is the &lt;=&gt; (&quot;spaceship&quot;, three-way comparison) operator in C++?

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?

What are coroutines in [tag:C++20]?

In what ways it is different from &quot;Parallelism2&quot; or/and &quot;Concurrency2&quot; (look into below image)?

The below image is from ISOCPP.

https://isocpp.org/files/img/wg21-timeline-2017-03.png


[![enter image description here][1]][1]


  [1]: https://i.stack.imgur.com/4MtgA.png

What are coroutines in C++20?

I ran into this while debugging [this question](https://stackoverflow.com/questions/65638680/using-boost-strong-typedef-to-differentiate-arg-types-but-causing-seg-fault/65643014?noredirect=1#comment116069484_65643014).

I trimmed it down all the way to just using [Boost Operators](https://www.boost.org/doc/libs/1_75_0/libs/utility/operators.htm):

 1. **Compiler Explorer [C++17](https://godbolt.org/z/q89brM) [C++20](https://godbolt.org/z/szYx9E)**
    
        #include &lt;boost/operators.hpp&gt;
        
        struct F : boost::totally_ordered1&lt;F, boost::totally_ordered2&lt;F, int&gt;&gt; {
            /*implicit*/ F(int t_) : t(t_) {}
            bool operator==(F const&amp; o) const { return t == o.t; }
            bool operator&lt; (F const&amp; o) const { return t &lt;  o.t; }
          private: int t;
        };
        
        int main() {
            #pragma GCC diagnostic ignored &quot;-Wunused&quot;
            F { 42 } == F{ 42 }; // OKAY
            42 == F{42};         // C++17 OK, C++20 infinite recursion
            F { 42 } == 42;      // C++17 OK, C++20 infinite recursion
        }
    
    This program compiles and runs fine with C++17 (ubsan/asan enabled) in both GCC and Clang.
    
 1. When you change the _implicit_ constructor to `explicit`, the problematic lines obviously **[no longer compile on C++17](https://godbolt.org/z/hq4fve)**

Surprisingly both versions **compile on C++20 ([v1](https://godbolt.org/z/onMzo5) and [v2](https://godbolt.org/z/b1Pav5))**, but they lead to **infinite recursion** (crash or tight loop, depending on optimization level) on the two lines that wouldn&#39;t compile on C++17.

Obviously this kind of silent bug creeping in by upgrading to C++20 is worrisome.

Questions:

 - Is this c++20 behaviour conformant (I expect so)
 - What exactly is interfering? I suspect it might be due to c++20&#39;s new &quot;spaceship operator&quot; support, but don&#39;t understand **how** it changes the behaviour of this code.



C++20 behaviour breaking existing code with equality operator?

[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


Why is std::ssize() introduced in C++20?

A slightly strange question, however, if I remember correctly, C++ source code doesn&#39;t require a file system to store its files.

Having a compiler that scans handwritten papers via a camera would be a conforming implementation. Although practically not making that much sense.

However C++20 now adds source location with [`file_name`][1]. Does this now imply that source code should always be stored in a file?

  [1]: https://en.cppreference.com/w/cpp/utility/source_location/file_name



Does C++20 mandate source code being stored in files?

[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?

What is the difference between the C++20 chrono types/values `month{7}` and `months{7}`?  Isn&#39;t it confusing to have two such similar names?


What is the difference between chrono::month and chrono::months

I was told that the following code has undefined behavior until C++20:

    int *p = (int*)malloc(sizeof(int));
    *p = 10;

Is that true?

The argument was that the lifetime of the `int` object is not started before assigning the value to it ([P0593R6][1]). To fix the problem, placement `new` should be used:

    int *p = (int*)malloc(sizeof(int));
    new (p) int;
    *p = 10;

Do we really have to call a default constructor that is trivial to start the lifetime of the object?

At the same time, the code does not have undefined behavior in pure C. But, what if I allocate an `int` in C code and use it in C++ code?

    // C source code:
    int *alloc_int(void)
    {
        int *p = (int*)malloc(sizeof(int));
        *p = 10;
        return p;
    }

    // C++ source code:
    extern &quot;C&quot; int *alloc_int(void);

    auto p = alloc_int();
    *p = 20;

Is it still undefined behavior?

  [1]: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html#motivating-examples

Is using malloc for int undefined behavior until C++20

### Contrary to all other similar questions, this question is about using the new C++ features.

* 2008 [tag:c] [Is there a simple way to convert C++ enum to string?](/questions/201593)
* 2008 [tag:c] [Easy way to use variables of enum types as string in C?](/questions/147267)
* 2008 [tag:c++] [How to easily map c++ enums to strings](/questions/207976)
* 2008 [tag:c++] [Making something both a C identifier and a string?](/questions/126277)
* 2008 [tag:c++] [Is there a simple script to convert C++ enum to string?](/questions/201593)
* 2009 [tag:c++] [How to use enums as flags in C++?](/questions/1448396)
* 2011 [tag:C++] [How to convert an enum type variable to a string?](/questions/5093460)
* 2011 [tag:c++] [Enum to String C++](/questions/6281461)
* 2011 [tag:c++] [How to convert an enum type variable to a string?](/questions/5093460)
* 2012 [tag:c] [How to convert enum names to string in c](/questions/9907160)
* 2013 [tag:c] [Stringifying an conditionally compiled enum in C](/questions/18790332)

### After reading many answers, I did not yet find any:

* Elegant way using [C++11], [C++14] or [C++17] new features
* Or something ready-to-use in [Boost](http://www.boost.org/doc/libs/release/)
* Else something planned for [C++20]

### Example

An example is often better than a long explanation.  
You can compile and run this snippet on [Coliru](http://coliru.stacked-crooked.com/a/5fd889116289d906).  
&lt;sup&gt;([Another former example](http://coliru.stacked-crooked.com/a/bb58819257b6df50) is also available)&lt;/sup&gt;

    #include &lt;map&gt;
    #include &lt;iostream&gt;
    
    struct MyClass
    {
        enum class MyEnum : char {
            AAA = -8,
            BBB = &#39;8&#39;,
            CCC = AAA + BBB
        };
    };
    
    // Replace magic() by some faster compile-time generated code
    // (you&#39;re allowed to replace the return type with std::string
    // if that&#39;s easier for you)
    const char* magic (MyClass::MyEnum e)
    {
        const std::map&lt;MyClass::MyEnum,const char*&gt; MyEnumStrings {
            { MyClass::MyEnum::AAA, &quot;MyClass::MyEnum::AAA&quot; },
            { MyClass::MyEnum::BBB, &quot;MyClass::MyEnum::BBB&quot; },
            { MyClass::MyEnum::CCC, &quot;MyClass::MyEnum::CCC&quot; }
        };
        auto   it  = MyEnumStrings.find(e);
        return it == MyEnumStrings.end() ? &quot;Out of range&quot; : it-&gt;second;
    }
    
    int main()
    {
       std::cout &lt;&lt; magic(MyClass::MyEnum::AAA) &lt;&lt;&#39;\n&#39;;
       std::cout &lt;&lt; magic(MyClass::MyEnum::BBB) &lt;&lt;&#39;\n&#39;;
       std::cout &lt;&lt; magic(MyClass::MyEnum::CCC) &lt;&lt;&#39;\n&#39;;
    }

### Constraints

* Please no valueless duplication of [other answers](/a/10177840/938111) or [basic link](/a/18791363/938111).
* Please avoid bloat macro-based answer, or try to reduce the `#define` overhead as minimum as possible. 
* Please no manual `enum` -&gt; `string` mapping.

### Nice to have

* Support `enum` values starting from a number different from zero
* Support negative `enum` values
* Support fragmented `enum` values 
* Support `class enum` (C++11)
* Support `class enum : &lt;type&gt;` having any allowed `&lt;type&gt;` (C++11)
* Compile-time (not run-time) conversions to a string,&lt;br&gt;
  or at least fast execution at run-time (e.g. `std::map` is not a great idea...)
* [`constexpr`][ce] (C++11, then relaxed in C++14/17/20)
* [`noexcept`][ne] (C++11)
* [C++17][]/[C++20][] friendly snippet

One possible idea could be using the C++ compiler capabilities to generate C++ code at compilation-time using meta-programming tricks based on `variadic template class` and `constexpr` functions...

[C99]:   https://en.wikipedia.org/wiki/C99
[C11]:   https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29
[C++11]: https://en.wikipedia.org/wiki/C%2B%2B11
[C++14]: https://en.wikipedia.org/wiki/C%2B%2B14
[C++17]: https://en.wikipedia.org/wiki/C%2B%2B17
[C++20]: https://en.wikipedia.org/wiki/C%2B%2B20

[ce]:  https://en.cppreference.com/w/cpp/language/constexpr
[ne]:  https://en.cppreference.com/w/cpp/language/noexcept

[Vittorio Romeo]: http://stackoverflow.com/users/598696
[Karoly Horvath]: http://stackoverflow.com/users/650405

[PlasmaHH]:       http://stackoverflow.com/users/833362

enum to string in modern C++11 / C++14 / C++17 and future C++20

With C++20 we can read the term &quot;niebloid&quot; more often now in the cppreference. 

On SO we can find today 2020/07/16  2 articles mentioning it:

 - [First post][1]
 - [Second post][2], talking about customization point objects

Google does also not spit out that many results. The most prominent is maybe [here][3].


Can somebody shed a little bit more light on niebloids?


  [1]: https://stackoverflow.com/questions/62093977/practical-difference-between-a-struct-with-only-operator-and-a-normal-function/62094376#62094376
  [2]: https://stackoverflow.com/questions/53495848/what-are-customization-point-objects-and-how-to-use-them/53516153#53516153
  [3]: https://thephd.github.io/a-weakness-in-the-niebloids

What is a niebloid?

Based on the following it looks like coroutines in C++20 will be stackless. 

https://en.cppreference.com/w/cpp/language/coroutines

I&#39;m concerned for many reasons:

 1. On embedded systems heap allocation is often not acceptable.
 2. When in low level code, nesting of co_await would be useful (I don&#39;t believe stackless co-routines allow this).

&gt; With a stackless coroutine, only the top-level routine may be
&gt; suspended. Any routine called by that top-level routine may not itself
&gt; suspend. This prohibits providing suspend/resume operations in
&gt; routines within a general-purpose library.

https://www.boost.org/doc/libs/1_57_0/libs/coroutine/doc/html/coroutine/intro.html#coroutine.intro.stackfulness

 3. More verbose code because of the need for custom allocators and memory pooling.

 4. Slower if the task waits for the operating system to allocate it some memory (without memory pooling).

Given these reasons, I&#39;m really hoping I&#39;m very wrong about what the current coroutines are.

The question has three parts:

 1. Why would C++ choose to use stackless coroutines?
 2. Regarding allocations to save state in stackless coroutines. Can I use alloca() to avoid any heap allocations that would normally be used for the coroutine creation. 

&gt; coroutine state is allocated on the heap via non-array
&gt; operator new.
https://en.cppreference.com/w/cpp/language/coroutines

 3. Are my assumptions about the c++ coroutines wrong, why?

EDIT:

I&#39;m going through the cppcon talks for the coroutines now, if I find any answers to my own question I&#39;ll post it (nothing so far).

*CppCon 2014: Gor Nishanov &quot;await 2.0: Stackless Resumable Functions&quot;*

https://www.youtube.com/watch?v=KUhSjfSbINE

*CppCon 2016: James McNellis “Introduction to C++ Coroutines&quot;*

https://www.youtube.com/watch?v=ZTqHjjm86Bw


Are stackless C++20 coroutines a problem?

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?

`constinit` is a new [keyword](http://eel.is/c++draft/lex.key) and [specifier](http://eel.is/c++draft/dcl.constinit) in C++20 which was proposed in [P1143](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1143r2.html).

The following example is provided in the standard:

    const char * g() { return &quot;dynamic initialization&quot;; }
    constexpr const char * f(bool p) { return p ? &quot;constant initializer&quot; : g(); }
    constinit const char * c = f(true);     // OK
    constinit const char * d = f(false);    // ill-formed

A few questions come to mind:

  * What does `constinit` mean? Why was it introduced? In which cases should we use it?

  * Does it make a variable immutable? Does it imply `const` or `constexpr`?

  * Can a variable be both `const` and `constinit`? What about `constexpr` and `constinit`?

  * To which variables can the specifier be applied? Why cannot we apply it to non-`static`, non-`thread_local` variables?

  * Does it have any performance advantages?

&lt;sub&gt;*This question is intended to be used as a reference for upcoming questions about `constinit` in general.*&lt;/sub&gt;


What is `constinit` in C++20?

This bit of code compiled in C++20 (using gcc 10.1) without using the ```typename``` keyword before the dependent type ```std::vector&lt;T&gt;::iterator```. Why does it compile?
```
#include &lt;vector&gt;

template&lt;typename T&gt;
std::vector&lt;T&gt;::iterator // Why does this not require &quot;typename&quot; before it?
f() { return {}; }

int main() {
    auto fptr = &amp;f&lt;int&gt;;
}
```

[code playground](https://godbolt.org/z/WhSs53)

Why don&#39;t I need to specify &quot;typename&quot; before a dependent type 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;m running into a strange behavior with the new spaceship operator `&lt;=&gt;` in C++20. I&#39;m using Visual Studio 2019 compiler with `/std:c++latest`.

This code compiles fine, as expected:

    #include &lt;compare&gt;

    struct X
    {
        int Dummy = 0;
        auto operator&lt;=&gt;(const X&amp;) const = default; // Default implementation
    };

    int main()
    {
        X a, b;

        a == b; // OK!

        return 0;
    }

However, if I change **X** to this:

    struct X
    {
        int Dummy = 0;
        auto operator&lt;=&gt;(const X&amp; other) const
        {
            return Dummy &lt;=&gt; other.Dummy;
        }
    };

I get the following compiler error:

`error C2676: binary &#39;==&#39;: &#39;X&#39; does not define this operator or a conversion to a type acceptable to the predefined operator`

I tried this on clang as well, and I get similar behavior.

I would appreciate some explanation on why the default implementation generates `operator==` correctly, but the custom one doesn&#39;t.

non-defaulted operator &lt;=&gt; doesn&#39;t generate == and != in C++20

Recently I&#39;ve gotten suggestions to use `span&lt;T&gt;`&#39;s in my code, or have seen some answers here on the site which use `span`&#39;s - supposedly some kind of container. But - I can&#39;t find anything like that in the C++17 standard library. 

So what is this mysterious `span&lt;T&gt;`, and why (or when) is it a good idea to use it if it&#39;s non-standard?



What is a &quot;span&quot; and when should I use one?

Apparently, `consteval` is going to be a keyword in C++20. The [cppreference page][1] for it is currently blank. What is it going to be and how does it relate to `constexpr`?


  [1]: https://en.cppreference.com/w/cpp/keyword/consteval

What is consteval?

`std::bit_width` finds minimum bits required to represent an integral number `x` as `1+floor(log(x))`

Why does `std::bit_width` return 0 for the value 0? Shouldn&#39;t it return 1, Since the number of bits required to represent 0 is 1?

Also, I think the `1` in the formula is an offset.

Why does std::bit_width return 0 for the value 0, shouldn&#39;t it return 1?

There&#39;s a new comparison operator `&lt;=&gt;` in C++20. However I think in most cases a simple subtraction works well:

    int my_strcmp(const char *a, const char *b) {
        while (*a == *b &amp;&amp; *a != 0 &amp;&amp; *b != 0) {
            a++, b++;
        }
        // Version 1
        return *a - *b;
        // Version 2
        return *a &lt;=&gt; *b;
        // Version 3
        return ((*a &gt; *b) - (*a &lt; *b));
    }

They have the same effect. I can&#39;t really understand the difference.

All C++20 Solutions on Gang of Coders

Total of 36 C++20 Solutions

What is "destroying operator delete" in C++20?