Здравствуйте, baily, Вы писали:
B>Здравствуйте, Сыроежка, Вы писали:
С>>Здравствуйте, jazzer, Вы писали:
J>>>Здравствуйте, Сыроежка, Вы писали:
С>>>>Как проще выполнить реверсию значений элементов для заданного контейнера std::map? То есть ключи остаются на месте, а меняются в обратном порядке отображаемые значения.
J>>>Зачем? J>>>Если затем, чтоб обходить в обратном порядке, то есть rbegin/rend.
С>>Я вас уверяю, что задачи, возникающие на практике. значительно разнообразнее, чем может представить ваша фантазия в данный момент!
B>Не нужно тащить в интерфейс библиотечного класса все функции, которые возникают на практике.
А на самом деле тут исходная позиция не в том, чтобы тащить все функции, которые возникают на практике, в иинтерфейс, а в том, что прерывается логическая последовательность использования стандартного алгоритма revrese. То есть он существукт, может применяться для контейнеров, а затем, бац!, обнаруживается, что имеется провал, и что этот алгоритм, который на самом деле имеет тот же самый семантический смысл, просто отсутствует!
Я считаю это серьезным упущением стандарта. То есть я с самого начала считал, что это недостаток стандарта, но думал, задавая вопрос, что можетт быть существует давно очень простой, а самое главное общепринятый метод, как выполнить этот алгоритм для std::map, а я просто этот банальный метод не знаю. И поэтому хотел проверить, существуетт ли такой метод, или нет. Оказалось, что на самом деле такого общепринятого и де-факто стандартного метода нет! То есть поступают различные предлоежния, как этот сделать, со многими из которых я не соогласен и сделал бы это по-другому. А это значит имеет место несогласовнность в реализации стандартного алгоритма. То есть имеет место серьезный пробел в согласованности использования алгоритма.
Здравствуйте, Masterkent, Вы писали:
M>Сыроежка:
С>>Здесь вопрос не о включении абсолютно всего, так как стандартный алгоритм уже включен в библиотеку. То есть нужно лишь сделать так, чтобы std::map не остался не охваченным.
M>Ну, можно было бы ввести трансформирующие итераторы для работы с mapped values. Можешь написать в Спортлотосюда свои пожелания, и, быть может, их учтут в комитете по стандартизации (некоторые люди из комитета регулярно посещают данный ресурс).
С>>Впорос, как часто это надо, это чисто риторический вопрос.
M>Это существенный вопрос. Стандартная библиотека не резиновая, помещать туда всё подряд, как в Boost, не получится.
Здесь я с вами не соглашусь. Согласованность подхода значительно важнее понятия резиновости библиотеки. Для примера возьмем историю алгоритма copy_if, который, как известно, Страуструп в свое время выкинул из библиотеки. И что, это улучшило библиотеку? Нет коонечно! написать этот алгоритм самостоятельно достатоноч просто, но тем не менее это влекло к отсутствию общей семантики и согласованности библиотеки. А потому Страуструп признал свою ошибку, и copy_if, снова был включен в стандарт. На мой взгляд анналогичная ситуация имеет место и с reverse для std::map, но только ситуация еще хуже! так как 1) будет существовать многообразие реализаций этого алгоритма большее, чем оп сравнению с copy_if$ 2) появится многообразие названий этого алгоритма, так как если его назвать точно также, как reverse, то это буде т вводить в заблуждение, так как бдет путаница со стандартным алгоритмом.
Все эти вопросы были бы сняты, если функция reverese была бы членом класса.
Здравствуйте, Сыроежка, Вы писали:
С>Так ч и не собираюсь придумывать реальную задачу. Реальные задачи существуют помимо вашей и меой фантазии. Вы не на то облращаете внимание! Не беспокойтесь, как я уже сказал, мир реальных задач значительно богаче вашей фантазии, что вам даже и не снилось, какие задачи могут встретиться на практике.
"Не пытайтесь это понять, понять это невозможно" (c)
Т.е. ты придумываешь сам себе развлечения, не имеющие отношения к реальности? Тоже дело
С>Я вам уже сказал, что ваш аргумент не состоятелен, так как согласно ему, вообще непонятно, зачем существует этот алгоритм, например, для векторов? С>Вопрос состоит в другом, почему для контейнера map не применим и не существует алгоритм reverse. Ведь на самом деле не обязательно переставлять весь набор элементов. Может, например, потребоваться перестановканекоторого поддиапазона набора элементов и т.д.
Я тебе открою тайну — вектор, как и список, не поддерживает свою отсортированность. Т.е. ты отсортировал его, а после это можешь джелать все, что хочешь, в т.ч. сортированность нарушить. Поэтому и есть sort, reverse, random_shuffle и другие веселые алгоритмы, которые в принципе отсутствуют для контейнеров, поддерживающих свою отсортированность.
А мап и сет — это контейнеры, сохраняющие свою отсортированность при любых операциях, и эта отсортированность поддерживается компаратором, который ты изменить для данного объекта не можешь (что имеет смысл, в общем-то), учитывая, что ты можешь хранить итераторы внутрь контейнера, с соответствующими гарантиями. И любые манипуляции с порядком элементов за пределами компаратора нарушат главное свойство — отсортированность.
Так что твой reverse может иметь смысл исключительно в терминах смены компаратора, что запрещено — а это значит, что ты должен создать новый объект мапа/сета с новым компаратором, который будет работать наоборот, и перекинуть данные в него — тогда все будет как надо.
Еще вариант — использовать boost::multi_index: там можно извращаться как угодно.
Здравствуйте, baily, Вы писали:
B>Э, нет, батенька. Теперь понятно происхождения вашей путаницы.
B>Тут имеется два параметра : B>1) "Исходный номер" барышни, по сути ее числовой идентификатор B>2) "Порядковый номер" барышни в туре
B>Для представления всех девушек можно использовать map с ключом равным "Исходный номер". B>А вот для представления девушек в каждом туре надо использовать vector из их исходных номеров. B>Положение в этом vector и будет текущим "Порядковым номером"
Здравствуйте, Сыроежка, Вы писали:
С>А на самом деле тут исходная позиция не в том, чтобы тащить все функции, которые возникают на практике, в иинтерфейс, а в том, что прерывается логическая последовательность использования стандартного алгоритма revrese. То есть он существукт, может применяться для контейнеров, а затем, бац!, обнаруживается, что имеется провал, и что этот алгоритм, который на самом деле имеет тот же самый семантический смысл, просто отсутствует!
С>Я считаю это серьезным упущением стандарта.
Вот, понимаешь, прерывается логическая последовательность квадратного корня. Для 4 работает, для 3 — тоже, для 2 — работает, даже для 1 работает, и более того, даже для нуля! А затем, бац!, обнаруживается, что имеется провал и корень из -1 извлечь нельзя.
Я считаю это серьезным упущением теории действительных чисел.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Сыроежка, Вы писали:
С>>Так ч и не собираюсь придумывать реальную задачу. Реальные задачи существуют помимо вашей и меой фантазии. Вы не на то облращаете внимание! Не беспокойтесь, как я уже сказал, мир реальных задач значительно богаче вашей фантазии, что вам даже и не снилось, какие задачи могут встретиться на практике. J>"Не пытайтесь это понять, понять это невозможно" (c) J>Т.е. ты придумываешь сам себе развлечения, не имеющие отношения к реальности? Тоже дело
С>>Я вам уже сказал, что ваш аргумент не состоятелен, так как согласно ему, вообще непонятно, зачем существует этот алгоритм, например, для векторов? С>>Вопрос состоит в другом, почему для контейнера map не применим и не существует алгоритм reverse. Ведь на самом деле не обязательно переставлять весь набор элементов. Может, например, потребоваться перестановканекоторого поддиапазона набора элементов и т.д. J>Я тебе открою тайну — вектор, как и список, не поддерживает свою отсортированность. Т.е. ты отсортировал его, а после это можешь джелать все, что хочешь, в т.ч. сортированность нарушить. Поэтому и есть sort, reverse, random_shuffle и другие веселые алгоритмы, которые в принципе отсутствуют для контейнеров, поддерживающих свою отсортированность. J>А мап и сет — это контейнеры, сохраняющие свою отсортированность при любых операциях, и эта отсортированность поддерживается компаратором, который ты изменить для данного объекта не можешь (что имеет смысл, в общем-то), учитывая, что ты можешь хранить итераторы внутрь контейнера, с соответствующими гарантиями. И любые манипуляции с порядком элементов за пределами компаратора нарушат главное свойство — отсортированность.
J>Так что твой reverse может иметь смысл исключительно в терминах смены компаратора, что запрещено — а это значит, что ты должен создать новый объект мапа/сета с новым компаратором, который будет работать наоборот, и перекинуть данные в него — тогда все будет как надо.
J>Еще вариант — использовать boost::multi_index: там можно извращаться как угодно.
J>Я ответил на твой вопрос?
Не просветите меня, с каких это пор список не поддерживает свою организацию хранения данных?! Как раз каждый контейнерсуществует самостоятельно именно из-за того, что поддерживает собственную организацию хранения данных.
Что касается всего остального, то это говорит, что вы не в состоянии мыслить концептуально. Вы относитеьс к тем людям, которые не в состоянии обощать, а постоянно решаете частные вопросы. Для программиста — это серьезный недостаток. Я вам советую исправлять его!
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Сыроежка, Вы писали:
С>>А на самом деле тут исходная позиция не в том, чтобы тащить все функции, которые возникают на практике, в иинтерфейс, а в том, что прерывается логическая последовательность использования стандартного алгоритма revrese. То есть он существукт, может применяться для контейнеров, а затем, бац!, обнаруживается, что имеется провал, и что этот алгоритм, который на самом деле имеет тот же самый семантический смысл, просто отсутствует!
С>>Я считаю это серьезным упущением стандарта.
J>Вот, понимаешь, прерывается логическая последовательность квадратного корня. Для 4 работает, для 3 — тоже, для 2 — работает, даже для 1 работает, и более того, даже для нуля! А затем, бац!, обнаруживается, что имеется провал и корень из -1 извлечь нельзя.
J>Я считаю это серьезным упущением теории действительных чисел.
Спасибо за развлечение. но когда у меня будет желание посмотреть на кривляние обезьянки, я лучше схожу в зоопарк!
Сыроежка:
С>Для примера возьмем историю алгоритма copy_if
В комитете по стандартизации не хватает людских ресурсов для тщательной проверки правил. И copy_if тому наглядный пример: LWG DR 2039. Issues with std::reverse and std::copy_if.
С>На мой взгляд анналогичная ситуация имеет место и с reverse для std::map
Интересно, а чем алгоритм reverse такой особенный? Если вдруг захочется скопировать куда-то mapped значения, удовлетворяющие некоему условию, то ты тогда предложишь ещё copy_if в std::map добавить? По-моему, если тут что-то и добавлять, так это не reverse в map, а функции (или шаблоны функций) для получения итераторов, указывающих на mapped values. Использование такого добра выглядело бы либо так:
Здравствуйте, Сыроежка, Вы писали:
С>Не просветите меня, с каких это пор список не поддерживает свою организацию хранения данных?! Как раз каждый контейнерсуществует самостоятельно именно из-за того, что поддерживает собственную организацию хранения данных.
Перечитай мое сообщение еще раз, там речь шла о поддержании отсортирвоанности, а не об организации хранения.
С>Что касается всего остального, то это говорит, что вы не в состоянии мыслить концептуально. Вы относитеьс к тем людям, которые не в состоянии обощать, а постоянно решаете частные вопросы. Для программиста — это серьезный недостаток. Я вам советую исправлять его!
Вы относитесь к людям, которые не в состоянии прочитать внимательно то, что написано. Для программиста — это серьезный недостаток.
А если серьезно, в чем смысл всей этой эскапады? Реклама ресурса клиппер-борда-ру? Или что?
Здравствуйте, Masterkent, Вы писали:
M>Сыроежка:
С>>Для примера возьмем историю алгоритма copy_if
M>В комитете по стандартизации не хватает людских ресурсов для тщательной проверки правил. И copy_if тому наглядный пример: LWG DR 2039. Issues with std::reverse and std::copy_if.
С>>На мой взгляд анналогичная ситуация имеет место и с reverse для std::map
M>Интересно, а чем алгоритм reverse такой особенный? Если вдруг захочется скопировать куда-то mapped значения, удовлетворяющие некоему условию, то ты тогда предложишь ещё copy_if в std::map добавить? По-моему, если тут что-то и добавлять, так это не reverse в map, а функции (или шаблоны функций) для получения итераторов, указывающих на mapped values. Использование такого добра выглядело бы либо так:
M>
Дело в том, что алгоритм reverse сохраняет свое семантическое значение и для std::map. Что такое reverse? Это, фактически, обобщение swap для более, чем двух элементов.
Что касается copy_if, у него есть по крайней мере возможная альтернатива в виде transform с предикатом, с помощью которого можно создавать новые последовательности. У reverse даже близко нет какоой-то альтернативы, так как нужно получать сразу же два значения последовательности для обработки? одно — из начала последовательности, другое — из конца последовательнсоти. То есть нет такого алгоритма, который поставлял бы в предикат такую пару итераторов.
Здравствуйте, Masterkent, Вы писали:
M>Сыроежка:
С>>Для примера возьмем историю алгоритма copy_if
M>В комитете по стандартизации не хватает людских ресурсов для тщательной проверки правил. И copy_if тому наглядный пример: LWG DR 2039. Issues with std::reverse and std::copy_if.
С>>На мой взгляд анналогичная ситуация имеет место и с reverse для std::map
M>Интересно, а чем алгоритм reverse такой особенный? Если вдруг захочется скопировать куда-то mapped значения, удовлетворяющие некоему условию, то ты тогда предложишь ещё copy_if в std::map добавить? По-моему, если тут что-то и добавлять, так это не reverse в map, а функции (или шаблоны функций) для получения итераторов, указывающих на mapped values. Использование такого добра выглядело бы либо так:
M>
Можно еще посмотреть с другой стороны. Фактически, к std::map можно относиться как к некоторой частной разновидности более общего подхода к контейнеру наравне с std::vector. То есть первая разновидность позволяет обращаться к элементам контейнера по ключу, вторая разновидность позволяет обращаться к элементам контейнера, когда клюом является индекс элемента. Ведь в принципе числа натурального ряда также моогут быть взяты в качестве ключа. Если мы создадим контейнер std::map с ключами 0, 1, 2, и т.д., то обращение к данным, хранимым в sttd::map, не будет отличаться от обращения к данным, хранимым в std::vector, То есть концептуально имеется один тип контейнера, у которого могут быть различные ключи в том числе и чсила натурального ряда. Но получается, что в одном частном случае, коогда ключами являются числа натурального ряда, мы можем применять функцию reverse к некоторому диапазону элементов контейнера, а во втором случае мы этого делать не можем. Происходит семантический разрыв и не согласованность интерфейса..
Здравствуйте, rus blood, Вы писали:
RB>Здравствуйте, Сыроежка, Вы писали:
С>>Спасибо за развлечение. но когда у меня будет желание посмотреть на кривляние обезьянки, я лучше схожу в зоопарк!
RB>Смотри пункт 5
Вы этот пункт покажите для автора предудыщего сообщения. Надо конструктивно обсуждать вопрос, а не заниматься поясничаньем. Иначе любую тему можно превратить в профонацию! Так что будьте объективны. Иначе как окликнется, так и аукнется!
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Сыроежка, Вы писали:
С>>Не просветите меня, с каких это пор список не поддерживает свою организацию хранения данных?! Как раз каждый контейнерсуществует самостоятельно именно из-за того, что поддерживает собственную организацию хранения данных. J>Перечитай мое сообщение еще раз, там речь шла о поддержании отсортирвоанности, а не об организации хранения.
С>>Что касается всего остального, то это говорит, что вы не в состоянии мыслить концептуально. Вы относитеьс к тем людям, которые не в состоянии обощать, а постоянно решаете частные вопросы. Для программиста — это серьезный недостаток. Я вам советую исправлять его! J>Вы относитесь к людям, которые не в состоянии прочитать внимательно то, что написано. Для программиста — это серьезный недостаток.
J>А если серьезно, в чем смысл всей этой эскапады? Реклама ресурса клиппер-борда-ру? Или что?
Вы просто не понимаете, что вектор можно рассматривать как отсортированный контейнер, ключом которого является индекс элемента! Создайте std::map с ключом, равным числам натурального ряда последовательно, например, от 0 до 99, и фактически, ваш контейнер будет представлять собой вектор! Только и всего! То есть можно концептуально рассматривать вектор, как некоторый частный случай std::map (раз вы не ведете речь о физической организации, а говорите лишь об отсортированности по ключу), в котором ключем является индекс элемента!
например, рассмотрите код, чтобы было вам понятно
Фактически здест имеют место быть пары { ключ, значение }, где ключом является индекс элемента. Причем последовательность априори отсортирована по индексу элемента!
Здравствуйте, Сыроежка, Вы писали:
С>Здравствуйте, jazzer, Вы писали:
J>>А если серьезно, в чем смысл всей этой эскапады? Реклама ресурса клиппер-борда-ру? Или что?
С>Вы просто не понимаете, что вектор можно рассматривать как отсортированный контейнер, ключом которого является индекс элемента! Создайте std::map с ключом, равным числам натурального ряда последовательно, например, от 0 до 99, и фактически, ваш контейнер будет представлять собой вектор! Только и всего! То есть можно концептуально рассматривать вектор, как некоторый частный случай std::map (раз вы не ведете речь о физической организации, а говорите лишь об отсортированности по ключу), в котором ключем является индекс элемента! С>например, рассмотрите код, чтобы было вам понятно
С>
С>Фактически здест имеют место быть пары { ключ, значение }, где ключом является индекс элемента. Причем последовательность априори отсортирована по индексу элемента!
Дорогой наш мыслитель концептуально! Ваша концептуальнейшая и обобщеннейшая теория имела бы смысл в том случае, если бы ключ и значение внутри std::map являлись бы взаимно независимыми сущностями, как например это происходит для вектора (это так, даже если смотреть на это обобщенно и концептуально, т.к. индекс никак не зависит от значения которое туда захотят засунуть!).
то я могу еще понять смысл операции reverse, т.к. индексы остаются независимой сущностью и не зависят от значения которое там хранится (программист все также будет первый, директор второй, а уборщица третьей).
reverse(staff.begin(), staff.end());
Но std::map в том виде, в котором задумывался и был воплощен имеет все же другой смысл (цитата из wikipedia): "Ассоциативный массив (словарь) — абстрактный тип данных (интерфейс к хранилищу данных), позволяющий хранить пары вида «(ключ, значение)» и поддерживающий операции добавления пары, а также поиска и удаления пары по ключу". Обратите ваше внимание на тот факт, что слова ключ и значение используется вместе как единое целое, и обозначаются словом "пара". Т.е. предлагаемый Вами reverse должен переворачивать часть единого целого.
С>например, рассмотрите код, чтобы было вам понятно
// внимание код не компилируемый!!!struct student{
string sname;
string name;
};
student all_students[] = {{"Петров","Петя"},{"Иванов","Ваня"},{"Егорушкин","Жора"},{"Ссылкин","Ссылка"}};
reverse(begin(all_students), end(all_students));
// после этого, по Вашей логике, нормальным результатом будет
// Петров Ссылка
// Иванов Жора
// Егорушкин Ваня
// Ссылкин Петя
Re[12]: Разместить в обратном порядке отображаемые значения
Здравствуйте, rumit7, Вы писали:
R>Здравствуйте, Сыроежка, Вы писали:
С>>Здравствуйте, jazzer, Вы писали:
J>>>А если серьезно, в чем смысл всей этой эскапады? Реклама ресурса клиппер-борда-ру? Или что?
С>>Вы просто не понимаете, что вектор можно рассматривать как отсортированный контейнер, ключом которого является индекс элемента! Создайте std::map с ключом, равным числам натурального ряда последовательно, например, от 0 до 99, и фактически, ваш контейнер будет представлять собой вектор! Только и всего! То есть можно концептуально рассматривать вектор, как некоторый частный случай std::map (раз вы не ведете речь о физической организации, а говорите лишь об отсортированности по ключу), в котором ключем является индекс элемента! С>>например, рассмотрите код, чтобы было вам понятно
С>>
С>>Фактически здест имеют место быть пары { ключ, значение }, где ключом является индекс элемента. Причем последовательность априори отсортирована по индексу элемента!
R>Дорогой наш мыслитель концептуально! Ваша концептуальнейшая и обобщеннейшая теория имела бы смысл в том случае, если бы ключ и значение внутри std::map являлись бы взаимно независимыми сущностями, как например это происходит для вектора (это так, даже если смотреть на это обобщенно и концептуально, т.к. индекс никак не зависит от значения которое туда захотят засунуть!).
R>Например, если бы std::map создавался как-то так:
R>
R>то я могу еще понять смысл операции reverse, т.к. индексы остаются независимой сущностью и не зависят от значения которое там хранится (программист все также будет первый, директор второй, а уборщица третьей).
R>
R>reverse(staff.begin(), staff.end());
R>
R>Но std::map в том виде, в котором задумывался и был воплощен имеет все же другой смысл (цитата из wikipedia): "Ассоциативный массив (словарь) — абстрактный тип данных (интерфейс к хранилищу данных), позволяющий хранить пары вида «(ключ, значение)» и поддерживающий операции добавления пары, а также поиска и удаления пары по ключу". Обратите ваше внимание на тот факт, что слова ключ и значение используется вместе как единое целое, и обозначаются словом "пара". Т.е. предлагаемый Вами reverse должен переворачивать часть единого целого.
С>>например, рассмотрите код, чтобы было вам понятно
R>
R>// внимание код не компилируемый!!!
R>struct student{
R> string sname;
R> string name;
R>};
R>student all_students[] = {{"Петров","Петя"},{"Иванов","Ваня"},{"Егорушкин","Жора"},{"Ссылкин","Ссылка"}};
R>reverse(begin(all_students), end(all_students));
R>// после этого, по Вашей логике, нормальным результатом будет
R>// Петров Ссылка
R>// Иванов Жора
R>// Егорушкин Ваня
R>// Ссылкин Петя
R>
А ключ и значение как раз и являются независимыми. То есть что это означает? что для ззаданнного ключа может быть в любое время указано совершенно другое значение!
Но в любом случае спасибо вам за участие. Я уже всю дискуссию подытожил в своем сообщении по адресу http://clipper.borda.ru/?1-6-0-00000022-000-0-0-1326309482
Почитайте, будет вам интересно. Я не думаю, что что-то принципиально новое вы сможете мне возразить. То есть я не вижу никаких серьезных контраргументов моей постановке вопроса.
Здравствуйте, rumit7, Вы писали:
R>Здравствуйте, Сыроежка, Вы писали:
С>>Здравствуйте, jazzer, Вы писали:
J>>>А если серьезно, в чем смысл всей этой эскапады? Реклама ресурса клиппер-борда-ру? Или что?
С>>Вы просто не понимаете, что вектор можно рассматривать как отсортированный контейнер, ключом которого является индекс элемента! Создайте std::map с ключом, равным числам натурального ряда последовательно, например, от 0 до 99, и фактически, ваш контейнер будет представлять собой вектор! Только и всего! То есть можно концептуально рассматривать вектор, как некоторый частный случай std::map (раз вы не ведете речь о физической организации, а говорите лишь об отсортированности по ключу), в котором ключем является индекс элемента! С>>например, рассмотрите код, чтобы было вам понятно
С>>
С>>Фактически здест имеют место быть пары { ключ, значение }, где ключом является индекс элемента. Причем последовательность априори отсортирована по индексу элемента!
R>Дорогой наш мыслитель концептуально! Ваша концептуальнейшая и обобщеннейшая теория имела бы смысл в том случае, если бы ключ и значение внутри std::map являлись бы взаимно независимыми сущностями, как например это происходит для вектора (это так, даже если смотреть на это обобщенно и концептуально, т.к. индекс никак не зависит от значения которое туда захотят засунуть!).
R>Например, если бы std::map создавался как-то так:
R>
R>то я могу еще понять смысл операции reverse, т.к. индексы остаются независимой сущностью и не зависят от значения которое там хранится (программист все также будет первый, директор второй, а уборщица третьей).
R>
R>reverse(staff.begin(), staff.end());
R>
R>Но std::map в том виде, в котором задумывался и был воплощен имеет все же другой смысл (цитата из wikipedia): "Ассоциативный массив (словарь) — абстрактный тип данных (интерфейс к хранилищу данных), позволяющий хранить пары вида «(ключ, значение)» и поддерживающий операции добавления пары, а также поиска и удаления пары по ключу". Обратите ваше внимание на тот факт, что слова ключ и значение используется вместе как единое целое, и обозначаются словом "пара". Т.е. предлагаемый Вами reverse должен переворачивать часть единого целого.
С>>например, рассмотрите код, чтобы было вам понятно
R>
R>// внимание код не компилируемый!!!
R>struct student{
R> string sname;
R> string name;
R>};
R>student all_students[] = {{"Петров","Петя"},{"Иванов","Ваня"},{"Егорушкин","Жора"},{"Ссылкин","Ссылка"}};
R>reverse(begin(all_students), end(all_students));
R>// после этого, по Вашей логике, нормальным результатом будет
R>// Петров Ссылка
R>// Иванов Жора
R>// Егорушкин Ваня
R>// Ссылкин Петя
R>
Что касается открытия темы, то я просто тхотел выяснить, действительно не существует общерпиятой простой замены std::reverse для контейнера std::map, или я просто не тзнаю такой замены. Так как одна голова хорошо, а две лучше. Я же не обязан знать все трюки программирования, которые используются.
Как оказалось в ходе дискусии, я оказался прав, то есть нет общепринятого метода размещения значений в std::map в обратном порядке.
Это серьезое упущение стандарта С++.
> MZ>Порядок хранения элементов в std::map не определён. Обратным порядком для > MZ>неоределённого порядка будет также неопределённый порядок. Следовательно, > MZ>тебе ПРОСТО НЕ НУЖНО НИЧЕГО ДЕЛАТЬ. > > Ты что-то путаешь. Порядок на множестве ключей определен и этот порядок для
Определён порядок на ключах. И порядок итерирования. Порядок хранения -- не
определён.
Posted via RSDN NNTP Server 2.1 beta
Re[6]: Разместить в обратном порядке отображаемые значения s
> алгоритмы, которые не прикрутишь к другим ассоциативным контейнерам типа хеш-таблиц > в частности, алгоритм ТС применим к std::map и не применим к хеш-таблицам, > потому что там нет порядка ключей
Порядок ключей хеш-таблицы может быть и задан как-то.
Но это не отменяет сделанных выводов.
