Привет всем,
кто нибудь может подсказать параграфы стандарта где описывается поведение при сравнение итераторов, в частности "конечных", от разных контейнеров?

Здравствуйте, anton_p, Вы писали:

_>Привет всем,
_>кто нибудь может подсказать параграфы стандарта где описывается поведение при сравнение итераторов, в частности "конечных", от разных контейнеров?

А зачем их сравнивать? Да и насколько я понимаю суть итераторов, они не должны вообще сравниваться, следовательно не должно быть и оператора сравнения для них.

_>>кто нибудь может подсказать параграфы стандарта где описывается поведение при сравнение итераторов, в частности "конечных", от разных контейнеров?

V>А зачем их сравнивать? Да и насколько я понимаю суть итераторов, они не должны вообще сравниваться, следовательно не должно быть и оператора сравнения для них.

тип то у них у всех одинаковый. Для итераторов из одного контейнера есть оператор сравнения. Значит и для итераторов из разных контейнеров (разных объектов, а не классов) оператор есть, но пользоваться им запрещено.

Здравствуйте, dilmah, Вы писали:


_>>>кто нибудь может подсказать параграфы стандарта где описывается поведение при сравнение итераторов, в частности "конечных", от разных контейнеров?

V>>А зачем их сравнивать? Да и насколько я понимаю суть итераторов, они не должны вообще сравниваться, следовательно не должно быть и оператора сравнения для них.

D>тип то у них у всех одинаковый. Для итераторов из одного контейнера есть оператор сравнения. Значит и для итераторов из разных контейнеров (разных объектов, а не классов) оператор есть, но пользоваться им запрещено.

А какая логика могла бы быть для такого оператора сравнения для итераторов?

Вообще не понимаю — каким волшебным образом могут быть равны два итератора для разных контейнеров, даже если контейнеры одного типа . Хотя вот здесь

Автор: Sni4ok
Дата: 06.11.10

пример, только ИМХО итераторы, это не указатели и это неправильное их применение.

Здравствуйте, anton_p, Вы писали:

_>Привет всем,
_>кто нибудь может подсказать параграфы стандарта где описывается поведение при сравнение итераторов, в частности "конечных", от разных контейнеров?
пока я склоняюсь к тому, что в стандарте 03 нет такого параграфа
в драфте нового стандарта уже что-то есть, но тоже довольно размыто

нагуглил сразу тут: http://stackoverflow.com/questions/4657513/comparing-iterators-from-different-containers
приведу копию одного из ответов

if you consider the C++0x draft:

§ 24.2.1

An iterator j is called reachable from an iterator i if and only if there is a finite sequence of applications of the expression ++i that makes i == j. If j is reachable from i, they refer to elements of the same sequence.

§ 24.2.5

The domain of == for forward iterators is that of iterators over the same underlying sequence.

Given that RandomAccessIterator must satisfy all requirements imposed by ForwardIterator, comparing iterators from different containers is undefined.

Здравствуйте, v2kochetov, Вы писали:

V>А зачем их сравнивать? Да и насколько я понимаю суть итераторов, они не должны вообще сравниваться, следовательно не должно быть и оператора сравнения для них.


С подобным способом обхода контейнера ни сталкивались?

std::list<int> intlist;
 . . . . .
std::list<int>::iterator it_begin(intlist.begin());
std::list<int>::iterator it_end(intlist.end());
std::list<int>::iterator it;
for (it = it_begin; it != it_end; ++it)
{
    . . . . .
}

Если Вам, anton_p, надо каким то образом определить что итераторы разных контейнеров указывают на один и тот же элемент, да ещё и на "элемент после последнего" — стоит задуматься, а не сбились ли Вы с пути истинного и пересмотреть способ решения задачи, м.б. прийти к общему контейнеру.
Ибо мудрите вы тут что то

Здравствуйте, _niko_, Вы писали:

__>Здравствуйте, v2kochetov, Вы писали:

V>>А зачем их сравнивать? Да и насколько я понимаю суть итераторов, они не должны вообще сравниваться, следовательно не должно быть и оператора сравнения для них.


__>С подобным способом обхода контейнера ни сталкивались?
__>

__>std::list<int> intlist;
__> . . . . .
__>std::list<int>::iterator it_begin(intlist.begin());
__>std::list<int>::iterator it_end(intlist.end());
__>std::list<int>::iterator it;
__>for (it = it_begin; it != it_end; ++it)
__>{
__>    . . . . .
__>}
__>

Мм а где тут сравнение итераторов из разных контейнеров?

__>Если Вам, anton_p, надо каким то образом определить что итераторы разных контейнеров указывают на один и тот же элемент, да ещё и на "элемент после последнего" — стоит задуматься, а не сбились ли Вы с пути истинного и пересмотреть способ решения задачи, м.б. прийти к общему контейнеру.
__>Ибо мудрите вы тут что то

Вот и я о том же.

Здравствуйте, v2kochetov, Вы писали:

V>>>А зачем их сравнивать? Да и насколько я понимаю суть итераторов, они не должны вообще сравниваться, следовательно не должно быть и оператора сравнения для них.


__>>С подобным способом обхода контейнера ни сталкивались?
__>>

__>>std::list<int> intlist;
__>> . . . . .
__>>std::list<int>::iterator it_begin(intlist.begin());
__>>std::list<int>::iterator it_end(intlist.end());
__>>std::list<int>::iterator it;
__>>for (it = it_begin; it != it_end; ++it)
__>>{
__>>    . . . . .
__>>}
__>>

V>Мм а где тут сравнение итераторов из разных контейнеров?

Цитирую Ваши слова: "Да и насколько я понимаю суть итераторов, они не должны вообще сравниваться, следовательно не должно быть и оператора сравнения для них." — подвергалась сомнению необходимость сравнения итераторов одного контейнера, ну как я понял

Здравствуйте, anton_p, Вы писали:
_>кто нибудь может подсказать параграфы стандарта где описывается поведение при сравнение итераторов, в частности "конечных", от разных контейнеров?

Для разных классов поведение "конечных" итераторов может быть разным , например:

24.5.1 Class template istream_iterator

1...
If the end of stream is reached ( operator void*() on the stream returns false), the iterator becomes equal to the end-of-stream iterator value. The constructor with no arguments istream_iterator() always constructs an end of stream input iterator object, which is the only legiti- mate iterator to be used for the end condition. The result of operator* on an end of stream is not defined. For any other iterator value a const T& is returned. The result of operator-> on an end of stream is not defined. For any other iterator value a const T* is returned. It is impossible to store things into istream iterators. The main peculiarity of the istream iterators is the fact that ++ operators are not equality preserving, that is, i == j does not guarantee at all that ++i == ++j. Every time ++ is used a new value is read.

3. Two end-of-stream iterators are always equal. An end-of-stream iterator is not equal to a non-end-of- stream iterator. Two non-end-of-stream iterators are equal when they are constructed from the same stream.

Но:

24.1.6
An iterator j is called reachable from an iterator i if and only if there is a finite sequence of applications of the expression ++i that makes i == j. If j is reachable from i, they refer to the same container.

И ещё:

24.1.5 Just as a regular pointer to an array guarantees that there is a pointer value pointing past the last element of the array, so for any iterator type there is an iterator value that points past the last element of a corresponding container. These values are called past-the-end values. ...

Здравствуйте, anton_p, Вы писали:

_>Привет всем,
_>кто нибудь может подсказать параграфы стандарта где описывается поведение при сравнение итераторов, в частности "конечных", от разных контейнеров?

Спасибо всем откликнувшимся.

Итого это — Undefined Behavior.


С++03 молчит по этому поводу,
был создан баг http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-closed.html#446
которы пофиксили в C++0x:
24.2.1 In general [iterator.requirements.general] :

6 An iterator j is called reachable from an iterator i if and only if there is a finite sequence of applications of
the expression ++i that makes i == j. If j is reachable from i, they refer to elements of the same sequence.

7 Most of the library’s algorithmic templates that operate on data structures have interfaces that use ranges.
A range is a pair of iterators that designate the beginning and end of the computation. A range [i,i) is an
empty range; in general, a range [i,j) refers to the elements in the data structure starting with the element
pointed to by i and up to but not including the element pointed to by j. Range [i,j) is valid if and only if
j is reachable from i. The result of the application of functions in the library to invalid ranges is undefined.

Итератор — это указатель (адрес) на объекты в контейнере представленный в виде односвязанного списка.
Сравнивать итераторы разных контейнеров — т.е. объектов — по моему это бред, так как разные объеты имеют различные адреса в памяти.