Cool

clang diag when back

ha?

Finally the wait is over...[Hooray]

That's great! Thanks a lot!

I'd just tried to use new compiler in this submission [submission:277680488], got TLE

but previously absolutely same solution [submission:277680737] (1 char difference to be able to submit it again) gave me AC

MikeMirzayanov please pay attention on it

Cant use print :(

Savior-of-Cross bro can finally rest after asking from last 5 months.

Oh finally!, it is amazing, thanks a lot!!!

Thank you.

std::format will be very useful to make many output statements cleaner for those not using printf style format strings.

Before: std::cout << a << " + " << b << " = " << a+b << '\n';

After: std::cout << std::format("{} + {} = {}\n", a, b, a+b);

Quick benchmarking got really weird: an $$$\mathcal{O}(n \log^2{n})$$$ code on 1991C - Абсолютный ноль used like double runtime in C++23 compared to C++20:

• C++17 (405ms): 277693333
• C++20 (358ms): 277693378
• C++23 (968ms): 277693363

Was it a bug, or was it intended that way...?

Extra: trying to use set in that approach yielded 1500ms for C++20 (TL=2s), and instant TLE for C++23.

As of now, C++23 is not in the best shape, but when GCC will finally implement it, it will go hard.

Mainly for competitive programming, a C++23 gold nugget is std::print.

Finally clunky output with std::cout goes away in favor of elegant:

std::println("The meaning of the {} is {}", "universe" 42); // prints "The meaning of the universe is 42"

"Oh, nice printing, cool" you might think, but it gets better:

• You can finally print ranges and tuples

std::vector<std::pair<int, std::string>> vec = { {0, "hii"}, {1, "arul"} };
std::print("{}", vec); // prints [(0, "hii"), (1, "arul")]
// or not, they are not implemented yet :p

• It is faster than std::cout or printf (so maybe fast io hack won't be as used)

Also additional cool things are std::flat_set and std::flat_map that are basically(very roughly speaking) more cache-friendly counterparts of std::set and std::map. Will it be better than std::set and std::map for competitive programming? Time will tell, right now they are not even implemented in GCC.

Also there's deducing this which makes recursive lambdas not as weird (i am a certified lambda glazer, which means that deducing this is epic and cool)

Summarizing, C++23 adds great features for competitive programming. In theory. In reality, GCC 14.2 doesn't implement most features that folks on codeforces would find interesting

Amazing! No more cout (=

Thank you very much for the effort put into making c++23 available!

Thanks a lot!!!!!

genuine question: why are we naming it G++23, not C++23?

Unexpected news. But thanks!

I encountered a significant difference in execution time between two submissions that used the same code but different compiler versions, Solutions: C++20 and C++23 . The submission by C++20 was noticeably faster.

Why C++23 is slower in my case???

is there any plan on update on GCC? C11 5.10 is quite outdated imo

Wow! Is std::print available now?

Also, is codeforces the first onlinejudge which have GCC14?

Update: Emm, seems there are still some problems with std::print. :(

Update 2: Now the problems with std::print is fixed, thanks Mike. :)

Thanks

Cool update,but hope MikeMirzayanov can notice this about C[loud]F[are] we concerned about.

Finally, it happened.

auto!

when zig? when nim?

Please upgrade to 14.3 when it releases, dynamic_bitset is fixed in that version.

Thrilled to see G++23 now supported on Codeforces! Ready to leverage the latest C++ features. <3

COOOOOL! Does c++23 have constant optimization for stl or pbds?

Thats great but how can i find the new features of c++23?

Is the support for C++23 features incomplete in this compiler version? For example, is print still not usable. The following code will result in compilation errors:

#include <print>
#include <string>
#include <vector>

int main()
{
	std::string val = "hello";
	std::print("{}", val);
}

Cool LOL

After 40 years, c++ finally has print() function

It seems slow, and not able to use std::print and std::println for now

UPD1: Thank to mike that std::print and std::println are available.

UPD2: Sometime it's faster or slower, but within an acceptable range.

It's more likely to cause Runtime error than other g++ compiler for now. In C++20 (GCC 13-64) some code with boundary issues got Accept, but Runtime error in C++23 (GCC 14-64, msys2). It might have stricter boundary detection when using C++23 (GCC 14-64, msys2).

If you are getting errors like parsing errors or missing arguments, it is because the powershell is recognizing ',' as some special charachter.

Try this instead in that case:

g++ -std=c++23 -Wall -Wextra -Wconversion -static -DONLINE_JUDGE -Xlinker --stack=268435456 -O2 .\program.cpp

to compile the file, and since any name is not given in, the exe should be names to a.exe or something similar by default, and you can run that file by

.\a

Or, if you are an only-IDE person

All along, your code for compiling and running altogether will be

cd "PATH_TO_YOUR_WORKING_DIRECTORY" ; if ($$$?) { g++ -std=c++23 -Wall -Wextra -Wconversion -static -DONLINE_JUDGE -Xlinker --stack=268435456 -O2 .\program.cpp } ; if ($$$?) { .\a }

after using that command it still shows that gcc version is 13.2.0

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ C:\ProgramData\pbox\temp\65617\gcc14-64-winlibs$14.2.0-1>rd /S /Q gcc14-64-winlibs INFO [2024-08-23 14:52:28,631] Set environment variable 'GCC_14_64_WINLIBS_HOME=C:\Programs\gcc14-64-winlibs'. INFO [2024-08-23 14:52:28,631] Starting 'setx.exe GCC_14_64_WINLIBS_HOME C:\Programs\gcc14-64-winlibs /M'. INFO [2024-08-23 14:52:33,509] Successfully set environment variable 'GCC_14_64_WINLIBS_HOME=C:\Programs\gcc14-64-winlibs'. INFO [2024-08-23 14:52:40,241] Package 'gcc14-64-winlibs$14.2.0-1' installed to the 'C:\Programs\gcc14-64-winlibs'.

C:\Windows\System32>gcc --version gcc (MinGW-W64 x86_64-ucrt-mcf-seh, built by Brecht Sanders, r3) 13.2.0 Copyright (C) 2023 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

G++23 may cause some magical RE.

Submission using G++23: RE on #1 277773823

Submission using G++20: Accepted 277773900

UPD: Solved, I reversed the order

This release also includes Clang/LLD/LLDB 18.1.8, which might not meet the performance downgrade. Would we have a chance to test the clang compiler?

Also, it is easy to make the Clang use existing MSVC toolkits, by passing --target=x86_64-pc-windows-msvc and it would search and use MSSTL.

Some time ago, there was news here that we supported C++23 by installing GCC 14 from the Winlibs project. It turned out that with this method of supporting C++23, some compatibility issues lead to significant performance drops in certain submissions. So, I tried another distribution for GCC 14: the MSYS2 project. It seems that this problem does not occur with it, and now there are no unexpected performance drops. Let's test this C++23 support option together!

I wonder if the slow down bug still exists.

vector<vector<int>> TLE(7,vector<int>(40000));

ok, now please remove older versions of c++ as it creates confusion among participants

Why is my code slower in the C++23 compilation environment than in C++20? QAQ

How to get it in my local environment? How can I get the PBOX? Thanks.

Thanks a lot finally

Where can we find the implementation of it?

For some reason, I am still seeing a submission gets much slower when submitted as C++23, it is mainly doing operations on std::set:

C++23 (GCC 14-64, msys2) 2733 ms 284726189

C++20 (GCC 13-64). 983 ms 284731239

Hunches:

• std::set is slow, but I tried some small tests in custom test and didn't notice substantial differences, maybe need a specific size or operation sequence to trigger this if it's the case
• I/O is slow, which doesn't seem to be the case from test 29, also tried massive puts in custom test, the time is similar
• bad inline decision for those small functions, tried adding inline and it slightly reduced to 2499 ms 284734309 still a large gap

Also tried to reproduce locally with gcc 13.2 and 14.2 from docker and random data, but didn't observe differences.