-3
#include <iostream>
using namespace std;

int main(){
    int t;
    long long int n,res,x;
    scanf("%d",&t);
    while(t--){
            scanf("%lld",&n);
            res=0;


    for(int i=0;i<n;i++){
            scanf("%lld",&x);
            res^=x;
    }
    if(res==0)
        printf("-1\n");
    else 
        printf("%lld\n",res);

}
return 0;
}

this same program when i used cin and cout was timed out in hackerearth. But passed with scanf and printf.

Neel Alex
  • 605
  • 6
  • 10
  • 1
    Standard answer: try [`std::ios::sync_with_stdio(false);`](http://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdio) – BoBTFish Jan 18 '17 at 09:26
  • `std::cout << std::endl;` doing `flush()`. use `std::cout << '\n';` and check timing again. – Nick Jan 18 '17 at 09:27
  • 1
    ostream/istream have one thing in common with printf/scanf and that is that they are _all_ terribly slow functions with lots of overhead. You shouldn't assume that any of these are fast, nor can you easily know if the ostream implementation is faster or slower than printf for a given scenario. – Lundin Jan 18 '17 at 09:27
  • 1
    Possible duplicate of [Why is reading lines from stdin much slower in C++ than Python?](http://stackoverflow.com/questions/9371238/why-is-reading-lines-from-stdin-much-slower-in-c-than-python) – Tejendra Jan 18 '17 at 09:28
  • @Nick While I agree with avoiding [`std::endl`](http://chris-sharpe.blogspot.co.uk/2016/02/why-you-shouldnt-use-stdendl.html), `cout` is usually line-buffered anyway. Although maybe not in this case, depends how hackerearth handles the output. – BoBTFish Jan 18 '17 at 09:29
  • if i give using namespace std, then can i directly use it as cin and cout? – Neel Alex Jan 18 '17 at 09:30
  • @NeelAlex namespace std and `std::` syntax has absolutely nothing to do with performance. – Lundin Jan 18 '17 at 09:31
  • @BoBTFish `cout` is not "line buffered" - if, by that, you mean an implicit flushing on a per-line basis. – Peter Jan 18 '17 at 09:33
  • once again, `endl` is doing `flush` and ensure data is written on the "file". This is quite slow operation and can be completely avoided on screen. – Nick Jan 18 '17 at 09:37
  • @BoBTFish it was almost as fast as scanf and printf – Neel Alex Jan 18 '17 at 09:39
  • Regarding your title edit: you don't need to care about python when there is a Q/A where the main topic is optimizing C++ input handling and the results are compared to Python (which is irrelevant). You should really read the related post. – grek40 Jan 18 '17 at 10:07
  • @Peter That is what I meant. It is not *guaranteed* to be, but many common implementations are. – BoBTFish Jan 18 '17 at 10:07
  • @BoBTFish - if it's not guaranteed, it's rarely a good idea to rely on it, even if "common implementations" support it. Not unless you like code that breaks when ported to another implementation (which doesn't support it) or - and this does happen, too often in practice - a update or patch of a compiler/library removes the non-guaranteed behaviour you have relied on. Either way, you get bugs that are very difficult to track down. – Peter Jan 18 '17 at 10:26
  • @Peter We seem to be talking about entirely different things?! I was trying to explain the behaviour that was observed, not suggest best practice. – BoBTFish Jan 18 '17 at 10:35

1 Answers1

6

The speed difference is largely due to the iostream I/O functions maintaining synchronization with the C I/O functions. We can turn this off with a call to std::ios::sync_with_stdio(false);

By default standard C++ streams are synchronized to the standard C stream after each input/output operation.

Once synchronization is turned off, the C++ standard streams are allowed to buffer their I/O independently, you can try and see the time taken will be almost similar (possibly lesser than scanf)

Tejendra
  • 1,874
  • 1
  • 20
  • 32