Что из этого следует? К счастью, ничего особенно сложного:

• если переносимость вас не интересует, если вы хотите изменить значение элемента в контейнере

и ваша реализация STL это разрешает — действуйте. Помните о том, что ключевая часть элемента (то есть часть элемента, определяющая порядок сортировки элементов в контейнере) должна сохраниться без изменений;

• если программа должна быть переносимой, элементы контейнеров

модифицироваться не могут (по крайней мере, без преобразования ).

Кстати, о преобразованиях. Вы убедились в том, что изменение вторичных данных элемента

может быть вполне оправданно, поэтому я склонен показать, как это делается — а точнее, делается правильно и переносимо. Сделать это нетрудно, но при этом приходится учитывать тонкость, о которой забывают многие программисты — преобразование должно приводить к ссылке. В качестве примера рассмотрим вызов , который, как было показано, не компилируется в некоторых реализациях:

Чтобы этот фрагмент нормально компилировался и работал, необходимо устранить константность

. Правильный способ выглядит так:

Мы берем объект, на который ссылается

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

Многие программисты пытаются воспользоваться следующим кодом:

Приведенный фрагмент эквивалентен следующему:

Оба фрагмента компилируются, но вследствие эквивалентности работают неправильно. На стадии выполнения объект

не модифицируется, поскольку в обоих случаях результатом преобразования является временный анонимный объект — копия , и вызывается для анонимного объекта, а не для ! Обе синтаксические формы эквивалентны следующему фрагменту:

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

. При вызове для объекта, обозначенного ссылкой, функция вызывается для , чего мы и добивались.

Все сказанное хорошо подходит для контейнеров set и multiset, но при переходе к map/multimap ситуация усложняется. Вспомните, что

и содержат элементы типа . Объявление означает, что первый компонент пары определяетсякак константа, а из этого следует, что любые попытки устранить его константность приводят к непредсказуемому результату. Теоретически реализация STL может записывать такие данные в область памяти, доступную только для чтения (например, в страницу виртуальной памяти, которая после исходной записи защищается вызовом системной функции), и попытки устранить их константность в лучшем случае ни к чему не приведут. Я никогда не слышал о реализациях, которые бы поступали подобным образом, но если вы стремитесь придерживаться правил, установленных в Стандарте, — никогдане пытайтесь устранять константность ключей в контейнерах и .