streambuf performance 200x
Martin Sebor
sebor@roguewave.com
Fri Feb 14 17:49:00 GMT 2003
Nathan Myers wrote:
> On Thu, Feb 13, 2003 at 04:15:30PM -0700, Martin Sebor wrote:
>
...
> 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'm not suggesting that anything new be added. If the text requires
or even recommends (if non-normative) behavior that doesn't make
sense or is unintended, the best way to reconcile it is, IMHO, to
change or remove it. Just leaving it there is misleading not only
to implementers, but to test suite writers as well. I would rather
err on the side of stricter conformance than to have to defend
our implementation after another damaging Conformance Roundup.
Please realize that not everyone has the historical insight of
knowing what may have been the intent almost a decade ago.
>
...
>
>
> 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 was referring to the descriptions, not the names. If I'm free
to ignore the Note completely, then the constant bit means nothing
and overflow() is free to write all over the buffer. In fact, since
the behavior of overflow() itself is described in D.7.1.3. p3 by
non-normative Notes, palloc becomes meaningless as well. I think
you would be shocked if the palloc argument ended up being ignored
by an implementation of strstreambuf no matter how fast it was.
>
...
>
> 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.
That would certainly make me more comfortable, but I don't think
it's enough. The rest of the section, and ideally the rest of the
standard, should be checked for similar "non-normative" notes to
make sure they don't actually describe required behavior or that
they aren't similarly misleading.
Martin
More information about the Libstdc++
mailing list