Код, указанный ниже, отлично работает и меняет по итератору значение ключа в set. 
Но в книжке (Язык программирования С++. Вводный курс / С++ Primer, Fourth Edition) написано, что ключи в set константны и соответственно не поддаются изменению.
Может у меня компилятор свихнулся? 

Цитата из книжки:
"Подобно тому, как в элементе карты нельзя изменить ключ, ключи набора (set) также константны. Если существует итератор на элемент набора, то все, что с ним можно сделать, - это прочитать ключ, а запись при помощи итератора невозможна.

То же самое в англ.версии книжки:
"Just as we cannot change the key part of a map element, the keys in a set are also const. 
If we have an iterator to an element of the set, all we can do is read it; we cannot write through it"

zim22, ну я как-то не вижу в приведенном тобой примере, чтобы ты ключи менял.
Судя по всему, ты спутал понятия ключ-значение(значение неконстантным итератором изменить естественно можно, на то он и неконстантный)

pan2004, в моём коде были ещё комментарии, но я их удалил, в них указано, что мы оперируем именно ключами, а не значениями:

Т.е. мы всё-таки оперирум с ключами, а не со значениями. Т.к. контейнер set в MSDN описывается как содержащий только ключи, а не значения:

"An STL set is: 
An associative container, which a variable size container that supports the efficient retrieval of element values based on an associated key value. Further, it is a simple associative container because its element values are its key values."

т.е. в стандарте написано, что std::set::iterator ведет себя так же, как std::set::const_iterator, но не определено, должен ли первый являться вторым или нет. Более того, думаю, что не должен, так как константный итератор нельзя использоваться в std::set::erase, в то время как обычный можно.

Жизнь такого не говорит!!! Это Visual Studio упорно так твердит потому что по инерции продолжает не соответствовать стандарту. На GCC попробуй, результат совершенно другой.

bsa

Да, вести себя они должны одинаково, но если для map или set изменить ключ он должен перестроить все дерево (я честно не пробовал, но сомневаюсь что студио это делает). Я сталкивался с тем же самым..сам был удивлен, как такое возможно, почитал стандарт, попробовал на GCC - все встало на свои места 


В 2008 студии уже исправили


Это сообщение отредактировал(а) azesmcar - 3.3.2009, 07:54

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


т.е в стандарте по этому поводу ничего ясного нет. Студия поступает вполне корректно.

Добавлено через 2 минуты и 34 секунды
zim22, посмотри книгу Саттера, "Решение сложны задач на С++". Задача 1.15

vinter, красивая функция, но какое отношение имеет твоя функция find к тому что я написал?



Стандарт неохота открывать, да и не нужно читать стандарт чтобы узнать что менять ключь сета нельзя. А то что студия не соответствует стандарту давно известный факт, насчет 2008 не ручаюсь, но ранние версии точно. Полно проблем с шаблонами и STL.

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

ты отвечал на вопрос zim22, у которого в коде используется set и find.


можно его менять. Читай стандарт, это не запрещается. А что не запрещено, то разрешено.


обычно в таких случаях приводят аргументы, иначе твои слова остаются пустословием.


отлично, а map nne причем? Еще раз название темы перечитай.

но вопрос был не про find а про изменение ключа. Он и std::string использовал в своем примере, что нам теперь про std::string разговаривать?



я уже привел цитату из стандарта и из журнала C++ Report. Этого мало?



Если тебе нужны аргументы - это отдельная тема которая не подлежит обсуждению в этом топике, скажу только что в шестой студии не работала частичная специализация а конструктор std::exception у них до сих пор принимает параметр std::string, хотя в стандарте описан иной интерфейс класса std::exception - в результате до фига непереносимого кода, потому что люди пишут throw std::exception("error").
В приоритетах выборки первичного шаблона были некоторые проблемы и (уже не помню) какой студии.
Если хочешь открой отдельную тему пообсуждаем.



а map притом что без разницы. Просто для удобства привел пример на map, чтобы показать что ключь нельзя менять а значение можно.

Добавлено через 2 минуты и 25 секунд
ассоциативные контейнеры работают по одному принципу - построение дерева, если изменить значение - дерево станет недееспособным, потому без разницы.

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

Так...нашел.
Значит я правильно помнил, в 2008 тоже работало..



получаем в результате

1 2 1 4

насколько соответствует СТАНДАРТУ то что в ассоциативном контейнере set может быть два одинаковых ключа - думайте сами. Или мне привезти цитату из стандарта что set долже иметь уникальные ключи?

всё верно. про изменение ключа в set, но не в map. Т.к. в map ключи константны. но на момент написания кода я не знал, как получить доступ к ключу. поэтому и использовал функцию find. это не принципиально важно. можно использовать вместо find итератор на начало:


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


есть разница в том, что Саттер  пишет, что для map 100% определено, что ключи описаны как константные, а для случая set не всё так однозначно.

я знаю что пишет Саттер, и видел что в стандарте ключь сета не описан как константный. Но это еще ничего не значит, стандарт тоже не идеален, потому существуют книги, журналы и тому подобное, в статье C++ report явно написано что ключь должен быть константным для любого ассоциативного контейнера. И Саттер тоже не мало запрещал делать то что позволяет стандарт. А почему студия не соответствует стандарту, смотрите пример.

Добавлено через 2 минуты и 20 секунд


где это такое говорится?



по моему ясно написано.

Возможно я не правильно перевёл 
Как только ключ был вставлен в контейнер, его лучше не изменять такими способами, которые меняли бы его относительную позицию в контейнере.

Из этого я делаю вывод, что если при изменении ключа его относительная позиция не изменится - то изменять его можно.

Добавлено через 5 минут и 7 секунд

В этом примере Вы умышленно изменили относительную позицию элемента в контейнере. 
Тем самым Вы сами берёте ответственность за порчу его структуры. Хотя и MSVC 2008 позволяет это делать 


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


Это сообщение отредактировал(а) zim22 - 3.3.2009, 10:01

Неверный вывод, сейчас скажу почему. Когда я читал стандарт для этого случая я конкретно читал для map. Для map в стандарте ясно написано - ключь константный, для set там этого не написано, я согласен, но это еще ничего не значит. Возможно в стандарте есть упущения, не нам об этом судить, но логично было бы предположить что если запрещено для map, должно быть запрещено и для set.
Студия не соответствует стандарту не потому что она разрешила присвоение, а потому что как видите последствия этого присвоения ненормальны для ассоциативного контейнера. Даже если в стандарте это упистили, работаспособность подобного кода приводит к несоответствующему стандарту поведению контейнера. Т.е. несоответствию стандарта.

Если что-то явно не разрешено - это можно запретить. С такой логикой разработчики GCC создали свой компилятор. Этот код не скомпилируется в GCC. А значит код непереносимый.

Думаю все

Добавлено через 6 минут и 31 секунду


а зачем так извращаться если можно просто удалить и создать заного как советуют специалисты?

так и буду делать. спасибо за разъяснения.

но это то, что необходимо соблюдать,а  не домысливать.


не написано там такого, там написано, что лучше бы он был константен. Улавливаешь разницу между должен и желательно?

вполне соответсвует. По стандарту операторы вставки не вставят повторного элемента, другое стандартом не запрещается.

ты читать умеешь? прочитай еще раз мой пост и bsa, там написано, что стандарт не устанавливает ограничений, а значит студия имеет полного право так поступать. Да, ты там писал про VS 6.0, так будет тебе известнео, что он вышел до приянтия стандарта в 98 году и соответсвовать ему не обязан. Да и вообще приводить в пример компилятор которому 11 лет, по меньшей мере, некорректно.

да, это верный вывод.
вот тебе пример:

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

  

дык, это не его вывод. это мой вывод   

Это сообщение отредактировал(а) zim22 - 3.3.2009, 14:19

zim22, я знаю, просто цитату снимал с его поста

повторяюсь


слово requirement тебе о чем то говорит? 


где тут слово "лучше бы"?


никто не домысливал..и в Саттере которого ты цитировал - черным по белому написано


там же он называет метод с const_cast - базукой

и там же называет это правило - The Associative Container "Key Rule"
http://www.google.mu/search?hl=en&q=Th...G=Google+Search

если для тебя непереносимый код - нормально..тогда дальше обсуждать нечего.тема закрыта

Добавлено через 34 секунды
http://books.google.mu/books?id=_1uD7khOQo...result#PPA58,M1

вот еще ссылка на More Exceptional C++ Саттера, она как раз открыта на нужный странице.

Добавлено через 5 минут и 47 секунд


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

azesmcar, мне надоел твой троллизм, ответы на все твои вопросы даны в этой теме. Все подтверждено циаттами из стандарта, вчитывайся до полного просветеления. Играть с тобой в слова нет ни желания, ни времени.

...that key had better not be changed...

говорит. но ведь дальше по тексту объясняется, что подразумевается под этим requirement.
An essential requirement is this: Once a key has been inserted into the container, that key had better not be changed in any way that would change its relative position in the container
Т.е. если relative position не меняется при изменении ключа - не меняется и логическая целостность контейнера.

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


это ничего не меняет. Слово "лучше" не всегда значит что у тебя есть резонная альтернатива. Во всяком случае в данном контексте.
Если в стандарте что-то явно не сказано - это значит что каждый волен поступить как хочет. Так же как и с примером того же Саттера про очередность подстановки параметров функции это не стандартное решение и может быть непереносимым. Конкретный пример где этот код непереносим - я привел.

цитата из стандарта


если в set можно запихнуть два ключа с тем же значением не нарушая инкапсуляции - это по мне нарушение стандарта. 

vinter - насчет студии - почитай внимательно еще раз..я не только про шестую говорил но и про 2005-ую. И примеры привел. И про 2003 слышал, но сам не пробовал.

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

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

я же сказал


или ты ассемблерными вставками можешь не нарушить инкапсуляцию? Я имел ввиду использованим интерфейса класса. А ты про вставки говоришь и изменение бинарного кода. По моему в сравнение не идет

Добавлено @ 17:35
GoldFinch, я даже не знаю уже какой пример привести, ты в самом деле считаешь что твой пример имеет какое-то отношение к моему сказанному? Речь о том что интерфейс класса позволяет ЗАКОННЫМИ методами привести класс в состояние несоответствующее СТАНДАРТУ.

Можно сколько угодно спорить об этом, но однозначного ответа на этот вопрос я не вижу, по мне так однозначного ответа тут нет. Я сказал - ПО МОЕМУ это нарушение стандарта. Если есть инкапсуляция, она для того чтобы скрыть внутренние данные и не позволить их изменять (речь не идет о надуманных методах которыми можно обойти инкапсуляцию). А этот класс позволяет привезти себя в состояние не соответствующее стандарту своими же методами. 

Это сообщение отредактировал(а) azesmcar - 3.3.2009, 17:36

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

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

mes +1