This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]