угу, STL все сделает

Анатолий Широков писал:Конструкция вида v.swap(vector<тип>()) не верна, поскольку swap принимает в качестве параметра lvalue (vector &), тогда как vector<int>() - rvalue. Код по очистке вектора должен выглядеть следующим образом:

торопыжка
1. v.swap(vector<тип>()) - эта конструкция инвариантна, т.е. vector<тип>().swap(v); - тоже самое.
2. В lvalue допустимы временные объекты, и я это сплошь и рядом использую в алгоритмах, а так как в любом случае для swap приходится использовать временный объект, то мне фиолетово, с какой стороны его поместить. Спорить не надо, твое заявление меня настолько поразило (ну мало ли, вдруг я действительно ошибся), что я тут же накатал это все, скомпилил и проверил - все гут. :)
3. Ты решил задачу, не посмотрев условие. Прочти еще раз условие и ответь - для чего я взял std::set ??? (кстати, непонятно, зачем Lepsik взял std::map)

кстати, создай массив на 1000000 элементов и проверь быстродействие своего и моего варианта. Будешь удивлен, особенно, если возьмешь STL от boost. :)

Konst писал:Очевидно, Lepsik взял map, чтобы эквивалентные значения объектов выкидывались, а не эквивалентные упорядочивались по возрастанию на этапе вставки. Помимо некоторого "извращения" этот подход содержит потенциальный подвох. Равенство по a == b и эквивалентность, понимаемая в map как !(a < b) && !(b < a) в ряде случаев не одно и то же, хотя для чисел все будет ок.
все ясно, но map - это map, я использую set именно для того, что ты описал.
а насчет эквивалентности, то для описанной задачи: сортировка (<) и выкинуть лишнее (==) выполнение этих условий подразумевается.

2 Анатолий Широков
наверно ты прав, насчет, lvalue.
мой компилятор позволяет такие фокусы для агрегированных типов (классы, структуры).

насчет твоего способа, вот почему я не взял unique:


двойной вложенный проход по всему массиву, очевидно, что время работы unique пропорционально квадрату количества элементов массива, что не есть гут, в то время как set использует деревца, и одновременно и сортирует и выкидывает повторы. По количеству операций set приближается к quicksort. Да, в set мы имеем операции с памятью (весьма небыстрые), что тоже не есть гут. Однако, если подобную задачу выполнять постоянно с одним и тем же экземпляром set, и использовать какой-нить вменяемый аллокатор, то выделение памяти произойдет (в большинстве случаев) одноразово, а все остальные разы set сработает быстро, "одним махом" и отсортировав и выкинув лишнее.

2 Андрей Шевченко

Интересно, а зачем нужно делать этот swap ? В чем фишка?
Это стандартный способ очистки контейнеров - swap с пустым, эти контейнеры меняются хранимыми объектами в памяти, над которыми производят операции.

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

Кстати, и не совсем понятно на счет "insert_iterator(s)" - например у меня такая конструкция не работает (STL от VC7.1).


не факт, что компилятор не создаст лишний временный объект при компилировании return этой ф-ции, поэтому юзаю непосредственно insert_iterator. Просто я там описался (причем дважды), строчил быстро навскидку прямо в форум :), описки, разумеется можно было и исправить, тогда все заработало бы.

да, если можно подробнее, на чем именно произошла экономия вдвое?

2 Lepsik

В одном из недавних проектов делали аналогично, только без XML.
Хранили в базе метаданные, описывающие все и вся. Этих описательных структур-то всего около 3-х десятков, так что обошлись без тяжеловесного XML. :)