dwalker07@snet.net (Daryle Walker) wrote in message news:<1g36wij.798hrt1m0j5tmN%dwalker07@snet.net>...
> I was looking at the char* stream section D.7 of the standard and I
> found some bloopers.  Sorry if someone else has brought these up
> already.
>
> 1.  D.7.1.1 [depr.strstreambuf.cons], paragraph 8, the last line refers
> to "lib.strstreambuf.virtuals", but probably meant
> "depr.strstreambuf.virtuals".  (I guess the word processor the Standard
> guys used didn't support live reference linking.)
>
> 2.  D.7.1.2 [depr.strstreambuf.members], paragraph 1, the first
> "Effects" line doesn't have the ampersand of "strmode & dynamic" in the
> coding font.  Also the "is non-zero" following the previous fragment
> could be replaced with a "!= 0" (in the coding font).  I don't know if
> my disagreement on formatting and wording count as an error.

Those two still need fixing. I've forwarded them to the Project
Editor.

>
> 3.  D.7.1.3 [depr.strstreambuf.virtuals], paragraph 19, seems pointless!
> It has the same semantics as its base (27.5.2.4.2, para. 1 & 2), do
> nothing but wait for a child class to override it to do something
> useful.  Omitting this override entirely wouldn't change the semantics
> of strstreambuf.  (My guess about this paragraph is that no
> stream-buffer class had the setbuf method except strstream in the
> pre-Standard days.  Someone thought it was a good general idea, and
> moved it to basic_streambuf, but forgot to remove the now-redudant
> version in strstreambuf.  Also, wouldn't it have been more useful to
> make the strstreambuf version of setbuf change the internal buffer
> instead [deallocating the old buffer if needed]?)

Changing that would be substative rather editorial, so you should file
a defect report if you think this is a real defect. You have to begin
the subject with "Defect Report: " for it to get passed on to the
committee. But I should tell you that the LWG doesn't like to spend
much air time on annex D since it is deprecated stuff.

> 4.  D.7.4.1 [depr.strstream.cons], paragraph 2, the condition of the
> second bullet point is identical to the condition of the first, instead
> of countering.  Change the "==" of the second bullet point to "!=".  (A
> cut & paste error?)

That one's already fixed in the TC.

--Beman

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I was looking at the char* stream section D.7 of the standard and I
found some bloopers.  Sorry if someone else has brought these up
already.

1.  D.7.1.1 [depr.strstreambuf.cons], paragraph 8, the last line refers
to "lib.strstreambuf.virtuals", but probably meant
"depr.strstreambuf.virtuals".  (I guess the word processor the Standard
guys used didn't support live reference linking.)

2.  D.7.1.2 [depr.strstreambuf.members], paragraph 1, the first
"Effects" line doesn't have the ampersand of "strmode & dynamic" in the
coding font.  Also the "is non-zero" following the previous fragment
could be replaced with a "!= 0" (in the coding font).  I don't know if
my disagreement on formatting and wording count as an error.

3.  D.7.1.3 [depr.strstreambuf.virtuals], paragraph 19, seems pointless!
It has the same semantics as its base (27.5.2.4.2, para. 1 & 2), do
nothing but wait for a child class to override it to do something
useful.  Omitting this override entirely wouldn't change the semantics
of strstreambuf.  (My guess about this paragraph is that no
stream-buffer class had the setbuf method except strstream in the
pre-Standard days.  Someone thought it was a good general idea, and
moved it to basic_streambuf, but forgot to remove the now-redudant
version in strstreambuf.  Also, wouldn't it have been more useful to
make the strstreambuf version of setbuf change the internal buffer
instead [deallocating the old buffer if needed]?)

4.  D.7.4.1 [depr.strstream.cons], paragraph 2, the condition of the
second bullet point is identical to the condition of the first, instead
of countering.  Change the "==" of the second bullet point to "!=".  (A
cut & paste error?)

--
Daryle Walker
Mac, Internet, and Video Game Junkie
dwalker07 AT snet DOT net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]