AkinaИ каждый соответственно при этой сортировке имеет какой-то номер (который уникален даже для случая, если ключи сортировки совпадают). Изменение ключа до начала второй сортировки не изменяет этого порядкового номера. Так вот именно этот номер - известен?
Не знаю, зависит от того, как я буду хранить отсортированные элементы. Можно хранить так, что буду знать, но это накладные расходы. В этом в общем-то и вопрос, вернее часть его.
Кстати... у нас это массив, коллекция, связный список или вообще что?
Могу хранить как хочу. До этого хранил в boost::multi_index_container с тремя соотвествующими индексами. Но профайлер показал, что в этом месте затык. Поэтому и оптимизирую. Замена на три std::vector, в первом хранятся элементы, а в двух других отсортированные индексы на первый (через std::sort), показала прирост. Сейчас думаю как бы еще заоптимизировать...
Ты себя понял? я - извини, нет...
Прохожу один раз, походу сразу строю два отсортированных вектора и меняю мой элемент, когда встретился. Итого один проход по моему вектору (но полная сортировка двух векторов). Не будет ли так быстрее для десятка элементов.
ДронЯ не понял use case: когда надо сортировать, когда изменяются элементы, сколько раз это происходит?
Каждый раз приходит изменение одного элемента из десятка, мне нужно найти новую лучшую цену из десяти с учетом изменения. (вернее не только лучшую но это уже детали).
Пока это всё похоже на два std::set<Element*> с разными функторами сравнения.
Я уже хранил имеенно так в multi_index_container, накладные расходы большие. Я подозреваю, что кэш много мажет, так как по указателю объекты разбросаны.
vic_oneМожно позицию определить по дополнительному индексу, который будет формироваться при сортировке.
Это накладные расходы, стоит ли?