`basic_streambuf::setbuf` 的效果
我的问题如下： Martin York 声明 这个，这个，以及这回答了人们可以制作一个stringstream使用 basic_stringbuf::pubsetbuf 从某些内存中读取，如下所示：
char buffer[] = "123";
istringstream in;
in.rdbuf()->pubsetbuf(buffer, sizeof(buffer)); // calls basic_stringbuf::setbuf
int num;
in >> num; // reads 123
不幸的是，我深入研究了整个标准，但看不到它保证在哪里工作。我看到的是这只是实现定义的。事实上，对于微软的实现（也许其他人也是如此），这个调用没有效果。
以下是我在上一份 C++0x 草案中找到的相关引用。对于 basic_streambuf::setbuf [streambuf.virt.buffer]：
1 效果：以为本条款中从 basic_streambuf 派生的每个类单独定义的方式影响流缓冲（27.8.1.4、27.9.1.5）。
2 默认行为： 不执行任何操作。返回此。
然而，在派生类中，似乎保留了行为实现定义。对于 basic_stringbuf::setbuf 它显示 [stringbuf.virtuals]：
1 效果： 实现定义，但 setbuf(0,0) 没有效果。
对于 basic_filebuf::setbuf 它显示 [filebuf.virtuals]：
12 效果： 如果 setbuf(0,0) [...]，流将变为无缓冲。否则，结果是实现定义的。 “无缓冲”[...]
就是这样。因此，据我所知，有效的实现可以完全忽略这些调用（对于非空参数）。
我错了吗？该标准的正确解释是什么？ C++98/03/0x 是否有相同的保证？您是否有关于上述代码在哪些实现上有效以及在哪些实现上无效的更多统计信息？如何使用 basic_streambuf::setbuf ？
My problem is as follows: Martin York claims in this, this, and this answers that one can make a stringstream read from some piece of memory by using basic_stringbuf::pubsetbuf like this:
char buffer[] = "123";
istringstream in;
in.rdbuf()->pubsetbuf(buffer, sizeof(buffer)); // calls basic_stringbuf::setbuf
int num;
in >> num; // reads 123
Unfortunately I dug through the whole standard and couldn't see where it's guaranteed to work. What I see is that's just implementation-defined. In fact on Microsoft's implementation (maybe on others too) this call has no effect.
Here are related quotes I found in the last C++0x draft. For the basic_streambuf::setbuf [streambuf.virt.buffer]:
1 Effects: Influences stream buffering in a way that is defined separately for each class derived from basic_streambuf in this Clause (27.8.1.4, 27.9.1.5).
2 Default behavior: Does nothing. Returns this.
However in the derived classes it seems to leave the behavior implementation-defined. For basic_stringbuf::setbuf it says [stringbuf.virtuals]:
1 Effects: implementation-defined, except that setbuf(0,0) has no effect.
For basic_filebuf::setbuf it says [filebuf.virtuals]:
12 Effects: If setbuf(0,0) [...], the stream becomes unbuffered. Otherwise the results are implementation-defined. “Unbuffered” [...]
And that's it. So as I see it, a valid implementation can ignore these calls completely (for non-null parameters).
Am I wrong? What is the correct interpretation of the standard? Do C++98/03/0x have the same guarantees? Do you have more statistics on which implementations the above code works and on which it does not? How basic_streambuf::setbuf is intended to be used?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我相信它是实现定义的并且您提供了相关报价。
根据记录，这就是标准 C++ IOStream 和区域设置< /a>，我不得不承认，这不完全是一本新书，它在标题为“几乎语义自由的函数 -
setbuf()”的部分中谈到了这个主题：I believe it is implementation defined and that you provided the relevant quotes.
For the record, this is what Standard C++ IOStreams and locales, not exactly a recent book I have to admit, has to say on the subject in a section titled "The almost semantic free function -
setbuf()" :好的。缩回。
在花费了过去几天的时间浏览文档和已提出的提案之后，现在看来很明显这可能行不通（因为它是实现定义的）。
正如您在上面的描述中所指出的：
setbuf() 的效果实际上是通过它与 27.8.1.4 underflow() 的交互来定义的；
另外，为了从流中获取更多字符，您需要检查 27.9.1.5 showmanyc()
对于 stringstream 缓冲区来说，这意味着它不会得到任何东西，因为缓冲区已经保存了整个流。
因此，尽管它是实现定义的，但它是如何实现的。
它是如何做到的仍然有明确的定义。
OK. Retract.
After spending the last couple of days going through the documentation and the the proposals that have been made it now seems clear that this may not work (as it is implementation defined).
As you note in your description above:
The effect of setbuf() is really defined by its interaction with 27.8.1.4 underflow();
Also for getting more characters from the stream you need to check 27.9.1.5 showmanyc()
Which for the stringstream buffer means it will not get anything as the buffer already holds the whole stream.
So though it is implementation defined how it does it.
It is still well defined how it does it.