Wow, yesterday I've just said this, and today I meet the release of GCC 11! That's great!!! Yay!!!

What is the advantages?

Wow, latest gcc and c++20 support! Can't wait to try ;)

Seems like C++20 doesn’t introduce a lot for CP. Most useful probably are 3-way comparison shorthand and easier struct initialization.

Funnily enough, you can't actually write vector v{vector{1, 2}}; instead of what you said, it's equivalent to vector<int> v{vector{1, 2}}; which is the same as vector{1, 2}

I'm not sure there are many features useful in competitive programming

std::midpoint for example. Now your binary search implementation will never overflow

  auto a = numeric_limits<int32_t>::min();
  auto b = numeric_limits<int32_t>::max();
  cout << midpoint(a, b) << '\n';

Oh, also there are a lot of bit manipulation functions. std::has_single_bit — whether x is power of 2, std::popcount — you know what, etc.

Wow!!!That's great!!!

what is the function of operator <=> ? the operator can use for two values that can compare but < or == or > is return true. I can't think any uses of it.

i love codeforces be cause it is always up to date thanks mike for this update

1 min silence for those who still uses C++ 14

That's really good!

Does anyone know if ranges is good for competitive programming?

Thanks for the update to C++20!

Since it was asked in the post, here are some C++20 features I feel would be useful (and some making stuff merely easier to look at or type) in competitive programming in C++:

1. Finally casting from unsigned to signed variables is defined. Contrary to popular belief, this has not always been the case (it has been implementation-defined behaviour for casting elements >= INT_MAX), and one important issue is that it might affect some implementations of custom hashes. This is because C++20 finally enforces signed integers to be represented in twos-complement.
2. Formatted printing: You could do it using printf, but printf has severely limited functionality (more importantly, it doesn't deduce types and it doesn't work for user-defined types either). Using std::format, you can get Python-like printing, saving the formatted string to a buffer and so on.
3. The <bit> header for bit-related operations, which eliminates most of the need for using the __builtin_* family of functions, and gives some more useful things like has_single_bit, bit_ceil, bit_floor.
4. T::contains for T = std::map, std::set and family, which avoids pitfalls like using T::count for T = multiset.
5. std::midpoint that will finally prevent any overflow/underflow in binary search. A related function is std::lerp which does linear interpolation between two values while minimizing errors.
6. More attribute support for constant factor time and memory optimization.
7. std::ranges library would help you do something like sort a vector like you would do in Python, and avoid using iterators (iterators are super-handy, but writing both iterators doesn't make sense if they're going to be begin() and end() anyway). There are quite a few use-cases of std::ranges that might help make code more concise and expressive.
8. More stuff in the standard library/language is constexpr: If you like metaprogramming as much as (or more than) I do, this is probably the most exciting feature. Now that new is constexpr, it'll make life much easier to cheese problems by computing stuff at compile time, and you won't need to write your own constexpr allocators and stuff. This also means std::vector and std::string are constexpr, which will ease metaprogramming quite a bit too (even though there are a few limitations while using them in a constexpr context).
9. Designated initializers: Now you can assign member variables values by name (and perhaps skip some of them if they're to be initialized as if they're initialized by an empty list. As pointed out below, the order needs to be the same as declaration order. If you're memory optimizing by changing your struct layout by moving around a member variable, you won't need to change all your struct declarations everywhere, if you only ever default initialize that variable (i.e., don't mention it anywhere in the initialization).
10. Modules: This is not useful for competitive programming, but definitely, it looks much better IMO.
11. Concepts: This takes a nice Rust-like (and sort of Haskell-like) approach to defining the behaviour of types in a nicer manner. No more tons of std::enable_ifs and use of SFINAE.
12. 3-way comparison and default operator==: The first thing gets rid of having to declare multiple operators for the same order, and the second one eliminates the pesky compilation errors you get when you check for struct equality.
13. auto parameters of functions: This is officially called abbreviated function templates (because type deduction for auto is equivalent to that for templates). Remember auto return types in C++17? You can even do something like auto add(auto x, auto y) { return x + y; } or something like this now, rather than having to write out long templates.
14. std::ssize: Gives the signed size of a container. No more underflow errors while iterating with T::size if you replace it with T::ssize (and no more need to do typecasts either). This can also be used as ssize(container).
15. std::span: Something analogous to std::string_view but for general types (and contiguously stored elements). Might not be useful that much in competitive programming, but this has a nice interface with std::ranges.
16. Named constants in <numbers>: No more need to use acosl(-1.0) for pi, or exp(1) for e. They're defined (with many more constants) in this header.
17. starts_with and ends_with: This makes prefix/suffix string matching simpler (better and faster than extracting a substring and checking for equality).

I have done submit 132081784 and it had RE on first test. But when I have submitted same code 132085792 C++17 it got AC. So, it was because I have used non-standart allocator, without it, my code still works. I think that isn't right and I don't know how to fix it.

Did you add it specially before first Technocup qualification contest?)

When you have comparator function
auto cmp = [](const T&, const T&) -> bool { ... };,
you can now write
set<T, decltype(cmp)> s; instead of set<T, decltype(cmp)> s(cmp);

recently two of my solutions timed out/MLEd in C++ 17 64-bit but passed with a comfortable margin in C++17. Can anyone explain why is that the case? The difference was 100 MB for the MLE and ~0.2 sec for the TLE.

So why is 64 bit sometimes badder?

(I plan to use somehow such warnings in Polygon to suggest fixes in uploaded files)

This looks like a great idea! I would suggest to also include -Wshadow (mentioned here). At least for me, this is one of the most useful warnings.

Nice I need to keep switching between 4 versions xD

Codeforces - 20
Atcoder - 17
Codechef - 14
Topcoder - 11

Btw, MikeMirzayanov, would you please consider adding Clang not just for diagnostics?

• Many enterprises have already made the switch to it, especially big tech companies such as Google and Apple, so there are a lot of C/C++ coders who use it as the primary compiler, along with the rest of the LLVM ecosystem.
• It receives more attention from compiler engineering people, because its internals are much better organized compared to GCC, and also because it has more corporate-friendly license, allowing hardware companies such as Intel and AMD to maintain their own downstream versions and contribute hardware-specific optimizations.
• For this reason, LLVM is becoming the default in compiler engineering courses in universities and preferred in other programming courses (not in Russia though, but I believe most US universities have already switched).
• In my experience, it frequently beats GCC in terms of performance for algorithmic programming.

I'm working on a book about performance engineering with a lot of compiler-specific C/C++ examples, and the only reason I haven't ditched GCC for Clang/LLVM is that it isn't widely available in the competitive programming environment. Adding it to CodeForces will greatly catalyze the change.

• What else is useful?

You can now not implement a binary search for problems with binary search over a function f, if for whatever reason you don't want to do it, like so:

namespace r = std::ranges;
namespace v = std::views;
auto rng = v::iota(min,max+1) | v::transform([f](auto a) {return make_pair(f(a),a);});
auto it = r::lower_bound(rng,make_pair(true,min));

edit: this can also be reduced to this:

auto it = r::lower_bound(v::iota(min,max+1),true,{},f);

for (auto i : views::iota(0, n))

Thanks for this!

Please, add common lisp

It is very convenient to use projection functions when sorting structures. For example sorting edges by weight:

struct edge{ int v, u, w; };
vector<edge> e;
//input
ranges::sort(e, {}, &edge::w);

How about -Wshadow? Is it included in those?

When will release C++20 32-bit?

It seems that we can use chinese characters as variable names,is it?

my code in c++20 gives me TLE.

whereas the same code in c++17 gets accepted in 140ms.

can someone please tell the reason behind this.

I have different answers too

problem: https://mirror.codeforces.com/contest/459/submission/193205657

TLE 17 using GNU C++ 20 64: https://mirror.codeforces.com/contest/459/submission/193205461 ACC using GNU C++ 14 : https://mirror.codeforces.com/contest/459/submission/193205657

can anyone explain why?