有很多很好的答案。我只是想添加一个关于解耦流的小注释。

cin.tie(NULL);

在将流与CodeChef平台分离时，我遇到了一个问题。当我提交我的代码时，平台的回答是“错误答案”，但在绑定流和测试提交之后。它工作。

因此，如果有人想要解开流，则必须刷新输出流。

使用ios_base:: sync_with_stdio(假);足以解耦C和c++流。你可以在Langer和Kreft的《Standard c++ IOStreams and Locales》中找到相关的讨论。他们指出，这是由实现定义的。

cin.tie(NULL)调用似乎要求在cin和cout上的活动之间进行解耦。我无法解释为什么在其他优化中使用这个会导致崩溃。如上所述，你提供的链接是坏的，所以这里没有猜测。

这是同步IOs从C和c++世界。如果你同步，那么你就可以保证所有IOs的顺序都是你所期望的。一般来说，问题是IOs的缓冲导致的，同步让两个世界共享相同的缓冲区。例如cout << "Hello";printf("世界");cout << "Ciao";;没有同步，你永远不知道你是否会得到HelloCiaoWorld或HelloWorldCiao或WorldHelloCiao…

tie可以保证c++世界中的IOs通道是相互绑定的，这意味着例如，每个输出都在输入发生之前被刷新(想想cout << "What's your name ?";Cin >> name;)

你总是可以混合使用C或c++ IOs，但如果你想要一些合理的行为，你必须同步这两个世界。注意，一般不建议混合使用，如果你用C语言编程使用C stdio，如果你用c++编程使用流。但是，您可能希望将现有的C库混合到c++代码中，在这种情况下，需要同步两者。

它只是一些普通的东西，让cin输入工作得更快。

简单解释一下:第一行关闭了cin流和c风格stdio工具(如scanf或gets)之间的缓冲区同步——因此cin工作得更快，但不能与stdio工具同时使用。

第二行将cin与cout分开——默认情况下，每次从cin读取内容时，cout缓冲区都会刷新。当你反复读一些小的东西，然后写很多次小的东西时，可能会很慢。因此这一行关闭了同步(通过将cin绑定到null而不是cout)。

有很多很好的答案。我只是想添加一个关于解耦流的小注释。

cin.tie(NULL);

在将流与CodeChef平台分离时，我遇到了一个问题。当我提交我的代码时，平台的回答是“错误答案”，但在绑定流和测试提交之后。它工作。

因此，如果有人想要解开流，则必须刷新输出流。

这两个调用有不同的含义，与性能无关;事实上，它加快了执行时间是(或可能是)一个副作用。您应该了解它们各自的作用，而不是盲目地将它们包含在每个程序中，因为它们看起来像是优化。

ios_base::sync_with_stdio(false);

这将禁用C和c++标准流之间的同步。默认情况下，所有标准流都是同步的，这在实践中允许您混合使用C和c++风格的I/O，并获得合理和预期的结果。如果你禁用了同步，那么c++流被允许拥有自己独立的缓冲区，这使得混合C和c++风格的I/O成为一种冒险。

还要记住，同步的c++流是线程安全的(来自不同线程的输出可能会交织，但不会产生数据竞争)。

cin.tie(NULL);

这样就把cin和cout分开了。绑定流确保在对另一个流进行每次I/O操作之前自动刷新一个流。

默认情况下，cin绑定到cout以确保合理的用户交互。例如:

std::cout << "Enter name:";
std::cin >> name;

如果cin和cout绑定，那么在程序提示用户输入之前，输出将被刷新(即在控制台上可见)。如果您解开流，程序可能会阻塞等待用户输入他们的名称，但“输入名称”消息还不可见(因为cout在默认情况下是缓冲的，输出只在需要时或缓冲区满时才会刷新/显示在控制台上)。

因此，如果将cin从cout中解绑定，则必须确保每次希望在cin上输入之前显示内容时都手动刷新cout。

总之，了解它们各自的作用，理解其后果，然后决定是否真的想要或需要提高速度可能带来的副作用。