Здравствуйте, Сыроежка, Вы писали:

С>Задача простая: для заданного контейнера std::map реверсировать отображаемые значения.
С>Хочу понять, почему такой алгоритм не включен в качестве функции-члена класса std::map.

Потому что эта операция в общем случае неосмысленна.

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, Сыроежка, Вы писали:

С>>Здравствуйте, jazzer, Вы писали:

J>>>Здравствуйте, Сыроежка, Вы писали:

С>>>>Как проще выполнить реверсию значений элементов для заданного контейнера std::map? То есть ключи остаются на месте, а меняются в обратном порядке отображаемые значения.

J>>>Зачем?
J>>>Если затем, чтоб обходить в обратном порядке, то есть rbegin/rend.

С>>Я вас уверяю, что задачи, возникающие на практике. значительно разнообразнее, чем может представить ваша фантазия в данный момент!

J>Этот комментарий, безусловно, всё прояснил, и главное, ответил на вопрос "зачем".

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

Здравствуйте, Сыроежка, Вы писали:

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

Какой аргумент? Что для обратного обхода есть итераторы и надо пользоваться ими, благо скорость одна и та же будет? Ну так это же медицинский факт

Ну и я задачу так и не услышал. Реальную задачу, а не то, как ты ее пытаешься решить при помощи std::map, требуя реверса.
Вряд ли ведь задача ставится в терминах мапа и ключей-значений, правда?

You will always get what you always got
  If you always do  what you always did

Здравствуйте, Centaur, Вы писали:

C>Здравствуйте, Сыроежка, Вы писали:

С>>Задача простая: для заданного контейнера std::map реверсировать отображаемые значения.
С>>Хочу понять, почему такой алгоритм не включен в качестве функции-члена класса std::map.

C>Потому что эта операция в общем случае неосмысленна.

Не говорите "гоп" пока не перепрыгнули! Это для вас она сейчас является неосмысленной, потому что вы не в состоянии сейчас что-то придумать. А практика показывает, что существующие задачи настолько разнообразны, что не хватит никакой фантазии человека, чтобы представить все задачи, с которыми стаокивается программист!

Здравствуйте, jazzer, Вы писали:

J>Здравствуйте, Сыроежка, Вы писали:

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

J>Какой аргумент? Что для обратного обхода есть итераторы и надо пользоваться ими, благо скорость одна и та же будет? Ну так это же медицинский факт

J>Ну и я задачу так и не услышал. Реальную задачу, а не то, как ты ее пытаешься решить при помощи std::map, требуя реверса.
J>Вряд ли ведь задача ставится в терминах мапа и ключей-значений, правда?

Так ч и не собираюсь придумывать реальную задачу. Реальные задачи существуют помимо вашей и меой фантазии. Вы не на то облращаете внимание! Не беспокойтесь, как я уже сказал, мир реальных задач значительно богаче вашей фантазии, что вам даже и не снилось, какие задачи могут встретиться на практике. Я вам уже сказал, что ваш аргумент не состоятелен, так как согласно ему, вообще непонятно, зачем существует этот алгоритм, например, для векторов?
Вопрос состоит в другом, почему для контейнера map не применим и не существует алгоритм reverse. Ведь на самом деле не обязательно переставлять весь набор элементов. Может, например, потребоваться перестановканекоторого поддиапазона набора элементов и т.д.

Здравствуйте, uzhas, Вы писали:

U>Здравствуйте, baily, Вы писали:

B>>Непонятно, почему заминусовали данный ответ. Ну, конечно, можно придраться, что порядок элементов в map зависит от ключа и это иногда нужно.
U>std::map — это не просто какой-то там ассоциативный контейнер, это контейнер, предоставляющий некие гарантии по сложности операций, по интерфейсу и по семантике
U>крайне интересным считаю документацию контейнеров от SGI : http://www.sgi.com/tech/stl/Map.html
U>там формально введена некая классификация контейнеров и вы можете убедиться, что std::map удовлетворяет моделям Unique Sorted Associative Container, Pair Associative Container
U>именно подобные модели позволяют для конкретно этого контейнера реализовывать алгоритмы, которые не прикрутишь к другим ассоциативным контейнерам типа хеш-таблиц
U>в частности, алгоритм ТС применим к std::map и не применим к хеш-таблицам, потому что там нет порядка ключей

Это как раз и относится к тем придиркам, которые я имел ввиду, когда говорил, что в map порядок элементов зависит от ключа.
Что такое map и чем он отличается от hash_map я прекрасно знаю.

B>>Однако операции для map, которые переставляют значения для ключей типа reverse, уж совершенно лишены смысла.
U>операция не лишена смысла, в ней заинтересован ТС и уже дали даже один вариант реализации

Ну так и подсчитать среднее гармоническое для элементов map, тоже не лишена смысла и наверняка кому то нужна.
И реализовать ее тоже не сложно. Могу привести даже несколько вариантов реализации, если это вам кажется таким важным.
Проблема только в том, что если начать добавлять такие "нужные" операции в интерфейс класса, то с ним работать будет невозможно.

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

The fundamental property of iterators of associative containers is that they iterate through the containers in the non-descending order of keys where non-descending is defined by the comparison that was used to construct them.

(c) Стандарт

С>Вопрос состоит в другом, почему для контейнера map не применим и не существует алгоритм reverse. Ведь на самом деле не обязательно переставлять весь набор элементов. Может, например, потребоваться перестановканекоторого поддиапазона набора элементов и т.д.

Ответ вас видимо удивит, но все же: по определению.

Здравствуйте, Сыроежка, Вы писали:

С>Здравствуйте, baily, Вы писали:


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

Я согласен, что реверсирование данных это очень полезная вещь, но, если вам нужно то, что предложили здесь

Автор: rm822
Дата: 11.01.12

, то это не реверсирование,
так как данная операция переставляет не элементы контейнера, которые есть пары ( ключ, значение ), а переставляет только значения, оставляя ключи на местах.
То есть при таком реверсировании элементы контейнера меняются!!! И вот данная операция не очень полезна.

Настоящее же реверсирование map — это получение контейнера нового типа, у которого функция сравнения ключей имеет противоположный смысл.
Реализовать тоже не сложно.

Здравствуйте, Сыроежка, Вы писали:

С>Вопрос состоит в другом, почему для контейнера map не применим и не существует алгоритм reverse. Ведь на самом деле не обязательно переставлять весь набор элементов. Может, например, потребоваться перестановканекоторого поддиапазона набора элементов и т.д.

Потому что алгоритм reverse для контейнеров std::vector и std::list не изменяет сами хранимые сущности, а только меняет их порядок.
В случае std::map хранимой сущностью является пара "ключ-значение", которые контейнер std::map хранит в порядке, задаваемом ключами и предикатом.
Твой reverse для std::map не переставляет сущности, а изменяет их.
Т.е., из одного набора данных нужно получить полностью другой набор данных, а алгоритм — трансформирующий.
Ну а поскольку трансформаций может быть сколько угодно, а не только "обменять значения", в общем виде такого алгоритма у самого контейнера нет.

Здравствуйте, Сыроежка, Вы писали:

С>Здравствуйте, jazzer, Вы писали:

J>>Здравствуйте, Сыроежка, Вы писали:

С>>>Как проще выполнить реверсию значений элементов для заданного контейнера std::map? То есть ключи остаются на месте, а меняются в обратном порядке отображаемые значения.

J>>Зачем?
J>>Если затем, чтоб обходить в обратном порядке, то есть rbegin/rend.

С>Я вас уверяю, что задачи, возникающие на практике. значительно разнообразнее, чем может представить ваша фантазия в данный момент!

Не нужно тащить в интерфейс библиотечного класса все функции, которые возникают на практике.

Здравствуйте, Сыроежка, Вы писали:

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

Для вывода барышень в обратном порядке достаточно rbegin|rend.

Сыроежка:

С>Хочу понять, почему такой алгоритм не включен в качестве функции-члена класса std::map.

Насколько часто нужна такая операция? Стандартная библиотека не может включать в себя абсолютно всё. Она даёт некую базовую наиболее часто используемую функциональность и предоставляет возможность эту базовую функциональность расширять. Так всегда было и так будет дальше.

Реализовать такой алгоритм ручками несложно:

#include <utility>
 
template <class MapIterator>
    void reverse_mapped_values(MapIterator first, MapIterator ending)
{
    for (;;)
        if (first == ending || first == --ending)
            return;
        else
        {
            using std::swap;
            swap(first->second, ending->second);
            ++first;
        }
}

IMHO, в стандартной библиотеки есть куда более неприятные пробелы — например, отсутствие у файловых потоков конструктора, принимающего имя файла в юникоде (что для меня во многих случаях делает такие потоки бесполезными).

Здравствуйте, Сыроежка, Вы писали:

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

Э, нет, батенька. Теперь понятно происхождения вашей путаницы.

Тут имеется два параметра :
1) "Исходный номер" барышни, по сути ее числовой идентификатор
2) "Порядковый номер" барышни в туре

Для представления всех девушек можно использовать map с ключом равным "Исходный номер".
А вот для представления девушек в каждом туре надо использовать vector из их исходных номеров.
Положение в этом vector и будет текущим "Порядковым номером"

Здравствуйте, Masterkent, Вы писали:

M>Сыроежка:

С>>Хочу понять, почему такой алгоритм не включен в качестве функции-члена класса std::map.

M>Насколько часто нужна такая операция? Стандартная библиотека не может включать в себя абсолютно всё. Она даёт некую базовую наиболее часто используемую функциональность и предоставляет возможность эту базовую функциональность расширять. Так всегда было и так будет дальше.

M>Реализовать такой алгоритм ручками несложно:

M>

#include <utility>
 
M>template <class MapIterator>
M>    void reverse_mapped_values(MapIterator first, MapIterator ending)
M>{
M>    for (;;)
M>        if (first == ending || first == --ending)
M>            return;
M>        else
M>        {
M>            using std::swap;
M>            swap(first->second, ending->second);
M>            ++first;
M>        }
M>}

M>IMHO, в стандартной библиотеки есть куда более неприятные пробелы — например, отсутствие у файловых потоков конструктора, принимающего имя файла в юникоде (что для меня во многих случаях делает такие потоки бесполезными).

Здесь вопрос не о включении абсолютно всего, так как стандартный алгоритм уже включен в библиотеку. То есть нужно лишь сделать так, чтобы std::map не остался не охваченным. Потому что в противном случае возникают вопросы и сложности и несогласованность кода.
Впорос, как часто это надо, это чисто риторический вопрос. Например, в своей программе вы можете воообще не исаользовать ни одного стандартного алгоритма. Следует ли из этого, что все алгоритмы надо исключить из стандартной библиотеки? А ответьте мне на вопрос, как часто вы в свооих проектах использовали стандартные алгоритмы для перестановок?!
По поводу того, что можно написать код "своими ручками", то я уже по этому поводу достаточно ясно ответил, что это не удовлетворительное решение, когда стандартную оперрацию каждый программист пишет своими ручками.

Здравствуйте, baily, Вы писали:

B>Здравствуйте, Сыроежка, Вы писали:

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

B>Э, нет, батенька. Теперь понятно происхождения вашей путаницы.

B>Тут имеется два параметра :
B>1) "Исходный номер" барышни, по сути ее числовой идентификатор
B>2) "Порядковый номер" барышни в туре

B>Для представления всех девушек можно использовать map с ключом равным "Исходный номер".
B>А вот для представления девушек в каждом туре надо использовать vector из их исходных номеров.
B>Положение в этом vector и будет текущим "Порядковым номером"

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

Здравствуйте, Анатолий Широков, Вы писали:

С>>Вопрос состоит в другом, почему для контейнера map не применим и не существует алгоритм reverse. Ведь на самом деле не обязательно переставлять весь набор элементов. Может, например, потребоваться перестановканекоторого поддиапазона набора элементов и т.д.

АШ>Ответ вас видимо удивит, но все же: по определению.

Никакого опеределения нет! Чтобы было вам поонятно, то обратитсеь к адаптерам контейнеров и их эволюции. Я об этом писал в http://clipper.borda.ru/?1-6-0-00000009-000-0-0-1320937835

На мой взгляд это явный недочет стандартной библиотеки.

Здравствуйте, rus blood, Вы писали:

RB>Здравствуйте, Сыроежка, Вы писали:

С>>Вопрос состоит в другом, почему для контейнера map не применим и не существует алгоритм reverse. Ведь на самом деле не обязательно переставлять весь набор элементов. Может, например, потребоваться перестановканекоторого поддиапазона набора элементов и т.д.

RB>Потому что алгоритм reverse для контейнеров std::vector и std::list не изменяет сами хранимые сущности, а только меняет их порядок.
RB>В случае std::map хранимой сущностью является пара "ключ-значение", которые контейнер std::map хранит в порядке, задаваемом ключами и предикатом.
RB>Твой reverse для std::map не переставляет сущности, а изменяет их.
RB>Т.е., из одного набора данных нужно получить полностью другой набор данных, а алгоритм — трансформирующий.
RB>Ну а поскольку трансформаций может быть сколько угодно, а не только "обменять значения", в общем виде такого алгоритма у самого контейнера нет.

Я не соогласен с вашей позицией, так как в std::map а значение как раз является неконстантным и может меняться. То есть ключ больше относится не к значению, а к организации хранения данных в конкретном типе уонтейнера. То есть в векторе вы можете обращаться к элементамс вектора по индексу элемента, как, например, v[0], v[1] и т.д., а в std::map индекс заменяется ключом, как, например, m[key1], m[key2] и т.д.
То есть ключ — больше выполняет роль указателя или индекса доступа к данным. Сами же данные можно менять, то есть они могут размещаться по другому индексу или ключу точно также, как и векторе.
Конечно у каждого контейнера есть специфика хранения данных, но тем не менее семаника reverse достатончо прозрачна. Она обычно относится к самим данным независимо от способа их организации и хранения. То есть когда мы говорим о std::map мы естественно должны понимать специфику организации этого котейнера, а, сооответственно, алгоритм reverse должен отражать в себе эту специфику для этого контейнера. Исходя из этой позиции, я не вижу каких-то среьезных причин не даптировать этот алгоритм для данного коонтейнера. Такачя адаптация моогла бы быть выполнена с помощью функции-члена класса этого контейнера.
Пример такой адаптации я вижу в функции-члене класса insert, где указывается позиция, перед которой надо вставить новый элемент. Но вы хорошо понимаете, что тем не менее элемент не будет вставлен именно перед этой позицией в std::map. Но джля сохранения унифицированного подхода список параметров этой функции остается прежним, как и для других контейнеров, хотя ее действие не соответствует действию аналогичных функций других контейнеров. То есть учитывается специфика std::map, но формально сохраняется общий подход. То же самое можно было бы сделать и с reverse.

Сыроежка:

С>Здесь вопрос не о включении абсолютно всего, так как стандартный алгоритм уже включен в библиотеку. То есть нужно лишь сделать так, чтобы std::map не остался не охваченным.

Ну, можно было бы ввести трансформирующие итераторы для работы с mapped values. Можешь написать в Спортлото сюда свои пожелания, и, быть может, их учтут в комитете по стандартизации (некоторые люди из комитета регулярно посещают данный ресурс).

С>Впорос, как часто это надо, это чисто риторический вопрос.

Это существенный вопрос. Стандартная библиотека не резиновая, помещать туда всё подряд, как в Boost, не получится.