This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: streambuf performance 200x
On Thu, Feb 13, 2003 at 04:15:30PM -0700, Martin Sebor wrote:
> Nathan Myers wrote:
> >On Thu, Feb 13, 2003 at 03:36:27PM -0700, Martin Sebor wrote:
> >>Nathan Myers wrote:
> >>
> >>... 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 should have said "did it"; that is, fool with pnext. Appendix D
was supposed to reconcile existing practice, making a spec that was at
least consistent, if not "right". It's *deprecated*, in the "Backward
Compatibility appendix. Adding extra stuff that legacy code doesn't
depend on is doing too much.
> 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.
I think (almost) everybody involved at the time would be shocked and
bemused to find that anybody would add a tax on all streambufs in
order to add a new and manifestly unnecessary feature to a deprecated
library component, on the basis of a non-normatively hint, without
even asking on the list.
> >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.
You aren't required to have those names; in fact, you aren't even
allowed to, because they might hide users' global names from code
in inherited classes. The note is meant only as an aid to describing
what the normatively-specified interfaces do. If *they* don't say
it, you shouldn't do it.
I'm sorry, I'm shocked and bemused myself. I don't know what to say.
I mean no offense.
Would anyone object to a committee resolution that the non-normative
word "altered" really was meant to be non-normative, and was not
intended to require extra apparatus in basic_streambuf<>? We could
go further and remove the word, too, I suppose.
Nathan Myers
ncm-nospam@cantrip.org