Неверный вывод, сейчас скажу почему. Когда я читал стандарт для этого случая я конкретно читал для 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