mathturbator's blog

cin vs scanf
By mathturbator, history, 9 years ago, In English

These are links to my 2 submissions: 1) http://codeforces.net/contest/588/submission/13653807 2) http://codeforces.net/contest/588/submission/13653815

Only difference between both is that in 1) am using scanf to take input while in 2) am using cin. Although my logic remains the same, I got TLE and possible penalty (if this had happened during contest). Just because I used cin, does it make my submission wrong? If not, should time limits be set such that solutions are not rejected on usage of cin?

  • Vote: I like it
  • -22
  • Vote: I do not like it

»
9 years ago, # |
← Rev. 3   Vote: I like it 0 Vote: I do not like it

Tips to speed up cin Use std::ios_base::sync_with_stdio(false); and you'll be fine. Also, avoid using endl when you can use '\n'. Old compilers may slow cin down a little, always submit using C++11 if issues persist. Hope this helps!

→ Reply
  • »
    »
    9 years ago, # ^ |
      Vote: I like it 0 Vote: I do not like it

    I tried with C++11 and it still gave me TLE. And while I know that cin is slower than scanf, and that using scanf or your tips would be a better choice and help me accept my solution, but my point was if it is ok to judge a solution wrong just because you used a slower input method which itself is not so outdated or "not used anymore".

    → Reply
    • »
      »
      »
      9 years ago, # ^ |
        Vote: I like it +6 Vote: I do not like it

      The issue with setting time limits so that 'vanilla' cin will be fast enough is the possibility of allowing unintended solutions to pass if they are written with scanf (for example, an O(N^2) solution passing where an O(NlogN) solution is desired).

      Yes, it sucks if you have a good solution that TLEs due to slow i/o. But generally, people will make this mistake once and then learn how to avoid it. Meanwhile, relaxed time limits that allow unintended solutions to pass have a much more significant negative impact on contest quality.

      → Reply
»
9 years ago, # |
  Vote: I like it 0 Vote: I do not like it

The speed of cin is just as fast as scanf if you include the following at the beginning of your main method:

ios_base::sync_with_stdio(0);
cin.tie(NULL); cout.tie(NULL);

To speed cin up even faster, prevent it from flushing the output stream for each new line by using #define endl '\n'.

→ Reply
  • »
    »
    9 years ago, # ^ |
      Vote: I like it +10 Vote: I do not like it

    It's actually not as fast as scanf now on CF

    → Reply
    • »
      »
      »
      9 years ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      Yes, I agree. In fact it's much slower, at least on Codeforces. For 587A, I can barely pass in 500 ms with cin + cout and I tried all variations. However scanf + printf easily gets Accepted in 187 ms.

      → Reply
»
9 years ago, # |
  Vote: I like it +5 Vote: I do not like it

I don't understand the debate. Can you show me one problem in Codeforces which is not solvable with scanf and printf? Though there are often posts like this, got TLE with cin even after synced with stdio false and blah blah.... Why not always use scanf/printf, particularly when there can be as many as 10^6 numbers in the input? Why does it matter which is faster? I have yet to solve a problem where scanf/printf gets TLE but on the other hand cin/cout gets accepted.

Just use scanf/printf whenever the input is huge or you have doubts.

→ Reply
  • »
    »
    9 years ago, # ^ |
    ← Rev. 3   Vote: I like it +11 Vote: I do not like it

    Because

    1. it's more convenient to use
    2. it's as fast(and even sometimes a bit faster on real g++(as opposite to CF's version of mingw))
    → Reply
    • »
      »
      »
      9 years ago, # ^ |
        Vote: I like it 0 Vote: I do not like it

      Indeed so. You are right on both points. In codeforces however, #2 is not the case, as you mentioned. That's why I suggested if the input is huge, use scanf/printf. Otherwise use whatever you want because of course cin/cout is more simpler and convenient to use.

      → Reply