What is the significance of including
ios_base::sync_with_stdio(false);
cin.tie(NULL);
in C++ programs?
In my tests, it speeds up the execution time, but is there a test case I should be worried about by including this?
Do the 2 statements always have to be together, or is the first one sufficient, i.e., ignoring cin.tie(NULL)?
Also, is it permissible to use simultaneous C and C++ commands if its value has been set to false?
https://www.codechef.com/viewsolution/7316085
The above code worked fine, until I used scanf/printf in a C++ program with the value as true. In this case, it gave a segmentation fault. What could be the possible explanation for this?
This is to synchronize IOs from C and C++ world. If you synchronize, then you have a guaranty that the orders of all IOs is exactly what you expect. In general, the problem is the buffering of IOs that causes the problem, synchronizing let both worlds to share the same buffers. For example cout << "Hello"; printf("World"); cout << "Ciao";; without synchronization you'll never know if you'll get HelloCiaoWorld or HelloWorldCiao or WorldHelloCiao...
tie lets you have the guaranty that IOs channels in C++ world are tied one to each other, which means for example that every output have been flushed before inputs occurs (think about cout << "What's your name ?"; cin >> name;).
You can always mix C or C++ IOs, but if you want some reasonable behavior you must synchronize both worlds. Beware that in general it is not recommended to mix them, if you program in C use C stdio, and if you program in C++ use streams. But you may want to mix existing C libraries into C++ code, and in such a case it is needed to synchronize both.
Using ios_base::sync_with_stdio(false); is sufficient to decouple the C and C++ streams. You can find a discussion of this in Standard C++ IOStreams and Locales, by Langer and Kreft. They note that how this works is implementation-defined.
The cin.tie(NULL) call seems to be requesting a decoupling between the activities on cin and cout. I can't explain why using this with the other optimization should cause a crash. As noted, the link you supplied is bad, so no speculation here.
It's just common stuff for making cin input work faster.
For a quick explanation: the first line turns off buffer synchronization between the cin stream and C-style stdio tools (like scanf or gets) — so cin works faster, but you can't use it simultaneously with stdio tools.
The second line unties cin from cout — by default the cout buffer flushes each time when you read something from cin. And that may be slow when you repeatedly read something small then write something small many times. So the line turns off this synchronization (by literally tying cin to null instead of cout).
Lot's of great answer. I just want to add a small note about decoupling the stream.
cin.tie(NULL);
I have faced an issue while decoupling the stream with CodeChef platform. When I submitted my code, the platform response was "Wrong Answer" but after tying the stream and testing the submission. It worked.
So, If anyone wants to untie the stream, the output stream must be flushed.
Edit: I am not familiar with all the platform but this is what I have experienced.
Source: Stackoverflow.com