streambuf, yet again

[Christopher Benson-Manica]

Is there any way to prevent the streambuf from calling overflow or
xsputn unless I specifically flush the stream?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[John Harrison]

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:c1**********@chessie.cirr.com...

Is there any way to prevent the streambuf from calling overflow or
xsputn unless I specifically flush the stream?

Its ostream that calls overflow or xsputn.

I can't think of any reasonable way to achieve that, but I could easily be
wrong. But I am sure it would be better to code this so that you don't much
care when overflow or xsputn is called. Why exactly does it matter?

Is your stream working now then? What was the problem? Before you were
complaining that overflow wasn't being called at all, not you are
complaining that its being called to often!

john

[Christopher Benson-Manica]

John Harrison <jo*************@hotmail.com> spoke thus:

I can't think of any reasonable way to achieve that, but I could easily be
wrong. But I am sure it would be better to code this so that you don't much
care when overflow or xsputn is called. Why exactly does it matter?
Well, this is a deficiency of the class I'm trying to wrap -
TLSFile::Write() appends a '\n' to its argument before actually
writing to the file. So I have to code around it, convince my boss to
change that behavior (he seemed reluctant this morning), or just
forget wrapping the class with a stream at all.
Is your stream working now then? What was the problem? Before you were
complaining that overflow wasn't being called at all, not you are
complaining that its being called to often!

Well, it kind of is. It turns out that the first time through the
section of code in question, nothing happens. On subsequent trips
through that section of code, however, things work as expected
(although not as I would want - see above). Does that sound like a
specific kind of mistake to you?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[John Harrison]

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:c1**********@chessie.cirr.com...

John Harrison <jo*************@hotmail.com> spoke thus:

I can't think of any reasonable way to achieve that, but I could easily be wrong. But I am sure it would be better to code this so that you don't much care when overflow or xsputn is called. Why exactly does it matter?
Well, this is a deficiency of the class I'm trying to wrap -
TLSFile::Write() appends a '\n' to its argument before actually
writing to the file. So I have to code around it, convince my boss to
change that behavior (he seemed reluctant this morning), or just
forget wrapping the class with a stream at all.

Hmm awkward. And some people claim that object orientation promotes reusable
code. I'd work on your boss if I were you.

What you can do is create a real buffer (instead of using the unbuffered
mode you are using now). See Josuttis for details. Then when the buffer is
full and overflow is called you scan the characters in the buffer for
newlines. If you find any you can call TLSFile::Write with the characters
before the newline and just drop the newline. You won't be able to empty the
buffer entirely, just the portion that is before the last newline, but that
isn't a problem. If when overflow is called and the buffer is full and there
isn't a single newline in it, then you are either going to have to output a
spurious newline, or you are going to have to expand the buffer.

Is your stream working now then? What was the problem? Before you were
complaining that overflow wasn't being called at all, not you are
complaining that its being called to often!

Well, it kind of is. It turns out that the first time through the
section of code in question, nothing happens. On subsequent trips
through that section of code, however, things work as expected
(although not as I would want - see above). Does that sound like a
specific kind of mistake to you?

Sorry, it doesn't.

john

[Dietmar Kuehl]

Hi,
John Harrison wrote:

"Christopher Benson-Manica" <at***@nospam.cyberspace.org> wrote in message
news:c1**********@chessie.cirr.com...

Is there any way to prevent the streambuf from calling overflow or
xsputn unless I specifically flush the stream?

No. 'overflow()' is called when the stream buffer's buffer is full and
character is supposed to be dumped. Where should this one go? There are
several strategies how to deal with this though. The strategy used eg.
by the file streams is to dump the buffer to the file. Another strategy
is to increase the buffer's size and put the character there. ... or to
use a buffer which is not made accessible to 'std::streambuf' and which
is flushed in some form if a certain condition occures, eg. when a
newline is inserted.

'xsputn()' is quite similar but it is actually not really necessary to
override this function: the default behavior of 'xsputn()' is to process
the characters individually such that it is sufficient to override
'overflow()'. In this case the function is called with each character.
The function 'xsputn()' is mainly an optimization for cases where
processing sequences of characters can be done more efficiently.
Its ostream that calls overflow or xsputn.

No. Both 'overflow()' and 'xsputn()' are protected. They are called by
stream buffer functions. The former when the internal buffer is full
and the latter when 'sputn()' is called. Well, the latter is pretty
direct.
--
<mailto:di***********@yahoo.com> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>