streambuf performance 200x

Nathan Myers ncm-nospam@cantrip.org
Thu Feb 13 22:26:00 GMT 2003


On Thu, Feb 13, 2003 at 01:45:28PM -0700, Martin Sebor wrote:
> Nathan Myers wrote:
> >On Thu, Feb 13, 2003 at 11:11:13AM -0700, Martin Sebor wrote:
> >
> >>Nathan Myers wrote:
> >>
> >>>It's time to talk about fixing core streambuf performance.
> >>
> >>Note that this is complicated by the requirements on strstreambuf.
> 
> What I meant to say was that sputc() must not modify the buffer
> unless it actually is modifiable. What caught my eye was the
> statement
> 
> (this->pp != this->ep) ? (*this->pp++ = c) : this->overflow(c);
> 
> that would not guarantee that restriction unless freeze(true)
> set pp to make (pp == ep) hold and the call to overflow() was
> then made to fail, and freeze(false) restored the original
> values of the pointers. But this approach relies on overflow()
> having special knowledge of the state of the object, which
> an overflow() overridden by a program cannot have. So my
> impression is that sputc() cannot be made as simple as the
> statement above.

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.

Nathan Myers
ncm-nospam@cantrip.org



More information about the Libstdc++ mailing list