У меня есть итератор, который тяжелее, чем int или указатель (он предназначен для итерации по ближайшим соседям сайта в трехмерной периодической решетке, поэтому он должен содержать определенные частные структуры поддержки). Чтобы определить, находится ли итератор в конце контейнера, мне нужно только одно сравнение, но для создания итератора, указывающего на один конец, мне нужно было бы также создать конструкторские возможности.Должны ли методы begin() и end() в контейнере иметь одинаковый тип возврата?
Таким образом, я полагал, что я мог бы иметь end() mehtod контейнера возвращает int, а затем перегрузить operator==(), чтобы избежать создания полного один пришедших конечный итератора. This answer намекает, что это может быть хорошей идеей. Для двунаправленных итераторов это кажется неправильным, поскольку я позже узнал (от, например, this question), что все, что возвращается end(), должно быть декрементирующим до последнего элемента.
Поскольку мой итератор только вперед, я думал, что все будет хорошо, но теперь я считаю, что не могу использовать std::find() (и, возможно, другие алгоритмы STL), который ожидает два аргумента одного и того же (итератора) типа.
Итак, мой вопрос: имеет ли end() тип, отличный от begin(), нарушение стандартного поведения? Это такая плохая идея?
очень чистый. Я не согласен со стандартом, поэтому я могу ожидать, что его сожгут. Если есть разговоры об изменении, я думаю, что то, что я пытался сделать, было не такой плохой идеей. Будет ли изменение применяться также для пересылки итератора? Кажется, что требование об уменьшении от конца() сильно сталкивается с этой попыткой оптимизации. – TomasG
Это изменение относится ко всем категориям итераторов AFAIK. Я думаю, требование о возможности уменьшения конца() будет отброшено. – Puppy