On 01/11/2012 05:03 PM, Сыроежка wrote: > койтесь, как я уже сказал, мир реальных задач значительно богаче вашей фантазии, > что вам даже и не снилось, какие задачи могут встретиться на практике. Я вам уже > сказал, что ваш аргумент не состоятелен, так как согласно ему, вообще непонятно, > зачем существует этот алгоритм, например, для векторов?
Для векторов как раз всё понятно, зачем этот алгоритм существует. И для списков.
Потому что там есть ПОРЯДОК, ЗАДАННЫЙ ПОЛЬЗОВАТЕЛЕМ контейнера.
И именно он реверсируется алгоритмом.
А в мапе НЕТ порядка, заданного пользователем. А то, что что-то там итерируется
и может хранится в каком-то порядке -- не более чем побочный эффект реализации.
Posted via RSDN NNTP Server 2.1 beta
Re[9]: Разместить в обратном порядке отображаемые значения s
> А на самом деле тут исходная позиция не в том, чтобы тащить все функции, которые > возникают на практике, в иинтерфейс, а в том, что прерывается логическая > последовательность использования стандартного алгоритма revrese. То есть он
Тут исходная позиция в том, что ты подразумеваешь какую-то общность всех
контейнеров, которой на самом деле НЕТ. Есть только её видимость, кажущаяся.
Posted via RSDN NNTP Server 2.1 beta
Re[8]: Разместить в обратном порядке отображаемые значения s
Здравствуйте, MasterZiv, Вы писали:
MZ>On 01/11/2012 05:03 PM, Сыроежка wrote: >> койтесь, как я уже сказал, мир реальных задач значительно богаче вашей фантазии, >> что вам даже и не снилось, какие задачи могут встретиться на практике. Я вам уже >> сказал, что ваш аргумент не состоятелен, так как согласно ему, вообще непонятно, >> зачем существует этот алгоритм, например, для векторов?
MZ>Для векторов как раз всё понятно, зачем этот алгоритм существует. И для списков. MZ>Потому что там есть ПОРЯДОК, ЗАДАННЫЙ ПОЛЬЗОВАТЕЛЕМ контейнера. MZ>И именно он реверсируется алгоритмом.
MZ>А в мапе НЕТ порядка, заданного пользователем. А то, что что-то там итерируется MZ>и может хранится в каком-то порядке -- не более чем побочный эффект реализации.
Я бы не сказал, что в векторе есть порядок, который реверсируется. Реверсируются только значения, хранящиеся в элементах контейнера, а сам порядок остается прежним. Я уже подвел некоторый итог э той теме по адресу http://clipper.borda.ru/?1-6-0-00000022-000-0-0-1326309482
Там я более подробно изложил вопрос. Я не вижу никаких коонтраргументов, препятствующих ввнедрению данного алгоритма для std::map.
Я не считаю это недочетом, но если вы считаете, то можете открыть тему по этому вопросу. С моей точки зрения std::map дополняет понятие вектора, когда к элементам можно обращаться не только по одному виду ключа — беззнаковому целочисленному, но и по произвольному ключу.
>> А на самом деле тут исходная позиция не в том, чтобы тащить все функции, которые >> возникают на практике, в иинтерфейс, а в том, что прерывается логическая >> последовательность использования стандартного алгоритма revrese. То есть он
MZ>Тут исходная позиция в том, что ты подразумеваешь какую-то общность всех MZ>контейнеров, которой на самом деле НЕТ. Есть только её видимость, кажущаяся.
С этим я кардинально не согласен. Есть общность интерфейсов. Именно к этой цели стреились разработчики стандарта. В противном случае нельзя бы было использовать стандартные алгоритмы.
Другое дело, что для вашей точки зрения есть основа, заключающаяся в том, что право на существование конкретного контейнера дает его отличие от других контейнеров. Иначе не стоило бы городить огород и создавать новый шаблонный класс. Но тем не менее это не противоречит общности элементов контейнеров. Эту общность можно уследить, например, на адаптерах контейнеров, как, например, std:;stack,которые в свою основу могут выбрать произвольный контейнер.
> Я не считаю это недочетом, но если вы считаете, то можете открыть тему по этому > вопросу. С моей точки зрения *std::map* дополняет понятие вектора, когда к > элементам можно обращаться не только по одному виду ключа — беззнаковому > целочисленному, но и по произвольному ключу.
Я не знаю, что там с твоей точки зрения, но с точки зрения стандарта в
std::vector пользователь хранит данные в СВОЁМ порядке, в том, какой он
хочет иметь, а в std::map -- в навязанном ему реализацией этого контейнера.
А так -- да, они ПОЛНОСТЬЮ друг друга дополняют. Например, как ворон и
писменный стол. У одного две ноги, у другого (обычно) -- четыре.
Ты прослеживаешь аналогию? Представляешь, У НИХ ОБОИХ ЕСТЬ НОГИ !!
Так что это почти одно и то же !
Вообще, я сходу знаю 4 возможные реализации ассоциативных массивов,
почему STL решили прибить гвоздями к забору под названием "стандарт"
свойства ровно одной из них -- я не понимаю. И считаю это недочётом.
И я не буду открывать тему по этому вопросу. Потому что мне лично на это
наплевать. Есть библиотека, есть везде, извесно, как работает, -- всё.
Более меня не интересует ничего. STL вообще плохая библиотека, её проблемы
меня не интересуют, их там дофига.
Posted via RSDN NNTP Server 2.1 beta
Re[12]: Разместить в обратном порядке отображаемые значения
>> Я не считаю это недочетом, но если вы считаете, то можете открыть тему по этому >> вопросу. С моей точки зрения *std::map* дополняет понятие вектора, когда к >> элементам можно обращаться не только по одному виду ключа — беззнаковому >> целочисленному, но и по произвольному ключу.
MZ>Я не знаю, что там с твоей точки зрения, но с точки зрения стандарта в MZ>std::vector пользователь хранит данные в СВОЁМ порядке, в том, какой он MZ>хочет иметь, а в std::map -- в навязанном ему реализацией этого контейнера. MZ>А так -- да, они ПОЛНОСТЬЮ друг друга дополняют. Например, как ворон и MZ>писменный стол. У одного две ноги, у другого (обычно) -- четыре. MZ>Ты прослеживаешь аналогию? Представляешь, У НИХ ОБОИХ ЕСТЬ НОГИ !! MZ>Так что это почти одно и то же !
MZ>Вообще, я сходу знаю 4 возможные реализации ассоциативных массивов, MZ>почему STL решили прибить гвоздями к забору под названием "стандарт" MZ>свойства ровно одной из них -- я не понимаю. И считаю это недочётом. MZ>И я не буду открывать тему по этому вопросу. Потому что мне лично на это MZ>наплевать. Есть библиотека, есть везде, извесно, как работает, -- всё. MZ>Более меня не интересует ничего. STL вообще плохая библиотека, её проблемы MZ>меня не интересуют, их там дофига.
На мой взгляд и векторе и в отображении пользователь сам выбирает тот порядок, в котором он хочет расположить элементы. Отображение просто пердоставляет пользователю дополнительные возможности по установлению порядка. Ведь как определяется порядок в этих контейнерах? Он определяется прямым доступом к элементам. В веторе этот доступ осуществляется с помощью беззнакового целочисленного ключа, например, c[0[ = 'A'; c[1] = 'B';. То же самое можно сделать и в отображении, если его определить как std::map<unsigned int, char> c;. И работать с ним таким же образом, как и с вектором, c[0[ = 'A'; c[1] = 'B';. С точки зрения интерфейса разницы нет. Но отображение позволяет вводить ключи других типов. Но это всегда тот порядок, который устанавливает сам пользователь.
Здравствуйте, jazzer, Вы писали:
С>>Не просветите меня, с каких это пор список не поддерживает свою организацию хранения данных?! Как раз каждый контейнерсуществует самостоятельно именно из-за того, что поддерживает собственную организацию хранения данных. J>Перечитай мое сообщение еще раз, там речь шла о поддержании отсортирвоанности, а не об организации хранения.
Камрад, ну тут же типичнейший тролль!
Ему уже десять раз разжевали, а он всё кушать хочет.
С>>Что касается всего остального, то это говорит, что вы не в состоянии мыслить концептуально. Вы относитеьс к тем людям, которые не в состоянии обощать, а постоянно решаете частные вопросы. Для программиста — это серьезный недостаток. Я вам советую исправлять его! J>Вы относитесь к людям, которые не в состоянии прочитать внимательно то, что написано. Для программиста — это серьезный недостаток.
Зато для тролля похоже самое оно.
J>А если серьезно, в чем смысл всей этой эскапады? Реклама ресурса клиппер-борда-ру? Или что?
Этож очевидно: ЕДА!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: Разместить в обратном порядке отображаемые значения s
Здравствуйте, Сыроежка, Вы писали:
С>Спасибо за развлечение. но когда у меня будет желание посмотреть на кривляние обезьянки, я лучше схожу в зоопарк!
Полагаю такими темпами тебе выпишут абонемент в баню.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[13]: Разместить в обратном порядке отображаемые значения
Здравствуйте, Сыроежка, Вы писали:
С>А ключ и значение как раз и являются независимыми.
Привожу еще раз цитату из wikipediaна этот раз в более развернутом виде.
Внимание, читать медленно, вдумчиво, и если что-то не понятно, начать читать заново!
Ассоциативный массив (словарь) — абстрактный тип данных (интерфейс к хранилищу данных), позволяющий хранить пары вида «(ключ, значение)» и поддерживающий операции добавления пары, а также поиска и удаления пары по ключу
Т.е. std::map хранит в себе пары и позволяет находить и удалять среди них те, которые удовлетворяют условию равенства ключа внутри опять таки этих пар. Постарайтесь представить, что пара это единое целое, внутри которого содержится два поля: ключ и значение.
И далее пишут следующее:
Ассоциативный массив с точки зрения интерфейса удобно рассматривать как обычный массив, в котором в качестве индексов можно использовать не только целые числа, но и значения других типов — например, строки.
Т.е. для удобства его представляют как бы массив, но любой вменяемый с++ программист знает, что это не совсем так.
Так, во всех книжках обращают внимание, что за красивым и удобным интерфейсом вот такого использования:
m[key0] = value0;
скрывается следующая последовательность действий:
if( m.count(key0) )
{
m[key0] = value0;
}else{
m.insert( make_pair(key0, default_value) ); // т.е. для тяжелых типов не есть хорошо!
m[key0] = value0;
}
Но Вы конечно же это не читали, т.к. в это время уже бежали писать статью про std::map на Вашем любимом форуме.
С>Но в любом случае спасибо вам за участие. Я уже всю дискуссию подытожил в своем сообщении по адресу http://clipper.borda.ru/?1-6-0-00000022-000-0-0-1326309482 С>Почитайте, будет вам интересно. Я не думаю, что что-то принципиально новое вы сможете мне возразить. То есть я не вижу никаких серьезных контраргументов моей постановке вопроса.
Ничего интересного Вы там не пишите. Мне искренне жаль тех, кто решит познать с++ по Вашим статьям.
Кстати, "A map satisfies all of the requirements of a container, of a reversible container" означает, что у std::map имеется reverse_iterator, const_reverse_iterator, rbegin(), rend(). И совсем не обязан иметь средство реверсивного расположения значений элементов! Вы бы хотя бы стандарт открыли что-ли!? И вообще курите поменьше ту дрянь, что дает Вам возможность думать настолько обобщенно и концептуально..
P.S. Когда в следующий раз захотите выпендриться на своем форуме за счет Саттера, хотя бы прочитайте ВНИМАТЕЛЬНО то, что он пишет, например комменты к коду. Если не поняли с первого раза, читайте пока не дойдет, а уже потом пишите статьи, про то, какой Вы умный!
Re[14]: Разместить в обратном порядке отображаемые значения
Здравствуйте, rumit7, Вы писали:
R>Здравствуйте, Сыроежка, Вы писали:
С>>А ключ и значение как раз и являются независимыми.
R>Привожу еще раз цитату из wikipediaна этот раз в более развернутом виде. R>Внимание, читать медленно, вдумчиво, и если что-то не понятно, начать читать заново!
R>
R>Ассоциативный массив (словарь) — абстрактный тип данных (интерфейс к хранилищу данных), позволяющий хранить пары вида «(ключ, значение)» и поддерживающий операции добавления пары, а также поиска и удаления пары по ключу
R>Т.е. std::map хранит в себе пары и позволяет находить и удалять среди них те, которые удовлетворяют условию равенства ключа внутри опять таки этих пар. Постарайтесь представить, что пара это единое целое, внутри которого содержится два поля: ключ и значение. R>И далее пишут следующее:
R>
R>Ассоциативный массив с точки зрения интерфейса удобно рассматривать как обычный массив, в котором в качестве индексов можно использовать не только целые числа, но и значения других типов — например, строки.
R>Т.е. для удобства его представляют как бы массив, но любой вменяемый с++ программист знает, что это не совсем так. R>Так, во всех книжках обращают внимание, что за красивым и удобным интерфейсом вот такого использования:
R>
R>if( m.count(key0) )
R>{
R> m[key0] = value0;
R>}else{
R> m.insert( make_pair(key0, default_value) ); // т.е. для тяжелых типов не есть хорошо!
R> m[key0] = value0;
R>}
R>
R>Но Вы конечно же это не читали, т.к. в это время уже бежали писать статью про std::map на Вашем любимом форуме.
С>>Но в любом случае спасибо вам за участие. Я уже всю дискуссию подытожил в своем сообщении по адресу http://clipper.borda.ru/?1-6-0-00000022-000-0-0-1326309482 С>>Почитайте, будет вам интересно. Я не думаю, что что-то принципиально новое вы сможете мне возразить. То есть я не вижу никаких серьезных контраргументов моей постановке вопроса.
R>Ничего интересного Вы там не пишите. Мне искренне жаль тех, кто решит познать с++ по Вашим статьям.
R>Кстати, "A map satisfies all of the requirements of a container, of a reversible container" означает, что у std::map имеется reverse_iterator, const_reverse_iterator, rbegin(), rend(). И совсем не обязан иметь средство реверсивного расположения значений элементов! Вы бы хотя бы стандарт открыли что-ли!? И вообще курите поменьше ту дрянь, что дает Вам возможность думать настолько обобщенно и концептуально..
R>P.S. Когда в следующий раз захотите выпендриться на своем форуме за счет Саттера, хотя бы прочитайте ВНИМАТЕЛЬНО то, что он пишет, например комменты к коду. Если не поняли с первого раза, читайте пока не дойдет, а уже потом пишите статьи, про то, какой Вы умный!
Дело в том, что когда вы цитируете описание std::map, вы просто перечисляете открытый интерфейс этого контейнера, то есть те функции-члены, которые есть в контейнере. Но при этом никак не можете понять, что ключ и отображаемое значение — это независимые между собой части. В том смысле, что один раз завяде элемент контейнера, вы затем отображаемое значение этого элемента можете менять сколько угодно раз. Но хуже того, вы даже сами не понимаете то, что цитируете. Вы цитируете сходство с вектором, не понимая того, что имеется виду общий способ обращения по ключу к элементу, только у вектора этот ключ имеет заранее определенный тип unsigned int, и сами ключи должны следовать без пропусков. Что это означает? Это означает, что лишь организован доступ по ключу, но пользователь работает с отображаемыми объектами! Ключ играет роль индекса к элементу, а изменяется именно отображаемое значение. Работает пользовательна самом деле не с парой, так как первый элемент пары — это константное значение, а именно с отображаемым значением. Ключи создаются только раз и больше никакой роли кроме роли индекса к элементу не играют. Далее пользователь работает с отображаемым значением, модифицируя его по мере необходимости и пока элемент не будет удален. То есть изменение элемента относится именно к отображаемому значению, а не ключу. Поэтому реверсировать отображаемые значения для std::map это также естественно, как и для вектора, так как реверсия — это ничто иное, как изменение хранимых значений, а контейнеры для того и существуют, чтобы можно было менять значения.
Что касается Герба Саттера, то, извините, ничего конкретного вы не сказали. Так что это всего лишь ваше словоблудие. Если есть что сказать по существу, то говорите. Если я там что-то неправильно написал, то там и укажите, что я неправильно написал. Иначе вы выглядите, как бы сказать, ментором, который сам себе присвоил этот титул. То есть совершенно необосновано.
А то, что, якобы, я не интересно написал про reverse для std::map говорит лишь об одном, что вы не понимаете проблему. А стандарт как раз и движется в том направлении, которое я указал. Поэтому есть два варианта: либо расширить формы алгоритма std::reverse, либо добавить функцию-член класса в std::map. Я уже написал расширенную форму алгоритма std::reverse, которая позволяет работать с любым контейнером. Это наиболее гибкий подход, который не требует расширения существующего интерфейса std::map, Но чтобы это сдделать, нужно вникнуть и понимать проблему. Вы ее к сожалению не понимаете, так как цитируете банальный материал, без осознания сущности контейнеров, что контейнеры предназначены для изменения хранимых в них данных. А потмоу способы изменения данных долны быть унифицированы и просты в использовании. А этого для std::mmap в настоящее время нет. Поэтому это и является явным упущением стандарта.
R>if( m.count(key0) )
R>{
R> m[key0] = value0;
R>}else{
R> m.insert( make_pair(key0, default_value) ); // т.е. для тяжелых типов не есть хорошо!
R> m[key0] = value0;
R>}
R>
Вот вы написали банальную вещь. Допустим вы создали элемент std::map, а дальше-то что?! Можете вы этому элементу присвоить новое отображаемое значение или нет? То есть создали вы элемент с помощью m[key1] = value1;, а дальше разве это так и остается неизменным? Нет, конечно. Далее вы будете менять значения ваших элементов, то есть будут чаксто встречаться операторы m[key1] = value2; m[key1] = value3; m[key1] = value 4; и т.д. А что такое операция инверсии? Это тоже самое изменение значений элементов. Как вы ее собираетесь выполнять? И почему вы считаете, если изменять значения элементов можно, но нельзя деать операцию reverse? Чем она отличается от простого изменения элемента контейнера std::map?!Да ничем! Просто исходное новое значение вы берете из другого элемента этого же контейнера. Только и всего. Но теперь возникает вопрос, а как сделать эту операцию эффективно и корректно? Очевидно, что семантически действие этой операции одинаково для всех контейнеров, точно также, как операция swap семантически одинакова для всех контейнеров и объектов, независимо от их организации. Главное требование — это всего лишь, чтобы контейнер был реверсивным, то есть чтобы он имел двусторонний итератор или итератор произвольного доступа. Это является достаточным условием в общем случае для применения операции реверсии. И чего вы никак понять не можете. А если все условия выполняются и потребность в такой операции есть, то возникает второй вопрос? почему эта операция отсутствует для заданного контейнера? Оказывается, что на самом деле никаких оснований, чтобы эта операция у std::map отсутствовала, нет! Вот чего вы не понимаете.
Я вам настоятельно рекомендую почитать книгу Скотта Майерса "Эффективное использование STL" в частнсти его совет 23 "Используйте возможность замены ассоциативных контейнеров сортированными векторами", и тогда вы поймете, что между веторами и ассоциативными контейнерами существует неформальная связь.
То есть прежде чем цитировать мне банальные вещи, вы постарайтесь понять суть этих контейнеров и неформальную связь между ними, и тогда вы поймете смысл поставленной мною проблемы.
Здравствуйте, Сыроежка, Вы писали:
С>Здравствуйте, rumit7,
С>Я вам настоятельно рекомендую почитать книгу Скотта Майерса "Эффективное использование STL" в частнсти его совет 23 "Используйте возможность замены ассоциативных контейнеров сортированными векторами", и тогда вы поймете, что между веторами и ассоциативными контейнерами существует неформальная связь. С>То есть прежде чем цитировать мне банальные вещи, вы постарайтесь понять суть этих контейнеров и неформальную связь между ними, и тогда вы поймете смысл поставленной мною проблемы.
Спорить с Вами безполезное занятие, т.к. любой аргумент, будь то высказывание Майерса, Саттера или цитата из стандарта Ваш больной мозг трактует как подтверждение Вашей гениальности!
За сим спрошу прямо — что за травку курим?
Re[16]: Разместить в обратном порядке отображаемые значения
Здравствуйте, rumit7, Вы писали:
R>Здравствуйте, Сыроежка, Вы писали:
С>>Здравствуйте, rumit7,
С>>Я вам настоятельно рекомендую почитать книгу Скотта Майерса "Эффективное использование STL" в частнсти его совет 23 "Используйте возможность замены ассоциативных контейнеров сортированными векторами", и тогда вы поймете, что между веторами и ассоциативными контейнерами существует неформальная связь. С>>То есть прежде чем цитировать мне банальные вещи, вы постарайтесь понять суть этих контейнеров и неформальную связь между ними, и тогда вы поймете смысл поставленной мною проблемы.
R>Спорить с Вами безполезное занятие, т.к. любой аргумент, будь то высказывание Майерса, Саттера или цитата из стандарта Ваш больной мозг трактует как подтверждение Вашей гениальности!
R>За сим спрошу прямо — что за травку курим?
Кстати сказать, вы хорошо сделали, что напомнили стандарт. Если вы посмотрите главу 25 стандарта, где описаны стандартные алгоритмы, и параграф, где описан непосредственно алгоритм std::reverse, то единственные требования к этому алгоритму — это чтобы был по итератор не ниже двустороннего, а величины, на которые указывает итератор, были бы заменяемы, то есть могли использовать swap. Никаких других ограничений нет, и тем более нет упоминания в качестве иселючения для применения контейнера std::map. Это обязательство стандарта по применению алгоритма. И сам же стандарт его нарушает. То есть я вообще мог здесь не распинатьсяы, а указать просто на то, что стандарт не выполняет своих обязательств. То есть он был по крайней мере в разделе стандартных алгоритмов для этого алгоритма указать все исключения его применения, если основные требования выполнены, такие, как, например, наличие двустороннего итератора. Но этого нет. Этого вполне достатончо, чтобы заявить, что стнадарт содержит серьезные упущения.
А на самом деле проблема решается очень просто. В стандарте должна быть форма этого алгоритма вида
void reverse( BidirectionalIterator first,
BidirectionalIterator last,
BinaryPredicate binary_predicate );
и тогда никаких пролблем с коонтейнером std::map не было бы. К этому я и хотел подвести дискуссиию. Но оказалось, что уровень понимания вопроса настолько низок у аудитории, что бесполезно рассуждать на подобные темы.
>> MZ>Порядок хранения элементов в std::map не определён. Обратным порядком для >> MZ>неоределённого порядка будет также неопределённый порядок. Следовательно, >> MZ>тебе ПРОСТО НЕ НУЖНО НИЧЕГО ДЕЛАТЬ. >> >> Ты что-то путаешь. Порядок на множестве ключей определен и этот порядок для
MZ>Определён порядок на ключах. И порядок итерирования. Порядок хранения -- не MZ>определён.
А с какой стороны нам поможет знание устройства хранения? Прикладные задачи едва ли полагаются на это. Они оперируют публичным контрактом класса перед клиентом: интерфейсом и гарантиями сложности методов. В данному случае с std::map публичный контракт определен стандартом и с какой стороны меня должно трогать его внутреннее устройство с прикладной точки зрения?
Re[17]: Разместить в обратном порядке отображаемые значения
Здравствуйте, Сыроежка, Вы писали:
С>Кстати сказать, вы хорошо сделали, что напомнили стандарт. Если вы посмотрите главу 25 стандарта, где описаны стандартные алгоритмы, и параграф, где описан непосредственно алгоритм std::reverse, то единственные требования к этому алгоритму — это чтобы был по итератор не ниже двустороннего,
Выполняется.
С>а величины, на которые указывает итератор, были бы заменяемы, то есть могли использовать swap.
Не выполняется, поскольку итератор указывает на std::pair<const KeyT, ValueT>.
То, чего вы хотите — это итератор по значениям std::map. К паре таких итераторов будет применим стандартный алгоритм std::reverse. И они уже реализованы в библиотеке boost::range.
И тем не менее, это не отменяет того, что перестановка значений при сохранении ключей осмысленна только в узком частном случае, когда ключи образуют непрерывный отрезок натурального ряда.
Re[17]: Разместить в обратном порядке отображаемые значения
Здравствуйте, Сыроежка, Вы писали:
С>Кстати сказать, вы хорошо сделали, что напомнили стандарт. Если вы посмотрите главу 25 стандарта, где описаны стандартные алгоритмы, и параграф, где описан непосредственно алгоритм std::reverse, то единственные требования к этому алгоритму — это чтобы был по итератор не ниже двустороннего, а величины, на которые указывает итератор, были бы заменяемы, то есть могли использовать swap.
For each non-negative integer i <= (last — first)/2, applies iter_swap to all pairs of iterators first + i, (last — i) — 1.
C++ Standart 2003, 25.2.2 Swap:
template<class T> void swap(T& a, T& b);
Requires: Type T is CopyConstructible (20.1.3) and Assignable (23.1).
C++ Standart 2003, 23.1 Container requirements, Table 64—Assignable requirements:
expression | return type | post-condition
-------------------------------------------------
t = u | T& | t is equalent to u
-------------------------------------------------
In the map class template, these are bidirectional iterators.
Dereferencing this iterator accesses the element's value, which is of type pair<const Key,T>.
Следовательно, pair<const Key,T> не может использовать swap. На мой взгляд, стандарт последователен в данном случае.
С>Никаких других ограничений нет, и тем более нет упоминания в качестве иселючения для применения контейнера std::map. Это обязательство стандарта по применению алгоритма. И сам же стандарт его нарушает. То есть я вообще мог здесь не распинатьсяы, а указать просто на то, что стандарт не выполняет своих обязательств. То есть он был по крайней мере в разделе стандартных алгоритмов для этого алгоритма указать все исключения его применения, если основные требования выполнены, такие, как, например, наличие двустороннего итератора. Но этого нет. Этого вполне достатончо, чтобы заявить, что стнадарт содержит серьезные упущения.
Re[18]: Разместить в обратном порядке отображаемые значения
Здравствуйте, Centaur, Вы писали:
C>Здравствуйте, Сыроежка, Вы писали:
С>>Кстати сказать, вы хорошо сделали, что напомнили стандарт. Если вы посмотрите главу 25 стандарта, где описаны стандартные алгоритмы, и параграф, где описан непосредственно алгоритм std::reverse, то единственные требования к этому алгоритму — это чтобы был по итератор не ниже двустороннего,
C>Выполняется.
С>>а величины, на которые указывает итератор, были бы заменяемы, то есть могли использовать swap.
C>Не выполняется, поскольку итератор указывает на std::pair<const KeyT, ValueT>.
C>То, чего вы хотите — это итератор по значениям std::map. К паре таких итераторов будет применим стандартный алгоритм std::reverse. И они уже реализованы в библиотеке boost::range.
C>И тем не менее, это не отменяет того, что перестановка значений при сохранении ключей осмысленна только в узком частном случае, когда ключи образуют непрерывный отрезок натурального ряда.
Во-первых, почему std::pair не является swapable? Вы не можете к объектам этого класса применить алгоритм swap?
Во-вторых, совершенно не понятно, почему имеет смысл только для частного сулчая, когда ключи образуют непрерывный отрезок натурального ряда? А если в качества ключей идут строки, причем не непрерывно согласно их кодам, то что тогда?!
