[Last round](https://codeforces.net/blog/entry/65033) involved a randomized solution for problem E, and some pretests were aimed against std's rand() function. This caused a big dispute among contestants. It was questioned whether doing this type of tests was fair or necessary, since passing them depended merely on specific language knowledge, not actual problem-solving skills. Contest coordinators counter-argued that participants would've gotten hacked if it hadn't been for these pretests. They also stated that it's one's responsibility to know their favorite language when using it on a round.↵
↵
The fact is, this controversy was really caused by a technical property within C++ (and codeforces, partly), which many people had no clue existed. This is just an example of the fact that languages and their functioning in CF will sometimes have non-intuitive and unexpected properties, which may screw our performance in a contest. In other words, we are constantly exposed to bumping into another of these hidden behaviors, making the mentioned round hardly the last time something like this can happen.↵
↵
That's why I thought: We should have a list of the main language-specific issues that could annoy us during contests. Just a brief enumeration of not-so-fun facts about languages, such that, if not known, could break our solutions or get us hacked. Making a brief list available for the community, and exposing it to participants before a round could prevent a lot of trouble. If a problem could make you bump into one of these weird language issues, contest coordinators could safely assume we know about them and not get into a moral debate whether it's fair to include tests against it. Also, contestants would be safe from losing rating to specific language knowledge. In other words, we could prevent issues like the last round's with the least amount of effort. ↵
↵
This blog is an attempt to build up this list once and for all! It should include as much facts as possible, so I'm calling out for your help. If you've had trouble on a problem because of issues in the language, I invite you to help out contributing and write it as a comment. I'll update it in the list as soon as possible. You'd be helping out and preventing other people from going through the same annoying experience! I've included the very few facts I know about for now. It's not much, which is why anything you can share is useful!↵
Unhackable List↵
===============↵
C++↵
------------------↵
↵
<spoiler summary="Don't use rand()">↵
Using c++'s rand() is unsafe. Using it gives you a high chance of getting hacked or fayling systests, sometimes even pretests. [What to use instead](https://codeforces.net/blog/entry/61587).↵
</spoiler>↵
↵
↵
<spoiler summary="unordered_map can cause TLE">↵
C++'s unordered map uses a weak default hash function, which makes your solution hackable. [How to resolve it](https://codeforces.net/blog/entry/62393).↵
</spoiler>↵
↵
↵
<spoiler summary="std::random_device is unsafe in MinGW w64">↵
Every execution of std::random_device gives the same output when compiling with MinGW w64. [Details](https://sourceforge.net/p/mingw-w64/bugs/338/).↵
</spoiler>↵
↵
<spoiler summary="multiset::erase is unusual">↵
Calling multiset<T>::erase(T x) removes all elements in the set with value x. If you want to delete only one of them, do multiset<T>::erase(multiset::find(T x)). [Details](http://www.cplusplus.com/reference/set/multiset/erase/).↵
</spoiler>↵
↵
<spoiler summary="std::pow disregards precision">↵
This can happen for very small operations, even for numbers that fit perfectly in a double's representation. If using integer operations, try binary exponentiation instead. [More info](https://codeforces.net/blog/entry/21844).↵
</spoiler>↵
↵
<spoiler summary="size() in data structures is unsigned">↵
Normally this doesn't cause trouble, which is why it is more likely to catch you by surprise and screw you during a round. [Brief example](http://codeforces.net/blog/entry/4167).↵
</spoiler>↵
↵
<spoiler summary="cin/scanf slow when reading doubles">↵
Even with `cin.tie(0), ios::sync_with_stdio(false)`, you can get TLE by reading doubles. Here's an example:↵
↵
- Reading doubles: [submission:103335132]↵
- Without reading doubles: [submission:105614207]↵
↵
In that case, runtime was more than 10 times slower when reading doubles directly.↵
↵
Scanf is not as slow as cin, but it's still pretty slow: [submission:105614403].↵
↵
$421 ms$, versus the $93 ms$ of the solution that read integers and casted them into doubles. So basically, the best choice would be to write a custom input parser for doubles.↵
↵
This is honestly one of the most disappointing caveats I've seen in C++.↵
</spoiler>↵
↵
Java↵
------------------↵
↵
<spoiler summary="Arrays.sort() may cause TLE">↵
Using Arrays.sort() on primitives has worst case <math>O(n<sup>2</sup>)</math>. [How to sort safely](https://codeforces.net/blog/entry/7108).↵
</spoiler>↵
↵
Python↵
------------------↵
↵
<spoiler summary="Python recursion has low limit">↵
The recursion limit has a default value of 1000. [Here's how to change it](https://www.pythoncentral.io/resetting-the-recursion-limit/).↵
</spoiler>↵
↵
↵
↵
↵
The fact is, this controversy was really caused by a technical property within C++ (and codeforces, partly), which many people had no clue existed. This is just an example of the fact that languages and their functioning in CF will sometimes have non-intuitive and unexpected properties, which may screw our performance in a contest. In other words, we are constantly exposed to bumping into another of these hidden behaviors, making the mentioned round hardly the last time something like this can happen.↵
↵
That's why I thought: We should have a list of the main language-specific issues that could annoy us during contests. Just a brief enumeration of not-so-fun facts about languages, such that, if not known, could break our solutions or get us hacked. Making a brief list available for the community, and exposing it to participants before a round could prevent a lot of trouble. If a problem could make you bump into one of these weird language issues, contest coordinators could safely assume we know about them and not get into a moral debate whether it's fair to include tests against it. Also, contestants would be safe from losing rating to specific language knowledge. In other words, we could prevent issues like the last round's with the least amount of effort. ↵
↵
This blog is an attempt to build up this list once and for all! It should include as much facts as possible, so I'm calling out for your help. If you've had trouble on a problem because of issues in the language, I invite you to help out contributing and write it as a comment. I'll update it in the list as soon as possible. You'd be helping out and preventing other people from going through the same annoying experience! I've included the very few facts I know about for now. It's not much, which is why anything you can share is useful!↵
Unhackable List↵
===============↵
C++↵
------------------↵
↵
<spoiler summary="Don't use rand()">↵
Using c++'s rand() is unsafe. Using it gives you a high chance of getting hacked or fayling systests, sometimes even pretests. [What to use instead](https://codeforces.net/blog/entry/61587).↵
</spoiler>↵
↵
↵
<spoiler summary="unordered_map can cause TLE">↵
C++'s unordered map uses a weak default hash function, which makes your solution hackable. [How to resolve it](https://codeforces.net/blog/entry/62393).↵
</spoiler>↵
↵
↵
<spoiler summary="std::random_device is unsafe in MinGW w64">↵
Every execution of std::random_device gives the same output when compiling with MinGW w64. [Details](https://sourceforge.net/p/mingw-w64/bugs/338/).↵
</spoiler>↵
↵
<spoiler summary="multiset::erase is unusual">↵
Calling multiset<T>::erase(T x) removes all elements in the set with value x. If you want to delete only one of them, do multiset<T>::erase(multiset::find(T x)). [Details](http://www.cplusplus.com/reference/set/multiset/erase/).↵
</spoiler>↵
↵
<spoiler summary="std::pow disregards precision">↵
This can happen for very small operations, even for numbers that fit perfectly in a double's representation. If using integer operations, try binary exponentiation instead. [More info](https://codeforces.net/blog/entry/21844).↵
</spoiler>↵
↵
<spoiler summary="size() in data structures is unsigned">↵
Normally this doesn't cause trouble, which is why it is more likely to catch you by surprise and screw you during a round. [Brief example](http://codeforces.net/blog/entry/4167).↵
</spoiler>↵
↵
<spoiler summary="cin/scanf slow when reading doubles">↵
Even with `cin.tie(0), ios::sync_with_stdio(false)`, you can get TLE by reading doubles. Here's an example:↵
↵
- Reading doubles: [submission:103335132]↵
- Without reading doubles: [submission:105614207]↵
↵
In that case, runtime was more than 10 times slower when reading doubles directly.↵
↵
Scanf is not as slow as cin, but it's still pretty slow: [submission:105614403].↵
↵
$421 ms$, versus the $93 ms$ of the solution that read integers and casted them into doubles. So basically, the best choice would be to write a custom input parser for doubles.↵
↵
This is honestly one of the most disappointing caveats I've seen in C++.↵
</spoiler>↵
↵
Java↵
------------------↵
↵
<spoiler summary="Arrays.sort() may cause TLE">↵
Using Arrays.sort() on primitives has worst case <math>O(n<sup>2</sup>)</math>. [How to sort safely](https://codeforces.net/blog/entry/7108).↵
</spoiler>↵
↵
Python↵
------------------↵
↵
<spoiler summary="Python recursion has low limit">↵
The recursion limit has a default value of 1000. [Here's how to change it](https://www.pythoncentral.io/resetting-the-recursion-limit/).↵
</spoiler>↵
↵
↵
↵
