Language request: C++14

Please pass -std=c++14 to g++ to enable C++14 instead of the current C++11 mode. C++14 does bring quite a few productivity enhancements that I’ve found myself needing very early in the game (to cite just one notable example: generic lambdas).

Additionally but less importantly (I’m new to the game so I haven’t found myself needing those yet, but I’m anticipating), sorted by decreasing interest:

- It would be nice to be able to include Boost libraries. In “day to day” C++, Boost is virtually a must-have extension of the standard library.
  - It would be nice to compile with optimizations turned on (not sure if it would really make a difference in any of the puzzles?)

  • It would be nice to have g++5.x

Thanks for your time, and I think your site is pretty fun.

11 Likes

Is there any word from the coding game team when they would consider updating/ passing the c++14 flag? I would appreciate C++14 as well. It’s great to get familiar with C++14 features using Coding Game and we’re already awaiting C++17.
iso cpp status

2 Likes

Wholly agreed, there’s some exciting stuff in there I don’t get to use (yet) otherwise. Please update!

Codingame staff, for your convenience, this is the flag to copy/paste:

-std=c++14 -O3

:innocent:

6 Likes

I think what the IDE needs is some kind of flags or compiler parameters line, not limited to c++ or to a specific set of arbitrary parameters.
I don’t know if changing the C++11 to C++14 could add some compiler problems to existing code of players, this must be checked. The same with updating GCC to a much newer version.
The O3 is usually good but I sometimes need to disable the Pragma to find a bug, so an always on O3 could be a problem too. And maybe I prefer O2 or Ofast…
So it should be more flexible a compiler parameter line, or selectable flags, this way also others Lang can benefit (C#, Rust, Pascal…)

I can’t say for C++11 and C++14. But i know some code will not compile with a newer version of GCC.

The problem is bigger than that. C++ need some flag at compilation time, but Java need some flag in the run command line (for the garbage collector behavior).

Do you have an example ? I thought the C++ Standard was trying to make it as backwards compatible as possible. The only thing I can see are tri-graphs in c++17 … And I don’t think I’ve ever seen anyone using them.

@Agade have an example of such a code. Recently he had problem with multiple versions of GCC with the same code.

I think you’re referring to his openmp bug. Fortunately (or maybe not ?) it’s a plain bug and not a language regression.
The bug is fixed from gcc 6 and so on. (And technically this wouldn’t affect CG since we can’t use openmp here).

As far as i know, the problem is whith Agade’s Gitc code. I don’t think there’s any openmp in it.

Here are some examples of things that could break:

I question if these things are really a problem, but that’s not up to me to decide.

Offtopic: ppl ask for -O3 too, but that might not always be wise to have as a default.It’s easy to work around though. Just use this pragma: #pragma GCC optimize “O3,omit-frame-pointer,inline”

Ok ! Nevermind what I just said then :slight_smile:

Ah thanks a lot for this link ! This wil be useful !

True. But from what I’ve heard (from Magus), the standard library is still not optimised with this. Thus, vectors, maps, and all the containers and functions provided by the stl are really slow. I think the classic example was to try the difference between std::pow and coding your own pow function.

Unfortunaly, there’s some differences between pragmas and the real O3 flag. The STL is still slow without the flag, whatever you try. @pb4 tried something like 50 differents pragmas and it is still the same. You just can’t use the STL in a contest where you need performances.

But having O3 always and by default would be the worst idea ever. Since you can’t debug anything with O3 activated (no more stack when you crash).

I always asked for one thing: Adding a new language without any achievements (like the last Swift language added) called “C++ with -O3”. Don’t touch at the current C++ language.

2 Likes

I had two problems, but both were for Arena code, not AI code. One was with an OpenMP bug Aveuh mentioned, and one was with using the copy constructor of __gnu_cxx::stdio_filebuf. So I don’t have in mind any examples of AI code breaking with newer versions of gcc.

that’s a shame, but good to know. I’ve only tried some of the puzzles and the bot challenges, and didn’t hit any ceiling yet. I try and force myself to use STL for almost everything to help myself familiarize with the functions I don’t use regularly in my daily job. I guess if I try the other challenges, I might as well code in C.

I am curious to see a benchmark on CG with STL, anyone have some code to share? There are some #defines included with -O3 in the command line that are not with the #pragma. Doing the same manually before any #includes might actually yield equal performance to the command line. Here’s a couple I’ve found in the gcc docs, there might be more:

#undef __NO_INLINE__
#define __OPTIMIZE__ 1

Or maybe test the code on Godbolt.org and check if both codes create the same asm output .

On a very simple test (adding a million ints to a vector, then printing them), by adding all of the flags provided by Gulzt and reCurse both codes don’t compile to the same asm in Godbolt. So I think the flags are not equivalent as compiling with -O3. But I have no idea if there is still a difference in speed. I should try both and profile them …

I do not know all the innards of gcc and its stl, but since the stl is typically considered as code external to the compiler, I don’t see why it couldn’t give the same output barring some weird internal flag only set with O3 on the command line.

There has to be more #defines or something else. Maybe giving a look at their stl implementation code (e.g. their < vector >) would give more clues.

Is there a status update on introducing C++14?

Offtopic:
We went a bit offtopic, I noticed there is a topic for discussing optimization here:
Optimisation discussion