ваш (правильный) код будет несправедливо отвергнут компилятором, если итераторы относятся к разным типам. Обходное решение остается прежним (перестановка

и ), но в этом случае приходится учитывать, что не заменяется на :

Простейшая страховка от подобных проблем заключается в том, чтобы свести к минимуму использование разнотипных итераторов, а это в свою очередь подсказывает, что вместо

следует использовать . На первый взгляд отказ от только для предотвращения потенциальных недостатков реализации (к тому же имеющих обходное решение) выглядит неоправданным, но с учетом особого статуса в некоторых функциях контейнеров мы неизбежно приходим к выводу, что итераторы менее практичны, а хлопоты с ними иногда просто не оправдывают затраченных усилий.

Как было сказано в совете 26, некоторые функции контейнеров, вызываемые с параметрами-итераторами, ограничиваются типом

; им не подходит. Что же делать, если имеется и вы хотите вставить новый элемент в позицию контейнера, обозначенную этим итератором? необходимо каким-то образом преобразовать в , и вы принять в этом активное участие, поскольку, как было показано в совете 26, автоматического преобразования в iterator не существует.

Я знаю, о чем вы думаете. «Если ничего не помогает, берем кувалду», не так ли? В мире C++ это может означать лишь одно: преобразование типа. Стыдитесь. И где вы набрались таких мыслей?

Давайте разберемся с вредным заблуждением относительно преобразования типа. Посмотрим, что происходит при преобразовании

в :

В приведенном примере используется контейнер

, но аналогичный результат будет получен и для и хэшированных контейнеров, упоминавшихся в совете 25. Возможно, строка с преобразованием будет откомпилирована vector и , но это особые случаи, которые будут рассмотрены ниже.

Почему же для этих типов контейнеров преобразование не компилируется? Потому что

и относятся к разным классам, и сходства между ними не больше, чем между и . Попытка преобразования одного типа в другой абсолютно бессмысленна, поэтому вызов будет отвергнут. Попытки использования , и преобразования в стиле C приведут к тому же результату.

Впрочем, некомпилируемое преобразование все же может откомпилироваться, если итераторы относятся к контейнеру

или . Это объясняется тем, что в реализациях данных контейнеров в качестве итераторов обычно используются указатели. В этих реализациях является определением типа для — для , — для , а — для . В реализациях данных контейнеров преобразование в вызовом компилируется и даже правильно работает, поскольку оно преобразует в . Впрочем, даже в этих реализациях и являются полноценными классами, поэтому не позволяет преобразовать в . Кроме того, как объясняется в совете 50, даже реализации, в которых итераторы контейнеров и представлены указателями, могут использовать это представление лишь при компиляции окончательной (release) версии. Все перечисленные факторы приводят к мысли, что преобразование – итераторов в итераторы не рекомендуется и для контейнеров и , поскольку переносимость такого решения будет сомнительной.

Если у вас имеется доступ к контейнеру, от которого был взят

, существует безопасный, переносимый способ получения соответствующего типа без нарушения системы типов. Ниже приведена основная часть этого решения (возможно, перед компиляцией потребуется внести небольшие изменения):

Решение выглядит настолько простым и прямолинейным, что это невольно вызывает подозрения. Чтобы получить

, указывающий на тот же элемент контейнера, что и , мы создаем новый в начале контейнера и перемещаем его вперед до тех пор, пока он не удалится на то же расстояние, что и ! Задачу упрощают шаблоны функций и , объявленные в . возвращает расстояние между двумя итераторами в одном контейнере, a перемещает итератор на заданное расстояние. Когда итераторы и относятся к одному контейнеру, выражение переводит их в одну позицию контейнера.