STL отсортировал набор, где условия порядка могут измениться

Единственный безопасный способ сделать это с STL должно создать новый набор с измененным предикатом. Например, Вы могли сделать что-то вроде этого, когда необходимо было отсортировать набор с новым предикатом:

std::set<int> newset( oldset.begin(), oldset.end(), NewPred() );

Это является на самом деле зависящим от реализации.
Реализация STL может и обычно быть, предполагает, что предикат, используемый для сортировки, стабилен (иначе, "отсортированный" не был бы определен). По крайней мере, возможно создать допустимую реализацию STL, которая форматирует Ваш жесткий диск, когда Вы изменяете поведение экземпляра предиката.

Так, да, необходимо повторно вставить объекты в новый набор.

С другой стороны, Вы могли создать свой собственный контейнер, например, вектор + вид + lower_bound для двоичного поиска. Затем Вы могли обратиться, когда поведение предикатов изменяется.

Я соглашаюсь с другими ответами, что это собирается прервать некоторых странных и твердых отлаживать пути. Если Вы идете путем обновления, только необходимо сделать копию однажды. Создайте набор tmp с новой стратегией сортировки, добавьте каждый элемент от исходного набора до набора tmp, затем сделайте

 orig.swap(tmp);

Это подкачает внутренности наборов.

Если бы это было я, то я обернул бы это в новом классе, который обрабатывает все детали, так, чтобы можно было изменить реализации по мере необходимости. В зависимости от Ваших схем доступа и количества раз изменения порядка сортировки, ранее упомянутый вектор, вид, lowerbound решение может быть предпочтительным.

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

Multi_index однако дает Вам способ заказать ряд элементов на основе нескольких предикатов упорядочивания одновременно. Можно затем выбрать представления контейнера, которые ведут себя как станд.:: набор, заказанный предикатом, о котором Вы заботитесь в то время.

Если можно жить с незаказанным набором, то, почему Вы добавляете их в набор во-первых?

Единственный случай, о котором я могу думать, - то, где Вы просто хотите удостовериться, что список уникален, когда Вы добавляете их. Если это так, затем Вы могли использовать временный набор для защиты дополнений:

if (ts.insert (value).second) {
    // insertion took place
    realContainer.push_back (value);
}

Альтернатива, то, что в зависимости от того, как часто Вы будете изменять записи в наборе, можно, вероятно, протестировать, чтобы видеть, будет ли запись в другом месте (при помощи набора, сравнивают функциональность), и куда положение переместится, затем удаляют старую запись и повторно добавляют новую.

Как все остальные указали - незаказывание набора действительно плохо пахнет - и я также предположил бы, что его возможное получило неопределенное поведение согласно станд.

Это может вызвать потерянные записи при поиске элемента в a set оператор упорядочивания используется, это означает, что, если элемент был помещен слева от корня и теперь оператор упорядочивания говорит, что это направо затем, что элемент не будет дольше найден.

Просто развитие:

При выполнении этого кода Visual Studio C библиотеки отладки начала выдавать исключения, жалуясь, что" <" оператор был недействителен.

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

Вот простой тест для Вас:

struct comparer : public std::binary_function<int, int, bool>
{
  static enum CompareType {CT_LESS, CT_GREATER} CompareMode;
  bool operator()(int lhs, int rhs) const
  {
    if(CompareMode == CT_LESS)
    {
      return lhs < rhs;
    }
    else
    {
      return lhs > rhs;
    }
  }
};

comparer::CompareType comparer::CompareMode = comparer::CT_LESS;

typedef std::set<int, comparer> is_compare_t;

void check(const is_compare_t &is, int v)
{
  is_compare_t::const_iterator it = is.find(v);
  if(it != is.end())
  {
    std::cout << "HAS " << v << std::endl;
  }
  else
  {
    std::cout << "ERROR NO " << v << std::endl;
  }
}

int main()
{
  is_compare_t is;
  is.insert(20);
  is.insert(5);
  check(is, 5);
  comparer::CompareMode = comparer::CT_GREATER;
  check(is, 5);
  is.insert(27);
  check(is, 27);
  comparer::CompareMode = comparer::CT_LESS;
  check(is, 5);
  check(is, 27);
  return 0;
}

Так, в основном если Вы намереваетесь смочь найти элементы, Вы когда-то ввели Вас, не должен изменять предикат, используемый для вставок, и находить.

1) Вредный - нет. Результат в катастрофических отказах - нет. Худшим является действительно неотсортированный набор.

2) "Обновление" совпало бы с передобавлением так или иначе!