### kunaljain's blog

By kunaljain, 12 years ago,
I tried to solve Beta Round #1 - Problem A

I tried the I/O using scanf and printf. Using "%lld". But it gave a wrong answer the first test case.

While running the same code with I/O using cin and cout. It got Accepted. I could not make out what is wrong with scanning the input using scanf and printf.
I haven't seen anything such thing occur on any other judge.

Can somebody throw a light on what actually is the problem ?

• 0

 12 years ago, # |   0 In Wiindows version of g++(MinGW) you should use %I64d not %lld for reading and writing long longs.
 » 10 years ago, # |   0 Maybe cin and cout are better.
•  » » 10 years ago, # ^ | ← Rev. 2 →   +7 But sometimes they are so sloooooow. std::sync_with_stdio(0); treats it.
•  » » » 10 years ago, # ^ |   0 Actually, using the above trick makes cin faster than scanf, and cout is faster than printf unless you use endl, the reason is that endl flushes the output buffer. Use cout << something << '\n' instead.
•  » » » » 10 years ago, # ^ |   0 But sometimes ~~~~~ cout << '\n' ~~~~~gets WA,and maybe ~~~~~ puts("") ~~~~~ is a good way to write in a new line.
•  » » » » 10 years ago, # ^ |   +3 In theory — yes, because the cin/cout operators know the target type at compile time. But in practice your mileage may vary and depends on the compiler and the standard library. A few years ago I conducted extensive testing on this matter and found that sometimes iostreams was faster and sometimes it was not. But the difference was not so great, so, in my opinion, one is safe to use iostreams (with sync_with_stdio(false)).
 » 8 years ago, # |   0 This happens in some questions of spoj also.
 » 3 years ago, # |   -14 But it takes %l64d as string constant in printf