Hello,


While writing a DR, I found another inconsistency probably requiring a DR
too:


Various paragraphs make use of iterator arithmetic not supported by the
corresponding iterator category.

Examples of current wording (outside clause 25):

23.2.2.1/6: "Linear in first - last"
23.2.2.4/19-21: "first + 1", "(i - 1)", "(last - first)"
23.3.1.1/4: "last - first"
23.3.2.1/4: "last - first"
23.3.3.1/4: "last - first"
23.3.4.1/4: "last - first"




Iterators in clause 25 are special becaue of 25/9 (although I am pretty sure
there is another defect in this paragraph).


My questions:

1) Is there anything like 25/9 covering the other cases of invalid iterator
arithmetic expressions?
If yes, please point me to it.

2) In case not, I'd like to hear about every current paragraph and proposed
resolution in DR that suffer from the problem, so my DR will be complete.
[E-mail adress given below is valid if "ERASETHIS" is removed].


Thank you,


Thomas
a9804814ERASETHIS@unet.univie.ac.at


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

Thomas Mang wrote:
>=20
> 23.2.2.1/6: "Linear in first - last"

Beside your objection, this statement is wrong, as it should read "last=20
- first" not "first - last". This has already been reported by DR 237.

> 23.2.2.4/19-21: "first + 1", "(i - 1)", "(last - first)"

Ops! What are first and last in those clauses??? It seems that someone=20
have done a cut&paste of the unique() algorithm's description, but=20
that's inappropriate here as the context is completely different. All=20
three subclauses should be rewritten from scratch, IMHO.

(Moreover, there is also the same typo in 23.2.2.4/21 and in 25.2.8/3=20
confirming that the two sections are verbatim copies of one another.=20
Those two typos have already been reported by DR 239 and DR 315)

> Iterators in clause 25 are special becaue of 25/9 (although I am pretty=
 sure
> there is another defect in this paragraph).

I'm pretty sure that the intention is that 25/9 applies also to=20
description of algorithms in clause 23. Sure, making it more explicit in=20
the text wouldn't hurt. Maybe statement 25/9 should be moved in clause=20
24 with explicit wording that it applies to all algorithms descriptions=20
in the whole standard.

Just my =800.02

Alberto

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

"Alberto Barbati" <AlbertoBarbati@libero.it> schrieb im Newsbeitrag
news:J92td.7434$Lg7.251802@twister1.libero.it...
Thomas Mang wrote:
>
> 23.2.2.1/6: "Linear in first - last"

> Beside your objection, this statement is wrong, as it should read "last
> - first" not "first - last". This has already been reported by DR 237.



Thanks, but DR 237 suffers from the same problem.



> 23.2.2.4/19-21: "first + 1", "(i - 1)", "(last - first)"

Ops! What are first and last in those clauses??? It seems that someone
have done a cut&paste of the unique() algorithm's description, but
that's inappropriate here as the context is completely different. All
three subclauses should be rewritten from scratch, IMHO.


I know  :-).

The fun is, I started with writing a DR about std::remove / remove_if (-> my
DR 1). Then I found the wording in std::unique, which suffers from the same
problem as std::remove, plus that from not supported iterator arithmetic
which isn't covered in 25/9. (It makes use of "iterator - n", whereas 25/9
only describes "iterator + n". And reinterpreting the expression as
something like "iterator + -n" can't work, because std::advance requires the
Distance-parameter to be positive with iterators of category other than
random access / bidirectional.). So 25.2.8 will be my DR 2.

While trying to figure out a new wording for 25.2.8, I came across
std::list::unique, where "eliminate" is used again. I think this was meant
to be "erase" as in std::list::remove. Plus undefined "first", "last". Plus
unsupported iterator arithmetic. (23.2.2.4 will be DR 3). Which I found also
in various other paragraphs not covered by 25/9 (that will be my DR 4 :-))
[I'll take care about all 4 issues, as all 4 DRs are more or less written
complete. So never mind.]


(Moreover, there is also the same typo in 23.2.2.4/21 and in 25.2.8/3
confirming that the two sections are verbatim copies of one another.
Those two typos have already been reported by DR 239 and DR 315)


Both sections will be covered in my DRs suggesting new wording for
23.2.2.4/21 supposed to replace the proposed resolutions of the current DRs.



> Iterators in clause 25 are special becaue of 25/9 (although I am pretty
sure
> there is another defect in this paragraph).

I'm pretty sure that the intention is that 25/9 applies also to
description of algorithms in clause 23. Sure, making it more explicit in
the text wouldn't hurt. Maybe statement 25/9 should be moved in clause
24 with explicit wording that it applies to all algorithms descriptions
in the whole standard.


25/9 doesn't apply IMHO, because it says specifically "In the desription of
the _algorithms_", which is a pretty straight reference to only clause 25
(at least the way I read it). Plus the problem raised above about negative
distance. I am also pretty certain this paragraph was supposed to apply to
to all clauses of the Standard, not only 25. My DR will propose some
alternative resolutions to this issue, one being moving a modified version
of 25/9 (that includes "iterator - n") to the top and letting it clearly
refer to the other clauses.
I think that will be the best resolution.



If someone thinks one of the paragraphs mentioned here is not worth a DR I'd
like to hear about.

BTW, does anybody know how a post containing a DR to this group has to be
formatted so the DR is passed forward? I think I read somewhere starting the
subject as "Defect Report: blah", but I am not sure. Confirmation is
appreciated, correction if I am wrong.


Thomas


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

Thomas Mang wrote:

> BTW, does anybody know how a post containing a DR to this group has to be
> formatted so the DR is passed forward? I think I read somewhere starting the
> subject as "Defect Report: blah", but I am not sure. Confirmation is
> appreciated, correction if I am wrong.
>

It's in the FAQ: http://www.jamesd.demon.co.uk/csc/faq.html#B15

Alberto

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