Для большинства контейнеров iterator
Тип обеспечивает доступ для чтения и записи к значениям в контейнере, а const_iterator
Тип обеспечивает доступ только для чтения. Однако для std::set<T>
тип итератора не может обеспечить доступ для чтения и записи, поскольку изменение значения в наборе (потенциально) нарушает инварианты контейнера. Поэтому в std::set<T>
, и то и другое iterator
а также const_iterator
обеспечить доступ только для чтения.
Это подводит меня к моему вопросу: есть ли разница между вещами, которые вы можете сделать с std::set<T>::iterator
и то, что вы можете сделать с std::set<T>::const_iterator
?
Обратите внимание, что в C ++ 11 методы манипулирования контейнерами (например, erase
) могу взять const_iterator
аргументы.
Нет, между ними не так много функциональных различий. Конечно, там используемый вернуться в C ++ 03, когда set<T>::iterator
не вернул const T&
, Но как только они изменили это, они застряли с двумя различными типами итераторов, которые оба делают то же самое.
Действительно, стандарт совершенно ясно, что они имеют одинаковую функциональность (до точки, где они Можно быть того же типа, но не обязательно). С 23.2.4, с. 6:
iterator
ассоциативного контейнера относится к категории двунаправленных итераторов. Для ассоциативных контейнеров, где тип значения совпадает с типом ключа, обаiterator
а такжеconst_iterator
постоянные итераторы. Это не определено, или нетiterator
а такжеconst_iterator
того же типа. [ Замечания:iterator
а такжеconst_iterator
имеют одинаковую семантику в этом случае, иiterator
конвертируется вconst_iterator
, Пользователи могут избежать нарушения правила единого определения, всегда используяconst_iterator
в их списках параметров функций. —конечная нота ]
Когда мы (Err I) портировали наше большое приложение на VC 10.0, это правило вступило в силу. Он сломал все виды старого кода, где люди манипулировали итераторами, вызывая для них неконстантные методы.
Так что это приводит к самому большому различию, которое я нашел: вы можете вызывать методы const только на const итераторе. Где-как в старом стандарте вы могли бы невольно вызывать неконстантные методы и портить ваш набор. В некоторых случаях я заканчивал тем, что заменял некоторые наборы на карты, где я обнаружил, что код абсолютно требовал модификации к элементам, хранящимся в контейнере.
Надеюсь, это поможет.