我是怎么在不知道这一对函数的情况下活到今天的,以前碰到cin TLE的时候总是傻乎乎地改成scanf,甚至还相信过C++在IO方面效率低下的鬼话,殊不知这只是C++为了兼容C而采取的保守措施。
tie
tie是将两个stream绑定的函数,空参数的话返回当前的输出流指针。
#include <iostream> #include <fstream> ///////////////////////////SubMain////////////////////////////////// int main(int argc, char *argv[]) { std::ostream *prevstr; std::ofstream ofs; ofs.open("test.txt"); std::cout << "tie example:\n"; // 直接输出到屏幕 *std::cin.tie() << "This is inserted into cout\n"; // 空参数调用返回默认的output stream,也就是cout prevstr = std::cin.tie(&ofs); // cin绑定ofs,返回原来的output stream *std::cin.tie() << "This is inserted into the file\n"; // ofs,输出到文件 std::cin.tie(prevstr); // 恢复 ofs.close(); system("pause"); return 0; } ///////////////////////////End Sub//////////////////////////////////
输出:
tie example: This is inserted into cout 请按任意键继续. . .
同时当前目录下的test.txt输出:
This is inserted into the file
sync_with_stdio
这个函数是一个“是否兼容stdio”的开关,C++为了兼容C,保证程序在使用了std::printf和std::cout的时候不发生混乱,将输出流绑到了一起。
应用
在ACM里,经常出现数据集超大造成 cin TLE的情况。这时候大部分人(包括原来我也是)认为这是cin的效率不及scanf的错,甚至还上升到C语言和C++语言的执行效率层面的无聊争论。其实像上文所说,这只是C++为了兼容而采取的保守措施。我们可以在IO之前将stdio解除绑定,这样做了之后要注意不要同时混用cout和printf之类。
在默认的情况下cin绑定的是cout,每次执行 << 操作符的时候都要调用flush,这样会增加IO负担。可以通过tie(0)(0表示NULL)来解除cin与cout的绑定,进一步加快执行效率。
如下所示:
#include <iostream> int main() { std::ios::sync_with_stdio(false); std::cin.tie(0); // IO }
reference:
http://meme.biology.tohoku.ac.jp/students/iwasaki/cxx/speed.html
貌似优化效果与编译器和环境有关,在Windows上cin/cout优化后依然比scanf/printf慢很多,但在Linux下两者速度是一致的
效率确实有很大提高,不过貌似还是赶不上scanf。我在Windows上,用mingw的G++编译器,读一个65M的包含1e7个int类型整数的文件(重定向到stdin),直接用cin要13.5秒左右;经过上面的优化,大概是8秒左右;scanf大概是3.5秒。
http://acmer.diandian.com/post/2012-04-10/18636014 这篇文章的测试结果中,scanf和优化的cin差不多,不知道是不是因为我用的是mingw的编译器的原因……
可能确实是mingw的问题,https://www.byvoid.com/blog/fast-readfile/ ,这篇文章里mingw的结果和我的类似,优化的cin耗时是scanf的2倍左右
这个跟具体编译器相关性很大,我目前也的确还是在POJ上遇到了cin慢scanf快的情况。
求一个取消同步后cout和printf混用发生冲突的情况。。。
我也是看文档上这么说,实际上没有遇到过