标准库 'stdio' 和 'iostream' 的速度和稳定性比较。

14

当我在互联网上搜索这两个库之间的区别时,每个人都说 <iostream> 是C++的标准I/O库,而 <cstdio> 则是为C设计的。

我的教授说 cin>>cout<< 不是很好的函数,如果我们多次使用 cin>> ,我们的应用程序肯定会崩溃。他还说,stdio 提供的输入和输出速度比 iostream 快近三倍。但是,我更喜欢使用 iostream,因为它更方便,而且我也不知道我的教授是否正确。

你建议我使用什么?


12
请问需要翻译成什么语言呢? - Ignacio Vazquez-Abrams
3
如果我们多次使用cin>>,我们的应用程序肯定会崩溃。但我还没有经历过,一次都没有。 - Mark Garcia
17
你需要找到一位不同的老师,如果不可能的话,就得意识到你现在的老师无知,学会忽略他/她。 - David Heffernan
@paxdiablo 我同意你的观点 :D - Sam379
@paxdiablo 或者还没有访问 [so] 呢。;-) - Mark Garcia
4个回答

17

使用 iostream 应该不会导致程序崩溃。它可能会比较慢,但这只是因为它试图与 stdio 进行交互。那种同步可以关闭1。在大多数情况下,使用 C++ 时,我建议使用 iostream 来获取输入,而不是使用 stdio 函数。

1 使用 std::ios::sync_with_stdio(false);


@Sam379,你也可以阅读这篇文章 https://dev59.com/_mox5IYBdhLWcg3wLhei?rq=1 - log0
3
在某些情况下,使用stdio是更可取的;这种概括性的陈述并不一定有用... - Oliver Charlesworth
@OliCharlesworth,更好的是,我们可以拥有类型安全版本,减少使用C语言版本时的一些危险。 - chris
@Oli:我想确实存在这样的情况,但我一时也想不出来;你可以举个例子吗,说明在哪些情况下使用 "stdio" 可能更可取? - icktoofay
1
@icktoofay:嗯,使用printf执行格式化I/O通常(但并非总是)比玩弄流操作符更简洁和清晰。 - Oliver Charlesworth
1
@OliCharlesworth Boost.Format。此外,更清晰的术语是什么?事实上,sprintf 的规范使得使用它编写合理的代码几乎不可能(输出长度未知),这并不是很友好(即使可以使用它,语法更短,但它会崩溃)。现在,这才是真正的麻烦 - Bartek Banachewicz

9
使用流(streams)来处理C++,使用stdio.h来处理C语言。是的,流比较慢,但那些毫秒数重要吗?用户输入很少成为应用程序的瓶颈。
如果正确使用流,并且编译器/运行时库没问题,您的应用程序就不会崩溃。
但是,如果您有充分的、可解释的理由使用cstdio函数,那么在C++中也可以完全合法地使用它们。

4
不仅仅是用户输入,任何与文件的交互都包括在内... - Oliver Charlesworth
1
@OliCharlesworth:你说得完全正确,我写了“input”,因为问题主要涉及到cin - Alex Shesterov
1
这是误导性的。任何产生适中大小输出的程序,在使用cout和printf时都会看到很大的差别。 - andrepd
1
@andrepd,这取决于“适度大小”(输出)和“伟大”(差异)的定义。对于像tail这样的工具,它肯定很重要,但对于商业应用程序而言,通常并不重要。 - Alex Shesterov

3
除非 I/O 的性能真的很重要,否则使用最清晰易读的方式(最容易阅读)。
在我编写的大部分程序中,只有少数需要特殊处理“I/O 速度”的问题,而大多数与 std::stream 函数相关的问题都涉及实际解析输入(以及与 stdio 的同步)-如果你正在读取浮点数之类的内容,则编写自己版本的代码会相当困难(它接受 std::stream 允许的所有格式范围)。
如果 I/O 性能真的很重要,则使用 std::stream::read 和 std::stream::write 可能是解决方案,但在大多数情况下,最佳性能来自使用不可移植的 mmap 和 MapViewOfFile 接口,该接口直接将文件系统中的内容映射到应用程序的虚拟内存中。这样可以节省数据处理过程中所需的复制量,并使其稍微快一些。

1
iostreams 库可能比底层的 stdio 库慢。流在内部执行了更多操作 - 类型转换、本地化、异常处理等。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接