[snip]
The standard C++ library defined iterators to serve and additional task to
serve as abstract pointers that may be singular, i.e. not corresponding to
any object and distinct from any other iterator. To this end, the standard
requires that interators may be constructed out of thin air, and that such
an iterator is singular.
Chris, if I understand correctly, you claim that default-constructed iterators are required by the standard to be singular?
W dniu 29 września 2011 11:02 użytkownik Krzysztof Żelechowski
<giecrilj@stegny.2a.pl> napisał:
Dave Abrahams wrote:
> I'd also like to point out that there's no rule saying
> default-constructed iterators must be singular.
A default-constructed iterator must be singular not because the government
says so but because of logic. You usually get wet when it rains, although
there is no rule saying that you must. Standard iterators are all singular
by default.
I disagree. I think requiring default-constructed iterstors to be singular would make plain old pointers not meet the requirements. For example:
vector<int>::iterator a; // (1)
vector<int>::iterator b = a; // (2)
Correct me if I'm wrong: line (1) is legal, and the value of a may be singular, or a may be uninitialized. Therefore line (2) is undefined behavior.
However, if we change the example a bit to make a value-initialized:
vector<int>::iterator a = vector<int>::iterator(); // (3)
vector<int>::iterator b = a; // (4)
Now for vactor<int>::iterator == int* the value of a is guaranteed to be singular: NULL, and so line (4) is ok.
But my question is, does the standard require singularity for iterators value-initialized like on line (3)? If I understand Dave's point correctly, there's no such requirement in the standard.
So Chris, in my opinion you may have a point there, that it could make sense to:
1) add a requirement, that value-initialized default-constructed iterators be singular;
2) allow using such singular-value iterators to compare, but not dereference -- just like vector<int>::end() may be used.
- Note, that I'm *not* suggesting to make vector<int>::end() to return a value equal to vector<int>::iterator().
Regards,
Kris