streambuf performance 200x

[Martin Sebor]

Nathan Myers wrote:
...
 > If it's non-normative, then a test suite had better not require it.
 >
 > Still, I agree, confusing or misleading non-normative text should be
 > fixed.  Andy can do that on his own initiative, although he likes to
 > have guidance from the WG.  If the change ended up changing normative
 > requirements, that would exceed his authority.

I will propose changes and incorporate your opinion.

 >
 >
 >>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.
 >
 >
 > Ask!  If the text doesn't make it clear, the text needs to be fixed.
 > We don't know what to fix if nobody speaks up about what is confusing.

You know I have been, but there doesn't seem to be much interest
in iostreams or locale among the committee members (present
company excluded). Unfortunately, many of my posts regarding
these areas elicit few if any responses (e.g., c++std-lib-10581,
c++std-lib-10502, c++std-lib-10579, c++std-lib-10615).

 >
 >
 >>>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.
 >>
 >>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.
 >
 >
 > Since the text describing allocation using palloc is normative,
 > the behavior is certainly required.

I'm sorry to get sidetracked by this, but I must respectfully
disagree. Besides the interface, the value of palloc is only
mentioned in Tables 101, 102, and 103. What it's used for is
only explained in the non-normative Note(s) in D.7.1, p3 and
D.7.1.3, p3. If, as you say below, non-normative text doesn't
present any new requirements, there is no requirement at all
on what palloc is supposed be used for. And the same is also
true for constant, and for the effects of the frozen bit on
the output sequence.

This isn't the only example. To give you another, the Note in
20.4.1.1, p3 says that allocator::allocate() uses operator new().
There is no normative requirement that allocate() do so. This
is, IMO, clearly a defect yet no one has bothered to file an
issue to have it fixed even though all implementations follow
the note as if it were a requirement.

And it doesn't end with Notes. The inconsistencies extend to
and are especially wide-spread among the Effects and Returns
clauses in iostreams where most of the public streambuf functions
are not actually required to call the protected virtuals. They're
just required to return the same values because the normative text
mistakenly uses a Returns instead of an Effects clause (see, for
instance, 27.5.2.2.2, p1, p2, p3, and p4). The importance of this
is that if the standard were actually intended to allow the
bypassing of the virtual function calls (which I'm told by Jerry
Schwarz it never was), a set of new optimization opportunities
would open up to implementations. The fact that no implementation
explores these opportunities means that every implementer just
substituted Effects for Returns w/o being shocked or bemused by
the loss of performance.

So I think it should be quite understandable, even expected, that
implementers seeking maximum conformance and especially users may
interpret even non-normative Notes as requirements.

 > The non-normative note defines
 > a shorthand, so that the normative text can say "palloc" instead of
 > "the palloc_arg value that was provided as a constructor argument,
 > or 0 if there was none".  You aren't free to entirely ignore
 > non-normative text, because it defines terms that are used to describe
 > conforming behavior.
 >
 > I think maybe you misinterpret what we mean by "non-normative".  It
 > doesn't mean that you can chop out all the non-normative text and
 > still have a complete spec.  It means, rather, that the non-normative
 > text is being declared, a priori, not to introduce any requirements.
 > If it seems to introduce an extra requirement, either there's a defect
 > (because the normative text is incomplete) or you're interpreting it
 > wrong.  Normally, if something must be said two ways, we make one
 > non-normative to avoid potential conflicts; if a conflict is discovered,
 > we've already decided which side wins, and then the editor may fix the
 > non-normative bit to more accurately echo the normative bit.
 >
 > Since defining terms used in the following text doesn't, by itself,
 > introduce any requirements, it has to be non-normative.  But that
 > doesn't mean you can pick any random definition for those terms;
 > the terms really can mean only what the text says.
 >
 >
 >>>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.
 >
 >
 > I think that process has been going on for a long time.  I think
 > we have got the "actually describe required behavior" side scrubbed
 > fairly well.  What's left is mostly editorial clarification.

I'm not so sure. In many, although some admittedly corner, cases
it's quite difficult to tell what an implementation is and isn't
allowed to get away with.

 >
 > This is really about a non-normative note that just has an extra
 > word that could be interpreted to imply more than the normative
 > text requires.  It's a purely editorial job to snip it out.

Yes. As I said, I will propose this on the reflector and if
there aren't objections I will open an issue.

Thanks
Martin