理智检查输出streambuf计划？ [英] Sanity check output streambuf scheme?

问题描述

您好，


我之前在帖子下发帖：


如何将其分解为streambuf / ostream
< br $> b $ b我已经要求我们的图书馆获得C ++ IOStreams和Locales ...。由A.

Langer等人。同时，我已经从网上查看了C ++标准（ISO / IEC

14882），以掌握ostream

方法和streambuf方法之间的关系： flush（），operator<<（），sputc（），

sputn（），xsputn（），overflow（），sync（）和pubsync（）。


我的问题是我不想在我的

输出streambuf衍生物（mostreambuf）中使用固定大小的缓冲区，而且我不想要缓冲区

自动刷新。我希望缓冲区继续积累数据

，直到用户显式调用ostream :: flush（），可能使用

endl。这意味着mostreambuf不会使用pbase（），pptr（）或

epptr（）。相反，它将使用成员ostringstream对象oss。到

缓冲输出。这样，缓冲区可以无限增长，因为需要

，直到用户进行刷新。


在进一步说明之前，我应该指出标准确实如此不是
说同步调用是否过载，反之亦然，所以我不能假设
。


我实现上述方案的方法是基于Josuttis的C ++标准库中的示例代码，以及看到

flush（）调用pubsync（），它调用虚拟（可重载）

sync（）。首先，我设置所有3个缓冲区指针都设置为NULL，以便

sputc（c）调用overflow（），我将重载，以便c写入

到oss 。同样，xsputn（）将被重载以写入oss。我的
也会使sync（）重载，这样ostream :: flush（）就会将oss的内容发送到目的地，然后将oss变为oss。 。


这是一种合理的方法吗？


感谢您的反馈。


Fred

-

Fred Ma

卡尔顿大学电子学系

1125上校By Drive，渥太华，安大略省

加拿大，K1S 5B6

解决方案

" Fred Ma" < fm*@doe.carleton.ca>在消息中写道

news：40 *************** @ doe.carleton.ca ...

你好，
如何将其分解为streambuf / ostream

我已经要求我们的库获取C ++ IOStreams和Locales ......由A.
Langer等人。同时，我已经从网上看了C ++标准（ISO / IEC
14882），以掌握ostream
方法和streambuf方法之间的关系：flush（），operator<< （），sputc（），
sputn（），xsputn（），overflow（），sync（）和pubsync（）。

我的问题是我不想要在我的
输出streambuf衍生物（mostreambuf）中使用固定大小的缓冲区，我不希望缓冲区
自动刷新。我希望缓冲区继续积累数据，直到用户显式调用ostream :: flush（），可能使用
endl。这意味着mostreambuf将不使用pbase（），pptr（）或
epptr（）。相反，它将使用成员ostringstream对象oss。来缓冲输出。这样，缓冲区可以无限期地增长，直到用户进行冲洗。

在进一步说明之前，我应该指出标准没有说出任何关于同步调用是否过载，反之亦然，所以I


溢出

也不能推测。


你编写的代码就是这样，你决定同步调用是否溢出

，反之亦然。通常我也不会这样做。

我实现上述方案的方法是基于Josuttis在C ++标准库中的示例代码，以及看到
flush（）调用pubsync（），它调用虚拟（可重载）
sync（）。首先，我设置所有3个缓冲区指针都设置为NULL，以便
sputc（c）调用overflow（），我将重载，以便将c写入oss。同样，xsputn（）将被重载以写入oss。我也会重载sync（），以便ostream :: flush（）使oss的内容被发送到目的地，然后将oss null归为"。
<这是一个合理的方法吗？

对我来说似乎很好。


john

John Harrison写道：

在进一步说明之前，我应该指出标准没有说明是否同步调用过载，反之亦然，所以我

溢出

是的，我的坏。

也不能推测。

你编写的代码就是这样，你决定同步调用是否溢出
反之亦然。通常我都不会这样做。

Duh。是啊，你说得对。我在考虑默认的

行为，但在我的情况下并不重要。

这是一个合理的做法？

对我来说似乎很好。

感谢理智检查，John。是时候编写代码了。


Fred

Fred Ma写道：

我希望缓冲区继续积累数据，直到用户显式调用ostream :: flush（），可能使用
endl。这意味着mostreambuf将不使用pbase（），pptr（）或
epptr（）。相反，它将使用成员ostringstream对象oss。来缓冲输出。这样，缓冲区可以无限期地增长，直到用户进行刷新。

我建议使用std :: vector或者std :: deque for your buffer，

而不是ostringstream。使用ostringstream需要相当多的开销来进行简单的缓冲（包括构建流

和缓冲区对象，内部使用的std :: string以及所有开销，例如创建和销毁

岗哨对象）。


-Kevin

-

我的电子邮件地址有效，但会定期更改。

要联系我，请使用最近发布的地址。

Hello,

I posted previously under the thread:

How to break this up into streambuf/ostream

I''ve asked our library to get "C++ IOStreams and Locales..." by A.
Langer et al. Meantime, I''ve looked at the C++ standard (ISO/IEC
14882) from the web to get a grip on the relationship between ostream
methods and streambuf methods: flush(), operator<<(), sputc(),
sputn(), xsputn(), overflow(), sync(), and pubsync().

My problem is that I don''t want to use a fixed size buffer in my
output streambuf derivative (mostreambuf), and I don''t want the buffer
to flush automatically. I want the buffer to continue amassing data
until the user explicitly invokes ostream::flush(), possibly using
endl. This means mostreambuf will not use the pbase(), pptr(), or
epptr(). Instead, it will use a member ostringstream object "oss" to
buffer output. This way, the buffer can grow indefinitely as
required, until the user does a flush.

Before going further, I should point out that the standard does not
say anything about whether sync calls overload or vice-versa, so I
can''t presume either.

My approach to realizing the above scheme is based on Josuttis''s
example code in "The C++ Standard Library", as well as seeing that
flush() calls pubsync(), which calls the virtual (overloadable)
sync(). First, I set all 3 buffer pointers are set to NULL so that
sputc(c) calls overflow(), which I will overload so that c is written
to oss. Likewise, xsputn() will be overloaded to write to oss. I
will also overload sync() so that ostream::flush() causes the contents
of oss to be sent to its destination, followed by nulling oss to "".

Is this a reasonable approach?

Thanks for any feedback.

Fred
--
Fred Ma
Dept. of Electronics, Carleton University
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6

解决方案

"Fred Ma" <fm*@doe.carleton.ca> wrote in message
news:40***************@doe.carleton.ca...

Hello,

I posted previously under the thread:

How to break this up into streambuf/ostream

I''ve asked our library to get "C++ IOStreams and Locales..." by A.
Langer et al. Meantime, I''ve looked at the C++ standard (ISO/IEC
14882) from the web to get a grip on the relationship between ostream
methods and streambuf methods: flush(), operator<<(), sputc(),
sputn(), xsputn(), overflow(), sync(), and pubsync().

My problem is that I don''t want to use a fixed size buffer in my
output streambuf derivative (mostreambuf), and I don''t want the buffer
to flush automatically. I want the buffer to continue amassing data
until the user explicitly invokes ostream::flush(), possibly using
endl. This means mostreambuf will not use the pbase(), pptr(), or
epptr(). Instead, it will use a member ostringstream object "oss" to
buffer output. This way, the buffer can grow indefinitely as
required, until the user does a flush.

Before going further, I should point out that the standard does not
say anything about whether sync calls overload or vice-versa, so I
overflow
can''t presume either.
Well it the code you write that does this, you decide if sync calls overflow
or vice versa. Normally I would do neither.

My approach to realizing the above scheme is based on Josuttis''s
example code in "The C++ Standard Library", as well as seeing that
flush() calls pubsync(), which calls the virtual (overloadable)
sync(). First, I set all 3 buffer pointers are set to NULL so that
sputc(c) calls overflow(), which I will overload so that c is written
to oss. Likewise, xsputn() will be overloaded to write to oss. I
will also overload sync() so that ostream::flush() causes the contents
of oss to be sent to its destination, followed by nulling oss to "".

Is this a reasonable approach?

Seems fine to me.

john

John Harrison wrote:

Before going further, I should point out that the standard does not
say anything about whether sync calls overload or vice-versa, so I

overflow

Yes, my bad.

can''t presume either.

Well it the code you write that does this, you decide if sync calls overflow
or vice versa. Normally I would do neither.

Duh. Yeah, you''re right. I was thinking about the default
behaviour, but it doesn''t matter in my case.

Is this a reasonable approach?

Seems fine to me.

Thanks for the sanity check, John. Time to code it up.

Fred

Fred Ma wrote:

I want the buffer to continue amassing data
until the user explicitly invokes ostream::flush(), possibly using
endl. This means mostreambuf will not use the pbase(), pptr(), or
epptr(). Instead, it will use a member ostringstream object "oss" to
buffer output. This way, the buffer can grow indefinitely as
required, until the user does a flush.

I would suggest using a std::vector or maybe std::deque for your buffer,
instead of an ostringstream. Using ostringstream requires rather a lot
of overhead for simple buffering (including construction of the stream
and buffer objects, the std::string used internally, and all the
overhead involved in the actual I/O, such as creating and destroying
sentry objects).

-Kevin
--
My email address is valid, but changes periodically.
To contact me please use the address from a recent posting.

这篇关于理智检查输出streambuf计划？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！