IMHO, that is too little, too late. Neither was the compiler updated to any recent version, nor does CodinGame support the current version of the standard. To put it bluntly: After three years, the language update consists of flipping one command-line switch that you should have put there right away in the first place?
Professionals who work with modern C++ have long committed C++20 to muscle memory, are anticipating C++23 support to improve and are currently actively exploring C++26 features. I don’t consult cppreference anymore to check if a particular C++20 feature is supported by my compiler, I write my code under the firm assumption it does. Getting bitten by lack of support by a compiler that is outdated by many years is frustration that I do not need in my leisure time. And when onboarding junior co-workers, we cannot direct them here for training either: They need to learn our restrictions and coding guidelines anyway, so it doesn’t matter if CodinGame were to support more features than what we are using in our production code (spoiler: you don’t). But the converse is not true: We don’t want our juniors to learn outdated patterns, because of lack of support by the toolchain they use during training.
@_CG_Simon one week to go to the next bot programming contest. Any plans to do a language update beforehand? Access to C++23 features would be nice (instead of half-baked support of C++20 from a compiler that is many years out of date). Latest GCC and Clang both support the vast majority of C++23 features.
I’m afraid there won’t be any more language update before the challenge.
Just so you know, updating a language isn’t just a matter of changing a number somewhere. We have lots of compatibility issues to consider to make it fit our technical restrictions and to not break existing codes, whether on CodinGame or on CoderPad Screen (which share the same execution stack).
We are also discussing options to lift these difficulties and greatly improve our flexibility regarding language updates, but it’ll take time. Thanks for you patience
Hi @TwoSteps
I have reported this 4 years ago, it seems that the same problem exists with all the challenges and with this most recent Summer event 2024.
Random Timeouts occur on Groovy code. Do you think it can be solved?
Uh not sure TwoSteps is still active here, maybe you could follow up @_CG_Simon?
@_CG_Simon: Next opportunity upcoming; let’s update that GCC to something that actually supports C++20 (and put the switch to c++23 at the same time) for fall challenge '24! I know it’s not quite as easy as a command-line switch, but surely you have your build containers dockerised? I’d think it should be doable within a couple of hours to setup a new build environment, no?
You know, this is a real-world issue. I’m currently hiring a C++ engineer, and we’re about to start the coding interviews. Our code-base is actively using many recent C++ features, and so a main question to the candidates is how they can handle that. You guessed it, we’re not using CoderPad for our interviews. (Also: C++ Online IDE & Code Editor for Technical Interviews is grossly self-inconsistent; it mentions three different compiler versions, and two different versions of the standard - none of which is recent enough for us).
I have not heard anything. The current compilation times are not quite as abysmal any more, but still not good: about 12 s for an almost empty program, as compared to 2 s for Java, so still unusable for CoC. @_CG_dhubleur, do you have more info?
That’s a pity. Just for reference, Simon’s answer was to an enquiry made two contests (i.e. half a year) ago. In Spring, I did still participate normally, but in autumn, I only participated marginally; i.e. whatever I could do in python, but no C++.
Given that CoderPad’s whole business-model seems to be centered around providing an online sandbox tor programming languages for coding interviews, I’d have expected them to have a modern DevOps infrastructure to continuously deliver language updates. It should need as little as a Dockerfile to setup each toolchain, with which you could hand-off compilation jobs to a Kubernetes cluster using k8s-run or similar. Then, a manual toolchain update would be as simple as a two-line change in a dockerfile, and a bit of web-scraping could fully automate that. Contact me privately, if you want me to build a proof-of-concept for you. I might even do it for free (except a bit of insider information on the next contest - just kidding ;-).
PS; In autumn, I hired a C++ engineer for my team for which I would have loved to use CoderPad, but couldn’t, because the C++ one can write on this platform here bears little resemblance with the code we write in my company.
Thanks for your suggestion, work is well underway to enable us to modernize our execution stack and thus facilitate language updates. Unfortunately, as Simon said, there’s much more impact on the products than we can see on the surface, and it takes time. But believe me, we’re all looking forward to delivering it
I would add that it’s not just about running the code:
It needs to be able to running thousands of codes in parallel
It needs to prevent any user from being able to impact others users (cpu, memory and disk)
It needs to prevent any user from doing unwanted stuff (mining bitcoin, using it as a DDOS tool…)
It needs to unsure fairness between users (in terms of memory, cpu and disk)
It needs to be able to respond quickly to the client
It needs to limit the resources it needs so the company doesn’t go bankrupt
We currently rely on a system built by hands which is pretty good at respecting those constraints, at the cost of a higher maintenance effort. A new more modern system will eventually come when it’ll be ready.
Kubernetes is indeed a good candidate to build a solution on though, but it still have downsides and limitations that needs to be circumvented.
Feel free to suggest anything you feel like is relevant to help us, but keep in mind that’s something that was already deeply investigated.
