cstdio流VS的iostream流？ [英] cstdio streams vs iostream streams?
问题描述
我刚学的的ios_base :: sync_with_stdio 功能，基本上可以让您关闭（或者，如果你已经把它关闭）之间的同步的存在的iostream 是用C ++使用和 cstdio 流是标准C.一部分流
I just learned of the existence of the ios_base::sync_with_stdio function, which basically allows you to turn off (or on if you already turned it off) the synchronization between iostream streams that are used in C++ and the cstdio streams that are part of Standard C.
现在，我一直以为标准输出，标准错误和标准输入用C基本上是包裹在一组++的输入输出流类C对象的。但如果他们要的同步的对方，这将表明C ++的的iostream 类的<em>不的一个包装周围C'S 标准输入等
Now, I always thought that stdout, stderr and stdin in C were essentially wrapped in a set of objects in C++ in the iostreams classes. But if they have to be synchronized with each other, this would indicate that C++'s iostream classes are not a wrapper around C's stdin etc.
我很受此困惑？有人可以澄清C ++的的iostream和C的标准输入输出是如何的不同的的事情，做同样的事情，只是在不同的抽象层次？我以为他们是在的同样的事情的！？
I'm quite confused by this? Can someone clarify how C++'s iostream and C's stdio are different things that do exactly the same thing, just at a different level of abstraction? I thought they were the same thing!?
如何是他们必须同步？我一直以为他们是同样的事情，一是包裹等，本质上
How it is that they have to be synchronized? I always thought they were the same thing, one wrapping the other, essentially.
推荐答案
C和C ++标准，使刚刚在什么特定操作的效果是事情是如何实现的没有任何要求。对于＆LT;标准输入输出＆GT; 与＆LT; iostream的＆GT; 功能，这意味着一个可以换其他的，都可以是基本相同的，或者说，它们或者是完全独立的。从技术上讲，采用通用的实现将是理想的几个原因（如就没有必要明确的同步，并会有一个已定义的机制来扩展 FILE * 为用户自定义系统），但我不知道这实际上做到这一点的任何系统。有一个实现是其他的包装可能和实施＆LT; iostream的＆GT; S IN方面＆LT;标准输入输出＆GT; 是一个典型的实现选择，虽然它有它引入了某些操作需要支付额外费用，大部分C ++标准库已经转移到使用完全独立实现的缺点。
The C and C++ standards make no requirements on how things are implemented, just on what the effect of certain operations is. For the <stdio> vs. <iostream> functionality this means that one could wrap the other, both could be essentially the same, or that they are either entirely independent. Technically, using a common implementation would be ideal for several reasons (e.g. there would be no need for explicit synchronization and there would be a defined mechanism to extend FILE* for user defined systems) but I'm not aware of any system which actually does this. Having one implementation be a wrapper of the other is possible and implementing <iostream>s in terms of <stdio> was a typical implementation choice although it has the drawback that it introduces an extra cost for certain operations and most C++ standard libraries have moved on to use entirely separate implementations.
不幸的是，这两种包装的和独立执行共享一个共同的问题：I / O是可怕低效当完成一个字符级。因此，它本质上是强制性的，以缓冲的字符和读取或写入到一个缓冲器。这很好地工作的量是相互独立的流。美中不足的是标准C流标准输入，标准输出，标准错误和C ++窄字符同行的std :: CIN ，的std :: COUT ， STD :: CERR / 的std ::堵塞和C ++宽字符对应的std :: WCIN ，的std :: wcout ，的std :: wcerr / 的std :: wclog ，分别为：当用户无论从标准输入和的std :: CIN 会发生什么？如果这些数据流的读取来自底层操作系统字符的缓冲流的读似乎失灵了。同样，如果两个标准输出和的std :: COUT 使用独立的缓冲字符将出现在意想不到的订单时，用户既写这两个流。这样一来，上有标准的C ++流对象的特殊规则（即的std :: CIN ，的std :: COUT ，的std :: CERR 和的std ::堵塞及其宽字符的对应）的任务，他们与同步它们各自的＆LT;标准输入输出＆GT; 对应。实际上，这意味着具体这些C ++对象可以直接使用通用的实现，或者他们来讲是实施＆LT;标准输入输出＆GT; 的和的别T缓冲液的任何字符。
Unfortunately, both the wrapped and the independent implementation share a common problem: I/O is hideously inefficient when done one character level. Thus, it is essentially mandatory to buffer characters and read from or write to a buffer. This works nicely for streams which are independent of each other. The catch are the standard C streams stdin, stdout, stderr and their C++ narrow character counterparts std::cin, std::cout, std::cerr/std::clog and C++ wide character counterparts std::wcin, std::wcout, std::wcerr/std::wclog, respectively: what happens when a user reads both from stdin and std::cin? If either of these stream read a buffer of characters from the underlying OS stream the reads would appear out of order. Similarly, if both stdout and std::cout used independent buffers characters would appear in unexpected order when a user writes both to both streams. As a result, there are special rules on the standard C++ stream objects (i.e. std::cin, std::cout, std::cerr, and std::clog and their wide character counterparts) which mandate that they synchronize with their respective <stdio> counterpart. Effectively, this means that specifically these C++ objects either use a common implementation directly or that they are implemented in terms of <stdio> and don't buffer any characters.
有人意识到这同步的成本相当可观，如果实现不共享一个共同的基础，可能是不必要的一些用户：如果用户只使用＆LT; iostream的＆GT; 他不愿支付额外的间接，更重要的是，他并不想支付不使用缓冲带来的额外费用。仔细的实现不使用缓冲的成本可能相当庞大，因为它意味着某些操作最终不得不做在每个迭代一个检查和可能的虚拟函数调用，而不是仅在一段时间一次。因此，的std :: sync_with_stdio（）可用于关闭此同步关闭这可能意味着标准的流对象改变其内部实现或多或少完全。由于标准的流对象的数据流缓冲器可以由用户来代替，不幸的是，该流缓冲器不能被替换，但在内部执行数据流缓存器的可以改变的。
It was realized that the cost of this synchronization is quite substantial if the implementations don't share a common base and may be unnecessary for some users: if a user only uses <iostream> he doesn't want to pay for the extra indirection and, more importantly, he doesn't want to pay for the extra costs imposed by not using a buffer. For careful implementations the cost of not using a buffer can be quite substantial because it means that certain operations end up having to do a check and possibly a virtual function call in each iteration rather than only once in a while. Thus, std::sync_with_stdio() can be used to turn this synchronization off which may mean that the standard stream objects change their internal implementation more or less entirely. Since the stream buffers of the standard stream objects can be replaced by a user, unfortunately, the stream buffers can't be replaced but the internal implementation of the stream buffer can be changed.
在＆LT的良好实现; iostream的＆GT; 库这一切不仅影响了标准流对象。也就是说，文件流应该是这完全不受影响。但是，如果你想使用标准的流对象，并希望取得良好的业绩，你显然不希望混＆LT;标准输入输出＆GT; 和＆LT ; iostream的＆GT; 并要关闭同步关闭。特别是，在比较之间的I / O性能＆LT;标准输入输出＆GT; 和＆LT; iostream的＆GT; 你应该意识到这一点
In good implementations of the <iostream> library all this only affects the standard stream objects. That is, file streams should be entirely unaffected by this. However, if you want to use the standard stream objects and want to achieve good performance you clearly don't want to mix <stdio> and <iostream> and you want to turn synchronization off. Especially, when comparing I/O performance between <stdio> and <iostream> you should be aware of this.
这篇关于cstdio流VS的iostream流？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
