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 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


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