This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: streambuf performance 200x
Nathan Myers wrote:
On Thu, Feb 13, 2003 at 03:36:27PM -0700, Martin Sebor wrote:
Nathan Myers wrote:
My reading of D.7.* is that freezing the buffer does not cause
sputc calls to fail in any case. I think all the text describing
streambuf derivatives was composed carefully on the assumption
that sputc must be implementable as described above.
What about D.7.1, p2, bullet 4:
frozen, set when the program has requested that the array object
not be altered, reallocated, or freed.
^^^^^^^^^^^^^^
Despite this, though, the Classic Iostream implementation on both
HP-UX and SunOS allows frozen buffers to be altered via calls to
sputc(). Is the text in D.7.1, p2 wrong or am I missing something?
"Don't call sputc, and it won't be altered." :-) If Per had really
meant it, he might have specified that freeze should save off pnext,
set pnext to point at pend, and undo that on unfreeze. It would have
been pointless to say that, though, when nobody does it.
If by "does it" you mean that frozen prevents the array from being
altered, then both the Dinkumware and our implementation do it.
I don't know how Dinkumware accomplishes it, but we set the frozen
bit in strstreambuf::freeze() and check for it in streambuf::sputc().
That is also why I'm interested in this subject -- I'd like to be
able to eliminate that condition as much as you'd like to simplify
the function, but I don't see how I can do it.
Most likely
it's a defect, and that bit should be deleted. Anyhow it's in
non-normative text.
That, IMHO, is another defect :) The descriptions of pretty much
all strstreambuf members depend on the (non-normative) Note in
that paragraph. Without that Note, all those descriptions are
meaningless.
Martin