c++20

Why does the first call not compile? auto get1 = []<int B>() { return B; }; auto get2 = []<typename B>(B b) { return b; }; int main() { get1<5>(); // error: no match for operator< get2(5); // ok } The reason I use this, is an expression repeated many times in code. Of course I can use a real function template, but just I am curious WHY. Barry This is easier to understand if you consider what the equivalent class type looks like to your get1 : struct get1_t { template <int B> operator()() const { return B; } }; get1_t get1; get1<5>(); // error You're trying to provide an explicit template

Let's say I have defined a zero_initialize() function: template<class T> T zero_initialize() { T result; std::memset(&result, 0, sizeof(result)); return result; } // usage: auto data = zero_initialize<Data>(); Calling zero_initialize() for some types would lead to undefined behavior 1, 2 . I'm currently enforcing T to verify std::is_pod . With that trait being deprecated in C++20 and the coming of concepts, I'm curious how zero_initialize() should evolve. What (minimal) trait / concept can guarantee memsetting an object is well defined? Should I use std::uninitialized_fill instead of std:

In a recently published paper [1], Herb Sutter et al. describe an extension of the programming language C++ by a three way comparison operator. The authors refer to a considerable number of earlier proposals, all of which were ultimately rejected. The clever core concept of the new approach is to encode different categories of relations in the return type of the comparison operator. The authors declare that The primary design goal is conceptual integrity [Brooks 1975], which means that the design is coherent and reliably does what the user expects it to do. A total of five categories of

According to the last meeting of the ISO C++ Committee, bit-cast will be introduced in C++20 standard. I know that reinterpret_cast is not suitable for this job due to type aliasing rules 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? Well, there is one obvious reason: because it wouldn't do everything that bit_cast does. Even in the C++20 world where we can allocate memory at compile time, reinterpret_cast is forbidden in constexpr functions.

The last draft of the c++ standard introduces the so-called "customization point objects" ( [customization.point.object] ), which are widely used by the ranges library. I seem to understand that they provide a way to write custom version of begin , swap , data , and the like, which are found by the standard library by ADL. Is that correct? How is this different from previous practice where a user defines an overload for e.g. begin for her type in her own namespace? In particular, why are they objects ? What are customization point objects? They are function object instances in namespace std

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? There are already two compilers that support C++ modules clang: http://clang.llvm.org/docs/Modules.html MS VS 2015: http://blogs