Здравствуйте, _nn_, Вы писали:
__>Чем аргументираванно такое поведение ?
__>Спасибо.
Алгоритмы (sort, stable_sort) не могут использоваться со списками, потому что списки не поддерживают итераторы свободного доступа. Впрочем, для сортировкиэлементов в списках определена специальная функция sort()
Здравствуйте, sadomovalex, Вы писали:
S>Здравствуйте, _nn_, Вы писали:
__>>Чем аргументираванно такое поведение ?
__>>Спасибо.
S>
S>Алгоритмы (sort, stable_sort) не могут использоваться со списками, потому что списки не поддерживают итераторы свободного доступа. Впрочем, для сортировкиэлементов в списках определена специальная функция sort()
S>Н. Джосьютис
Я это же и написал.
Просто идея такая — вместо того чтобы пихать sort по классам, которые не могут работать с std::sort обычным.
Сделать еще одну функцию (написанно выше какую) и ее перегружать для всего где не работает std::sort обычный.
Здравствуйте, _nn_, Вы писали:
__>Просто идея такая — вместо того чтобы пихать sort по классам, которые не могут работать с std::sort обычным. __>Сделать еще одну функцию (написанно выше какую) и ее перегружать для всего где не работает std::sort обычный. __>Почему не сделать так ?
Дык какая собсно тебе разница, вызывать функцию класса или передавать контейнер в глобальную функцию?
std::sort это — изначально — разновидность быстрой сортировки контейнеров с произвольным доступом (массивы, std::vector).
std::list::sort использует алгоритм сортировки двухсвязных списков.
std::set/map/multiset/multimap вообще сортировать нельзя.
Для контейнеров с медленным произвольным доступом (по forward iterator'у) можно написать разновидность быстрой сортировки. Но вроде бы ни в одной версии STL этого не сделали.
В принципе, можно сделать функцию-диспетчера, которая различала бы тип контейнера и выполняла ту или иную сортировку.
template<class V, class A, class P>
void sort_container(std::vector<V,A>& cont, P pred)
{
std::sort(cont.begin(), cont.end(), pred);
}
template<class V, class A, class P>
void sort_container(std::list<V,A>& cont, P pred)
{
cont.sort(pred);
}
template<class C>
void sort_container(C& cont)
{
sort_container(cont, std::less<typename C::value_type>());
}
Перекуём баги на фичи!
Re[3]: Однообразность в STL
От:
Аноним
Дата:
25.08.04 12:43
Оценка:
Так ведь таким образом ты и потеряешь внешнюю, видимую пользователю однообразность, у тебя будет что-нить вроде
template<class Cont>
void Sort(Cont &);
template<class T>
void Sort(list<T> &);//допустим, вижуал 6.0 не сможет определить кто из функций лучше подходит, но это
//уже дело десятое
Здравствуйте, _nn_, Вы писали:
__>Напрашивается вопрос почему не сделать функцию sort в векторе. __>Или же почему не сделать функцию sort еще и так: __>
Ага, согласен, там еще много интересных функций которые хотелось бы так же перегрузить, например for_each. Такие разновидности я уже реализовал здесь, например kafe/algorithm.hpp (CVS версия).
__>А потом перегружать для нужных контейнеров. __>И тогда не будет проблемы выше.
Этого не делал, не было надобности.
__>Чем аргументираванно такое поведение ?
Историей наверно, да к тому же в STL много функций, которые должны работать именно с итераторами, а не с контейнерами, видимо решили базироваться на чем то одном (для общности ).
PS. Просматривая стандартный <algorithm> все время вспоминал про то, что как было бы здорово иметь нормальные ламбда функции в C++. Половину STL можно было бы выкинуть
Здравствуйте, Aera, Вы писали:
A>Можно сортировать не только контейнеры целиком, но и часть контейнера, в т.ч. и когда контейнер не является классом:
A>
A>int a[10];
A>std::sort(a, a+10);
A>
Это легко лечиться классом оболочкой, которая содержит в себе пару итераторов
Например, так:
/// Array reference.template<class ValueType>
class array_ref:
{
public:
template<int Size>
array_ref(ValueType (&X)[Size]): Begin(X), End(X+Size) {}
// здесь интерфейсы контейнера, такие как typedef ... iterator, iterator begin() и т.д. ...
...
private:
ValueType *Begin;
ValueType *End;
};
/// Creates an array reference.template<class ValueType, int Size>
array_ref<ValueType> make_array_ref(ValueType (&X)[Size])
{
return array_ref<ValueType>(X);
}
Тогда пример будет выглядеть так:
int a[10];
std_ex::sort(make_array_ref(a));
Заметь, безопаснее, так как размер массива может измениться в следующей версии программы. Пример реализации array_ref здесь.
Здравствуйте, _nn_, Вы писали:
__>Просто идея такая — вместо того чтобы пихать sort по классам, которые не могут работать с std::sort обычным.
__>Сделать еще одну функцию (написанно выше какую) и ее перегружать для всего где не работает std::sort обычный.
Короче, надо паттерн "стратегия" в шаблонном варианте применить.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, _nn_, Вы писали:
К><>
К>std::sort это — изначально — разновидность быстрой сортировки контейнеров с произвольным доступом (массивы, std::vector). К>std::list::sort использует алгоритм сортировки двухсвязных списков. К>std::set/map/multiset/multimap вообще сортировать нельзя.
К>Для контейнеров с медленным произвольным доступом (по forward iterator'у) можно написать разновидность быстрой сортировки. Но вроде бы ни в одной версии STL этого не сделали.
К>В принципе, можно сделать функцию-диспетчера, которая различала бы тип контейнера и выполняла ту или иную сортировку. К>
К>template<class V, class A, class P>
К>void sort_container(std::vector<V,A>& cont, P pred)
К>{
К> std::sort(cont.begin(), cont.end(), pred);
К>}
К>template<class V, class A, class P>
К>void sort_container(std::list<V,A>& cont, P pred)
К>{
К> cont.sort(pred);
К>}
К>template<class C>
К>void sort_container(C& cont)
К>{
К> sort_container(cont, std::less<typename C::value_type>());
К>}
К>
Можно и так, но ИМХО здесь "чисто конкретно" паттерн стратегия (policy) в шаблонном варианте надо применять.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, _nn_, Вы писали:
К><>
К>std::sort это — изначально — разновидность быстрой сортировки контейнеров с произвольным доступом (массивы, std::vector). К>std::list::sort использует алгоритм сортировки двухсвязных списков. К>std::set/map/multiset/multimap вообще сортировать нельзя.
К>Для контейнеров с медленным произвольным доступом (по forward iterator'у) можно написать разновидность быстрой сортировки. Но вроде бы ни в одной версии STL этого не сделали.
К>В принципе, можно сделать функцию-диспетчера, которая различала бы тип контейнера и выполняла ту или иную сортировку.
А почему в STL это не предусмотрели ?
Тогда можно было бы использовать одну функцию для всего.
Можно будет писать такое :
template<typename TContainer>
class C
{
TContainer c;
public:
void sort()
{
std::sort_container(c);
}
};
Здравствуйте, sergey_shandar, Вы писали:
_>Здравствуйте, Aera, Вы писали:
_>Это легко лечиться классом оболочкой, которая содержит в себе пару итераторов
_>Например, так: _>
_>/// Array reference.
_>template<class ValueType>
_>class array_ref:
_>
Здравствуйте, _nn_, Вы писали:
К>>В принципе, можно сделать функцию-диспетчера, которая различала бы тип контейнера и выполняла ту или иную сортировку.
__>А почему в STL это не предусмотрели ? __>Тогда можно было бы использовать одну функцию для всего.
Потому что сортировка списка меняет порядок обхода, не меняя сами элементы. А сортировка массива — обменивает значения.
Криворукий эскиз быстрой сортировки над forward-итерируемым массивом. Заметьте, даже не над bidirectional.
template<class It, class Pred>
std::pair<It,size_t> dummy_partition(It begin, It end, Pred pred)
{
if(begin == end) return std::make_pair(begin,0);
It splitter = begin;
It it = splitter; ++it;
// invariant: [begin,splitter) < [splitter] < (splitter,it)
size_t d = 0; // == distance(begin,splitter)while(it != end)
{
if(!pred(*splitter, *it)) // *splitter >= *it
{
swap(*splitter,*it);
++splitter; ++d;
}
++it;
}
return std::make_pair(splitter,d);
}
template<class It, class Pred>
void dummy_sort_imp(It begin, It end, size_t size, Pred pred)
{
while(size > 1)
{
// разбиваем интервал на два, с центральным элементом
std::pair<It,size_t> part = dummy_partition(begin,end,pred);
It end1 = part.first;
It begin2 = end1; ++begin2;
size_t size1 = part.second;
size_t size2 = size-size1-1;
// рекурсивно спускаемся в меньший из интервалов (оставляя больший для следующей итерации)if(size1*2 <= size)
{
dummy_sort(begin, end1, size1, pred);
begin = begin2;
size = size2;
}
else
{
dummy_sort(begin2, end, size2, pred);
end = end1;
size = size1;
}
}
}
template<class It, class Pred>
void dummy_sort(It begin, It end, Pred pred)
{
// вычисляем размер интервала единожды (требуется O(N) инкрементов итератора)
dummy_sort_imp(begin, end, std::distance(begin,end), pred);
}
что есть случаи когда нельзя их использовать) и STL не собираюсь менять, но моему личному опыту, просто надоедает писать X.begin(), X.end() (а в основном именно такая последовательность встречаеться в коде), поэтому предлагаю пользоваться готовыми оболочками.
Здравствуйте, sergey_shandar, Вы писали:
_>Здравствуйте, Aera, Вы писали:
A>>А какие вспомогательные классы нужны для следующего кода:
_>Можно так, используя sequence и make_sequence (см. там же, array_ref наследуеться от sequence): _>
_>std::vector<int> vector(2000);
_>// заполняем
_>std_ex::sort(vector);
_>int prev_size=vector.size();
_>for(int index=0; index<200; ++index)
_> vector.push_back(some_value());
_>std_ex::sort(make_sequence(vector.begin()+prev_size, vector.end())); // использовать оболочку sequence
_>std_ex::inplace_merge(vector, vector.begin()+prev_size); // здесь middle указываеться в конце.
_>
_>Не утверждаю что всегда надо передавать контейнеры везде где не попадя (я уже говорил
что есть случаи когда нельзя их использовать) и STL не собираюсь менять, но моему личному опыту, просто надоедает писать X.begin(), X.end() (а в основном именно такая последовательность встречаеться в коде), поэтому предлагаю пользоваться готовыми оболочками.
Можно сделать проще, если это идет имено в таком порядке и рядом :
что есть случаи когда нельзя их использовать) и STL не собираюсь менять, но моему личному опыту, просто надоедает писать X.begin(), X.end() (а в основном именно такая последовательность встречаеться в коде), поэтому предлагаю пользоваться готовыми оболочками.
__>Можно сделать проще, если это идет имено в таком порядке и рядом : __>
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, _nn_, Вы писали:
К>>>В принципе, можно сделать функцию-диспетчера, которая различала бы тип контейнера и выполняла ту или иную сортировку.
__>>А почему в STL это не предусмотрели ? __>>Тогда можно было бы использовать одну функцию для всего.
К>Потому что сортировка списка меняет порядок обхода, не меняя сами элементы. А сортировка массива — обменивает значения.
К>Криворукий эскиз быстрой сортировки над forward-итерируемым массивом. Заметьте, даже не над bidirectional.
Это не аргумент против добавления такой удобной вещи
Здравствуйте, sergey_shandar, Вы писали:
_>Здравствуйте, _nn_, Вы писали:
_>>>Не утверждаю что всегда надо передавать контейнеры везде где не попадя (я уже говорил
что есть случаи когда нельзя их использовать) и STL не собираюсь менять, но моему личному опыту, просто надоедает писать X.begin(), X.end() (а в основном именно такая последовательность встречаеться в коде), поэтому предлагаю пользоваться готовыми оболочками.
__>>Можно сделать проще, если это идет имено в таком порядке и рядом : __>>
_>Согласен, но у меня просто аллергия на дефайны .
Почему ?
Мне кажется что в данном случае гараздо проще использовать макрос чем определять десяток функций, к которым может еще что-нибудь добавиться, вдобавок этот макрос можно пихать везде, а не к только определенным функциям.
Здравствуйте, denisku, Вы писали:
D>Здравствуйте, _nn_, Вы писали:
__>>Просто идея такая — вместо того чтобы пихать sort по классам, которые не могут работать с std::sort обычным. __>>Сделать еще одну функцию (написанно выше какую) и ее перегружать для всего где не работает std::sort обычный. __>>Почему не сделать так ? D>Дык какая собсно тебе разница, вызывать функцию класса или передавать контейнер в глобальную функцию?
Разница в том что я смогу делать так : http://rsdn.ru/Forum/Message.aspx?mid=779712&only=1
Здравствуйте, _nn_, Вы писали:
_>>Согласен, но у меня просто аллергия на дефайны . __>Почему ?
Не знаю, появилась после поиска интересных ошибок... Не хотелось бы это говорить (думаю все эти дыры в макросах ты уже сам знаеш), ОБЯЗАТЕЛЬНО найдеться такой человек, который напишет что то вроде:
__>Мне кажется что в данном случае гараздо проще использовать макрос чем определять десяток функций, к которым может еще что-нибудь добавиться, вдобавок этот макрос можно пихать везде, а не к только определенным функциям.
Кому как, для меня важнее надежность и понятность кода .
Здравствуйте, sergey_shandar, Вы писали:
_>Здравствуйте, _nn_, Вы писали:
_>>>Согласен, но у меня просто аллергия на дефайны . __>>Почему ?
_>Не знаю, появилась после поиска интересных ошибок... Не хотелось бы это говорить (думаю все эти дыры в макросах ты уже сам знаеш), ОБЯЗАТЕЛЬНО найдеться такой человек, который напишет что то вроде: _>
__>>Мне кажется что в данном случае гараздо проще использовать макрос чем определять десяток функций, к которым может еще что-нибудь добавиться, вдобавок этот макрос можно пихать везде, а не к только определенным функциям.
_>Кому как, для меня важнее надежность и понятность кода .
Если использовать оккуратно проблем не будет.
Сколько людей используют BEGIN_MSG_MAP(BEGIN_MESSAGE_MAP) и не сталкиваются с трудностями
А насчет begin_end(flag?x:y) то это просто макрос исправить
Здравствуйте, _nn_, Вы писали:
К>>Потому что сортировка списка меняет порядок обхода, не меняя сами элементы. А сортировка массива — обменивает значения.
К>>Криворукий эскиз быстрой сортировки над forward-итерируемым массивом. Заметьте, даже не над bidirectional.
__>Это не аргумент против добавления такой удобной вещи
Что не аргумент? Криворукость? Или то, что сортировка списка не меняет содержимое элементов, а быстрая сортировка меняет?
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, _nn_, Вы писали:
К>>>Потому что сортировка списка меняет порядок обхода, не меняя сами элементы. А сортировка массива — обменивает значения.
К>>>Криворукий эскиз быстрой сортировки над forward-итерируемым массивом. Заметьте, даже не над bidirectional.
__>>Это не аргумент против добавления такой удобной вещи
К>Что не аргумент? Криворукость? Или то, что сортировка списка не меняет содержимое элементов, а быстрая сортировка меняет?
Я имел ввиду что можно сделать это.
К>Ну так чтож. Бери мой код, отладь и пользуйся.
Попробую
Здравствуйте, Кодт, Вы писали:
К>Криворукий эскиз быстрой сортировки над forward-итерируемым массивом. Заметьте, даже не над bidirectional. К>
...
К> swap(*splitter,*it);
...
Тогда лучше здесь вместо std::swap использовать std::iter_swap(splitter, it), так как std::iter_swap может быть специализирован для std::list<T>::iterator.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, _nn_, Вы писали:
К><>
К>std::sort это — изначально — разновидность быстрой сортировки контейнеров с произвольным доступом (массивы, std::vector). К>std::list::sort использует алгоритм сортировки двухсвязных списков. К>std::set/map/multiset/multimap вообще сортировать нельзя.
К>Для контейнеров с медленным произвольным доступом (по forward iterator'у) можно написать разновидность быстрой сортировки. Но вроде бы ни в одной версии STL этого не сделали.
К>В принципе, можно сделать функцию-диспетчера, которая различала бы тип контейнера и выполняла ту или иную сортировку. К>
К>template<class V, class A, class P>
К>void sort_container(std::vector<V,A>& cont, P pred)
К>{
К> std::sort(cont.begin(), cont.end(), pred);
К>}
К>template<class V, class A, class P>
К>void sort_container(std::list<V,A>& cont, P pred)
К>{
К> cont.sort(pred);
К>}
К>template<class C>
К>void sort_container(C& cont)
К>{
К> sort_container(cont, std::less<typename C::value_type>());
К>}
К>
У меня вопрос в таком случае. Расскажите, пожалуйста, почему std::multimap нельзя сортировать, ведь алгоритм сортировки применим ко всем контейнерам.
И подскажите, плизз, как обойти эту проблему: у меня задание вывести данные из multimap, упорядоченные по определенному критерию (не ключ).
Заранее благодарна.
Здравствуйте, Olivia, Вы писали:
O>У меня вопрос в таком случае. Расскажите, пожалуйста, почему std::multimap нельзя сортировать, ведь алгоритм сортировки применим ко всем контейнерам.
Не ко всем. STL выделяет последовательности (vector, deque, list) и ассоциативные контейнеры (set, map, multiset, multimap).
Элементы ассоциативных контейнеров уже упорядочены по ключу. Поэтому дополнительная сортировка к ним неприменима.
O>И подскажите, плизз, как обойти эту проблему: у меня задание вывести данные из multimap, упорядоченные по определенному критерию (не ключ).
Есть несколько вариантов:
1) изначально хранить в структуре, поддерживающей несколько порядков в контейнере — bimap, boost::multi_index...
2) сделать "слепок" контейнера и отсортировать. Вместо копирования значений можно брать указатели/итераторы исходного контейнера.
Большое спасибо за ответ.
К>Есть несколько вариантов: К>1) изначально хранить в структуре, поддерживающей несколько порядков в контейнере — bimap, boost::multi_index... К>2) сделать "слепок" контейнера и отсортировать. Вместо копирования значений можно брать указатели/итераторы исходного контейнера.
В первом случае, могли бы наглядно показать как это делается
вот мой класс
class Temp
{
public:
char s[50];
int age;
Temp();
Temp(const Temp &T);
Temp(char t_s[50],int t_age);
~Temp();
};
Как тогда будет выглядеть сама функция сортировки, она же там требует три параметра.
Во втором случае. Я не знакома с понятием слепок контейнера, где бы мне можно было почитать об этом. И я так понимаю во втором случае сортировка будет производиться по итераторам?
Я просто не могу понять сам механизм, ведь данные в ассоциативных контейнерах хранятся в упорядоченном виде по ключу, каким образом они будут упорядычиваться, если применить один из предложенных вариантов.
И какой из вариантов наиболее эффективен?
Здравствуйте, Olivia, Вы писали:
O>Здравствуйте, Кодт, Вы писали:
O>Большое спасибо за ответ.
К>>Есть несколько вариантов: К>>1) изначально хранить в структуре, поддерживающей несколько порядков в контейнере — bimap, boost::multi_index... К>>2) сделать "слепок" контейнера и отсортировать. Вместо копирования значений можно брать указатели/итераторы исходного контейнера.
O>В первом случае, могли бы наглядно показать как это делается O>вот мой класс
O>Как тогда будет выглядеть сама функция сортировки, она же там требует три параметра.
Вот здесь http://www.boost.org/libs/multi_index/doc/tutorial.html
рассказывается о том, как создавать многоиндексные контейнеры.
Кстати, пример там практически один в один с твоим
O>Во втором случае. Я не знакома с понятием слепок контейнера, где бы мне можно было почитать об этом. И я так понимаю во втором случае сортировка будет производиться по итераторам? O>Я просто не могу понять сам механизм, ведь данные в ассоциативных контейнерах хранятся в упорядоченном виде по ключу, каким образом они будут упорядычиваться, если применить один из предложенных вариантов.
Слепок в данном случае — это коллекция (вектор/список/множество) элементов, содержащихсч в исходном контейнере.
Если копировать элементы дорого, то можно и нужно формировать коллекцию посредников — указателей, итераторов и т.п.
Имхо, наиболее эффективным по скорости будет вектор указателей — единожды выделяется блок памяти, за линейное время туда копируются указатели на элементы, и наконец, выполняем сортировку.
Можно ли как-нибудь хранить, например, мой мультимэп в другом контейнере, т.е. как бы вложенная одна в другую структура получается, например — vector<m> v. Возможен ли такой вариант, это будет очень просто я думаю, только надо придумать как это реализовать...
Здравствуйте, Аноним, Вы писали:
А>Спасибо за ответ, но из ваших примеров я не могу применить ничего к своему, потому что у меня объявлен multimap и в нем уже хранятся данные:
Нужно лишь немножко подумать, а не копировать в лоб.
Что такое мультимап? Это реляционная таблица с неуникальным ключом.
Что значит дополнительная сортировка? Это добавление в таблицу ещё одной колонки с другим неуникальным ключом.
Поэтому если задача выборки в разных порядках встаёт часто — заводим структуру из 3 полей:
— первичный ключ (ключ мультимапа)
— альтернативный ключ
— данные (класс Temp)
В роли альтернативного ключа могут выступать сами данные или их члены.
Для единовременной сортировки — делаем слепок. Замени в моём коде set на multimap, и учти, что элемент мультимапа — это std::pair<const key_type,value_type>. То есть для доступа к значениям, нужно делать не (*it), а (it->second).
Приветик, Кодт.
Большое спасибо за ответ, но у меня еще теперь такой вопрос ты под чем писал этот код, потому что у меня какая-то фигня получается, честно... (может у меня руки кривые, что скорее всего ) ты можешь мне на почту прислать написанную с твоим кодом элементарную програмку, чтобы я ее проверила под VC++ 6.0
Мой e-mail: olivia84@mail.ru
Hello, Кодт!
You wrote on Wed, 08 Dec 2004 11:59:31 GMT:
К> Что такое мультимап? Это реляционная таблица с неуникальным ключом. К> Что значит дополнительная сортировка? Это добавление в таблицу ещё одной К> колонки с другим неуникальным ключом. Поэтому если задача выборки в К> разных порядках встаёт часто — заводим структуру из 3 полей: — первичный К> ключ (ключ мультимапа) — альтернативный ключ К> — данные (класс Temp) К> В роли альтернативного ключа могут выступать сами данные или их члены.
К> Для единовременной сортировки — делаем слепок. Замени в моём коде set на К> multimap, и учти, что элемент мультимапа — это std::pair<const К> key_type,value_type>. То есть для доступа к значениям, нужно делать не К> (*it), а (it->second).
Если нельзя использовать стороние библиотеки или компилятор совсем дохлый, то по другому не сделаешь. Но если можно взять boost, то multi_index это очень сильное уменьшение головных болей как писателю так и читателю. Я сам был вынужден делать вышеописанным способом, так как небыло тогда еще этого boost::multi_index в релизе, но доки уже были и я там встретил решение вышеописанной задачи. Так что лучше, если можно, не париться, а сразу взять multi_index и забыть о проблемах.
With best regards, Konstantin Litvinenko. E-mail: darkangel@malva.ua
У меня возникли проблемы с кодом, который вы мне прислали на e-mail. Там в коде я пыталась поправить ключ multimap'а int на char*, ничего не получилось... Я написала вам письмо с просьбой помочь, но, вероятно, вы его не получили или просто не прочитали... Так вот просьба была следующей в той проге, которую вы пересылали мне на мыло, я пробовала заменить ключ int на char* ввозникли некоторые проблемы с перегрузкой оператора () и << Пожалуйста, можете проверить исправленный код у себя и поправить, и прислать мне.
Здравствуйте, Olivia, Вы писали:
O>Здравствуйте, Кодт, Вы писали:
O>У меня возникли проблемы с кодом, который вы мне прислали на e-mail. Там в коде я пыталась поправить ключ multimap'а int на char*, ничего не получилось... Я написала вам письмо с просьбой помочь, но, вероятно, вы его не получили или просто не прочитали... Так вот просьба была следующей в той проге, которую вы пересылали мне на мыло, я пробовала заменить ключ int на char* ввозникли некоторые проблемы с перегрузкой оператора () и << Пожалуйста, можете проверить исправленный код у себя и поправить, и прислать мне.
Оливия, не могли бы вы детально рассказать, что у вас за проблема. Я так понял в multimap'е храняться объекты класса Temp? Что является ключом? По каким критериям надо сортировать?
Рассказав всё это мне, я может вам помогу.
... << RSDN@Home 1.1.4 beta 3 rev. 240>>
"Man feed machine
Machine feed man"
Peter Gabriel — OVO — The Tower That Ate People
Здравствуйте, Olivia, Вы писали:
O>У меня возникли проблемы с кодом, который вы мне прислали на e-mail. Там в коде я пыталась поправить ключ multimap'а int на char*, ничего не получилось... Я написала вам письмо с просьбой помочь, но, вероятно, вы его не получили или просто не прочитали... Так вот просьба была следующей в той проге, которую вы пересылали мне на мыло, я пробовала заменить ключ int на char* ввозникли некоторые проблемы с перегрузкой оператора () и << Пожалуйста, можете проверить исправленный код у себя и поправить, и прислать мне.
Вообще говоря, это классические грабли.
1) Строковые литералы имеют тип const char* (для совместимости с Си он иногда приводится к char*, но это жестоко)
2) Время жизни строк-ключей? Если это не литералы, то придётся вручную их прибивать
3) Операция сравнения? По умолчанию, map/multimap/set/multiset сравнивает значения ключей. А у тебя значения — это не содержимое строк, а указатели на них. Две одинаковых строки по разным адресам — и ку-ку.
Что делать?
Быстрый ответ: использовать объекты-строки. Например, std::string.
Я думаю, твои проблемы это решит.