It would be part of #388, if that one becomes reality.

Other than that attempt at a translation, we don't have any C++ tutorial / guideline at all. And there are lots of other C++ related topics, that could add. E.g. when to use map/unordered map, policy-based data structures, interactive problems, those tricks like including bits/stdc++.h, avoiding hacking attempts with hashing, ...

I'm open to adding those to the site, if somebody takes the effort and writing up articles.

What about having this short article for now and maybe expanding it to C++ in CP later? That's a quite broad topic

Sure, why not.

Also I've heard that including bits/stdc++.h would increase compilation times since you are asking the compiler to parse and decide what to include from every single header file. Also it's not portable and you should have your imports in a code template anyway. I know people do it anyway, like using namespace std, but that could cause silly problems as well.

• Compile time: It's possible to precompile the bits/stdc++.h, and you probably will gain some speed using it. But also with it, the compile time is not that terrible.
• Portable: It's pretty portable. It should works for every g++ installation. On Linux, Windows, Mac.

I'm generally in favor of using bits/stdc++.h. Just because it avoids a huge template with 30+ includes.
And using namespace std is completely fine in competitive programming (in opposite to any real-life projects with dependencies).

Portability I mean some people on Windows may be using Microsoft compiler or clang on other platforms. Anyway I digress on those code-saving tricks

I've also come across some people using #define int long long. I was pretty sure this would break something in libraries but then I thought int is only required only to be 16-bits and I don't think any library would mind it being at least 64 bits (with signed main to get around main required to have type int). I haven't decided if this is a travesty or reasonable but I am tempted by the devil.

I occasionally use #define int int64_t, though generally suggested practice is using int64_t directly. I kind of think that it's easier to code this way, though some other side effects include not being able to write min(0, x) for int x, because 0 is of type int, and some compilers wouldn't even allow min(0LL, x), because they think long long and int64_t are different types.

Another caveat is that on some compilers it might require you to use twice as much memory when you don't need it or make your execution time slower, so one should wary of using it in time/memory critical environment. Other than that, my personal opinion is it's fine to use the define, as long as you understand what you're doing.

P.S. Do I understand correctly that you're working on the article on this topic right now?

Thanks for your response. I can quickly whip up an article just to have some info on it

There was a pull request with this in #939, but @adamsoltan withdrew it...

If the old PR is not going to be revived, I can whip up a quick article

Should psychological tips be added too? Like in an Um_Nik blog: stop worrying about rating, stop obsessing over saving time typing, master the fundamentals before learning advanced data structures which don't appear in Div2 and 3 contests

https://codeforces.com/blog/entry/92248
https://codeforces.com/blog/entry/113785