Странное поведение set::erase при изменении компаратора

@georg21a · Регистрация: 09.07.2017

Студворк — интернет-сервис помощи студентам

Случайно столкнулся со странным поведением erase контейнера set. Вот такой код:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
int inverse = 0;
 
struct cmp {
    bool operator()(const int& a, const int& b) const {
        if (inverse){return a < b;}
        else{return a > b;}
    }
};
 
set<int, cmp> T;
 
 
int main()
{
    T.insert(1);
    T.insert(2);
 
    inverse = 1;
 
    T.erase(2);
    cout <<"T.size = " << T.size() << "; T=";
    for(auto tt: T){cout << tt << " ";}
    cout << "\n";
 
    T.erase(1);
    cout <<"T.size = " << T.size() << "; T=";
    for(auto tt: T){cout << tt << " ";}
    cout << "\n";
    return 0;
}

Даёт на выходе:
T.size = 2; T=2 1
T.size = 0; T=

Т.е. при попытке удалить 2 не удаляется ничего, а при попытке удалить 1 удаляются оба значения.
Почему не удаляет двойку, я еще могу понять. Он её просто не находит, т.к. выполняет двоичный поиск, а порядок значений поменялся.
Но почему при команде удалить единицу удаляет двойку тоже?

P.S. Если закомментировать строку inverse=1, всё работает нормально.

Алексей1153 · 17.07.2022, 22:06

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

а у тебя во время вставки a > b, а во время удаления вдруг a < b

@georg21a · 17.07.2022, 22:30 **[ТС]**

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

Т.е. хотелось бы получить конкретный ответ, на уровне "глубинных процессов", почему при изменении компаратора наблюдается именно такое поведение.

Алексей1153 · 17.07.2022, 22:48

georg21a, при смене поведения компаратора необходимо очистить контейнер и перенабить заново, чтобы сортировка и поиск осуществлялись одинаково

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
#include <set>
#include <iostream>
 
int inverse = 0;
 
struct cmp {
    bool operator()(const int& a, const int& b) const {
        if (inverse){return a < b;}
        else{return a > b;}
    }
};
 
std::set<int, cmp> T;
 
int main()
{
    T.insert(1);
    T.insert(2);
    T.erase(2);
    std::cout <<"T.size = " << T.size() << "; T=";
    for(auto tt: T){std::cout << tt << " ";}
    std::cout << "\n";
    
    T.clear();
    inverse = 1;
 
    T.insert(1);
    T.insert(2);
    T.erase(1);
    std::cout <<"T.size = " << T.size() << "; T=";
    for(auto tt: T){std::cout << tt << " ";}
    std::cout << "\n";
    return 0;
}

Croessmah · 17.07.2022, 22:50

Сообщение от georg21a

и в которой компаратор зависит от параметра

Сообщение от georg21a

при изменении компаратора наблюдается именно такое поведение.

"Компаратор зависит от параметра" и "компаратор изменяет свое поведение" - это разные ситуации.
Вы просто изменяете поведение компаратора.

Сообщение от georg21a

Т.е. хотелось бы получить конкретный ответ, на уровне "глубинных процессов", почему при изменении компаратора наблюдается именно такое поведение.

Загляните в исходники std::set в используемом компиляторе.

Сообщение от georg21a

Я хочу понять причину такого поведения, чтобы контролировать процесс.

Это undefined behaviour, нельзя это контролировать. Разве что вы привяжитесь к конкретной версии конкретного компилятора с определенными параметрами сборки.

@georg21a · 17.07.2022, 23:30 **[ТС]**

Я не понимаю. Контейнер не знает о том, что компаратор изменился. Контейнеру приходит команда удалить 1. Он начинает искать 1 с изменённым компаратором. Ищет методом двоичного поиска, но поскольку с новым компаратором порядок элементов нарушен, может и не найти. Если повезло и находит - ок, удаляет. Если не находит - значит не удаляет.

Но как он при команде "удалить 1" удаляет заодно и 2 ? Мне хочется в принципе понять, как такое может быть.

Т.е. вопрос не "как исправить", а "почему так происходит".

Croessmah · 18.07.2022, 00:48

Сообщение от georg21a

почему так происходит

Для начала, UB может проявляться как угодно.
Но давайте посмотрим, что делает erase - удаляет элемент с эквивалентным ключом (не равным, а эквивалентным!).
Эквивалентный ключ - это ключ, для которого !cmp(a, b) && !cmp(b, a) даст true.

Допустим, деверо строится так, что в левую ветку складываются все элементы для которых компаратор (cmp(новое_значение, узел)) вернул false, а в правую - true.
Элементы в правой ветке обзовем "меньшими", в левой - "не меньшими".

Тогда берем ваш компаратор и строим дерево с ним (inverse == 0, тут напутал, у вас знаки наоборот, но сути не меняет):

Code
1
2
3
   1
  / \
 2

чисто гипотетически, поиск может быть устроен так:
Находим первый эквивалентный элемент.
Мы знаем, что в правой ветке дерева элементы "меньше" текущего, т.е. эквивалентных там нет.
Эквивалентные ключи могут быть только в левой ветке.
Как найти первый не эквивалентный ключ в левой ветке?
Можно применить полную формулу, но зачем? У нас контейнер сформирован определенным образом.
И достаточно найти первый у которого cmp(искомое, узел) даст true, ну или закончится контейнер.

Давайте теперь выполним поиск по этому контейнеру с вашим компаратором при inverse == 0, т.е. с тем, с которым формировался контейнер (получившееся дерево есть выше).

Начинаем смотреть дерево и сразу находим эквивалентный элемент (1).
Ок. Пойдем в левую ветку искать не эквивалентный ключ cmp(1, 2), т.е. (1 < 2 == true), - нашли. Супер! Удаляем все узлы от (1) до (2).

Теперь выполним поиск по тому же самому контейнеру с вашим компаратором при inverse == 1.
Начинаем смотреть дерево и сразу находим эквивалентный элемент (1).
Ок. Пойдем в левую ветку искать не эквивалентный ключ cmp(1, 2), т.е. (1 > 2 == false) - о, ключ эквивалентный предыдущему. Дальше контейнер закончился, удаляем (1) и (2).

Новые блоги и статьи Все статьи Все блоги /
Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .	Архитектура слоя интернета для сервера-слоя. Hrethgir 11.04.2026 В продолжение https:/ / www. cyberforum. ru/ blogs/ 223907/ 10860. html Знаешь что я подумал? Раз мы все источники пишем в голове ветки, то ничего не мешает добавить в голову такой источник, который сам. . .	Подстановка значения реквизита справочника в табличную часть документа Maks 10.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: при выборе сотрудника (справочник Сотрудники) в ТЧ документа. . .	Очистка реквизитов документа при копировании Maks 09.04.2026 Алгоритм из решения ниже применим как для типовых, так и для нетиповых документов на самых различных конфигурациях. Задача: при копировании документа очищать определенные реквизиты и табличную. . .
модель ЗдравоСохранения 8. Подготовка к разному выполнению заданий anaschu 08.04.2026 https:/ / github. com/ shumilovas/ med2. git main ветка * содержимое блока дэлэй из старой модели теперь внутри зайца новой модели 8ATzM_2aurI	Блокировка документа от изменений, если он открыт у другого пользователя Maks 08.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в конфигурации КА2. Задача: запретить редактирование документа, если он открыт у другого пользователя. / / . . .	Система безопасности+живучести для сервера-слоя интернета (сети). Двойная привязка. Hrethgir 08.04.2026 Далее были размышления о системе безопасности. Сообщения с наклонным текстом - мои. А как нам будет можно проверить, что ссылка наша, а не подделана хулиганами, которая выбросит на другую ветку и. . .	Модель ЗдрввоСохранения 7: больше работников, больше ресурсов. anaschu 08.04.2026 работников и заданий может быть сколько угодно, но настроено всё так, что используется пока что только 20% kYBz3eJf3jQ

Алексей1153 фрилансер 6467 / 5682 / 1131 Регистрация: 11.10.2019 Сообщений: 15,146
	17.07.2022, 22:06
	georg21a, компаратор не должен меняться, он должен всегда работать одинаково - и во время вставки, и во время поиска, и во время удаления а у тебя во время вставки `a > b`, а во время удаления вдруг `a < b` 0

@georg21a 2 / 2 / 1 Регистрация: 09.07.2017 Сообщений: 19
	17.07.2022, 22:30 [ТС]
	Алексей, так в этом и суть эксперимента. Вопрос возник из реальной программы, которую мне надо написать, и в которой компаратор зависит от параметра. Я хочу понять причину такого поведения, чтобы контролировать процесс. Т.е. хотелось бы получить конкретный ответ, на уровне "глубинных процессов", почему при изменении компаратора наблюдается именно такое поведение. 0

@georg21a 2 / 2 / 1 Регистрация: 09.07.2017 Сообщений: 19
	17.07.2022, 23:30 [ТС]
	Я не понимаю. Контейнер не знает о том, что компаратор изменился. Контейнеру приходит команда удалить 1. Он начинает искать 1 с изменённым компаратором. Ищет методом двоичного поиска, но поскольку с новым компаратором порядок элементов нарушен, может и не найти. Если повезло и находит - ок, удаляет. Если не находит - значит не удаляет. Но как он при команде "удалить 1" удаляет заодно и 2 ? Мне хочется в принципе понять, как такое может быть. Т.е. вопрос не "как исправить", а "почему так происходит". 0