Created on 1997-12-15.00:00:00 last changed 159 months ago
ITEM 1: In 184.108.40.206 [lib.string::insert], change paragraph 16 to
EFFECTS: Equivalent to insert(p - begin(), basic_string(first, last)).
ITEM 2: Not a defect; the Standard is clear.. There are ten versions of replace() in the synopsis, and ten versions in 220.127.116.11 [lib.string::replace].
ITEM 3: Change the declaration of push_back in the string synopsis (21.3, [lib.basic.string]) from:
void push_back(const charT)
Add the following text immediately after 18.104.22.168 [lib.string::append], paragraph 10.
void basic_string::push_back(charT c);
EFFECTS: Equivalent to append(static_cast<size_type>(1), c);
ITEM 4: Not a defect. The omission appears to have been deliberate.
ITEM 5: Duplicate; see issue 5 (and 87).
ITEM 6: In table 37, Replace:
"Copies correctly even where p is in [s, s+n)."
"Copies correctly even where the ranges [p, p+n) and [s, s+n) overlap."
(1) In [string.insert], the description of template <class InputIterator> insert(iterator, InputIterator, InputIterator) makes no sense. It refers to a member function that doesn't exist. It also talks about the return value of a void function.
(2) Several versions of basic_string::replace don't appear in the class synopsis.
(3) basic_string::push_back appears in the synopsis, but is never described elsewhere. In the synopsis its argument is const charT, which doesn't makes much sense; it should probably be charT, or possible const charT&.
(4) basic_string::pop_back is missing.
(5) int compare(size_type pos, size_type n1, charT* s, size_type n2 = npos) make no sense. First, it's const charT* in the synopsis and charT* in the description. Second, given what it says in RETURNS, leaving out the final argument will always result in an exception getting thrown. This is paragraphs 5 and 6 of [string.swap]
(6) In table 37, in section [char.traits.require], there's a note for X::move(s, p, n). It says "Copies correctly even where p is in [s, s+n)". This is correct as far as it goes, but it doesn't go far enough; it should also guarantee that the copy is correct even where s in in [p, p+n). These are two orthogonal guarantees, and neither one follows from the other. Both guarantees are necessary if X::move is supposed to have the same sort of semantics as memmove (which was clearly the intent), and both guarantees are necessary if X::move is actually supposed to be useful.
|2010-10-21 18:28:33||admin||set||messages: + msg18|