Почему const_casting heap.top() из priority_queue имеет неопределенное поведение?

tl;dr: Может быть; возможно, нет.

Безопасность на уровне языка

Как и набор, priority_queue отвечает за упорядочение своих элементов. Любая модификация элемента потенциально «нарушит» порядок, поэтому единственный безопасный способ сделать это — использовать собственные методы мутации контейнера. (На самом деле ни один из них не предоставляет такой возможности.) Непосредственное изменение элементов опасно. Чтобы обеспечить это, эти контейнеры предоставляют только const доступ к вашим элементам.

Теперь на уровне языка объекты не будут иметь статического типа const T; скорее всего они просто Ts. Таким образом, их изменение (после const_cast для обмана системы типов) не имеет неопределенного поведения в этом смысле.

Безопасность на уровне библиотеки

Однако вы потенциально нарушаете условие использования контейнера. Правила для priority_queue на самом деле никогда не говорят об этом, но поскольку его изменяющие операции определяются в терминах таких функций, как push_heap и pop_heap, использование таких операций нарушит предварительные условия этих функций, если порядок контейнера больше не удовлетворяет после вашей прямой мутации.

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

Итак, где мы находимся?

Вопрос: вы нарушили порядок? Каково состояние элемента после перемещения из него, и удовлетворяется ли порядок, если объект в этом состоянии находится в начале очереди?

• В исходном примере используется shared_ptrs, и из документации мы знаем, что перемещенный shared_ptr безопасно превращается в нулевой указатель.

• Порядок priority_queue по умолчанию определяется std::less, что дает строгий общий порядок необработанных указателей; std::less на shared_ptr фактически вызовет его базовый случай operator<, но , который, в свою очередь, определен для вызова std::less на его эквивалент необработанного указателя .

• К сожалению, это не означает, что нулевой shared_ptr упорядочивается «первым»: , хотя порядок указателей std::less является строгим и полным, где нулевые указатели приземляются в этом порядке, не указано .

• Таким образом, не указано, нарушит ли ваша мутация порядок, и, следовательно, не указано, будет ли ваш pop() иметь неопределенное поведение.

(Пример MCVE с int безопасен, потому что std::move на int нечего делать: он просто скопирует int. Таким образом, порядок остается неизменным.)

Заключение

Я бы согласился с тем, что предположительно было вашим мотивом, что, к сожалению, pop() не возвращает вам выскочившую вещь, которую вы могли бы тогда move из. Подобные ограничения с наборами и картами — вот почему теперь у нас есть функции сплайсинга узлов для этих контейнеров. Для Priority_queue такого нет, это просто оболочка вокруг другого контейнера, такого как вектор. Если вам нужен более детальный контроль, вы можете заменить его собственным, который имеет нужные вам функции.

В любом случае, ради приращения shared_ptr (как в вашем исходном коде), я бы, вероятно, просто взял копию, если у вас нет действительно экстремальных требований к производительности. Таким образом, вы знаете, что все будет четко определено.

Конечно, ради int копии (как в вашем MCVE) std::move совершенно бессмысленно (нет косвенных ресурсов, которые можно было бы украсть!) и вы все равно делаете копию, так что вопрос довольно спорный и все, что вам нужно' мы сделали, чтобы создать более сложный код без всякой причины.

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