Почему определение деструктора удаляет неявно определенный оператор присваивания перемещения?

Какова причина выбора стандартным комитетом C ++ удаления неявно определенного оператора назначения перемещения, когда определяется настраиваемый деструктор?

6

Решение

Из статьи 17 «Эффективное современное С ++» Скотта Мейера (при условии, что вы Правило трех):

Следствием правила три является то, что наличие деструктора, объявленного пользователем, указывает на то, что простое членное копирование вряд ли подходит для операций копирования в классе. Это, в свою очередь, предполагает, что если класс объявляет деструктор, операции копирования, вероятно, не должны генерироваться автоматически, потому что они не будут делать правильные вещи. […]

Однако обоснование правила три остается в силе и в сочетании с наблюдением, что объявление операции копирования исключает неявную генерацию операций перемещения, мотивирует тот факт, что C ++ 11 делает не генерировать операции перемещения для класса с объявленным пользователем деструктором.

5

Другие решения

Идея состоит в том, что наличие любого из сгенерированных по умолчанию конструкторов (конструктор копирования, назначение копирования или деструктор) указывает на то, что тип должен выполнять какое-то специальное управление ресурсами. Если это так, то операции перемещения по умолчанию могут не сработать. Я не уверен, были ли действительно неудачные примеры, где сгенерированный по умолчанию конструктор копирования работает правильно, но сгенерированный по умолчанию конструктор перемещения не был представлен.

Резолюция заключалась в том, что безопаснее не генерировать операции перемещения по умолчанию, тем более что легко запросить соответствующие операции перемещения: просто добавьте = defaultред. реализация. Класс явно уже делает что-то особенное (иначе не было бы деструктора).

5

По вопросам рекламы [email protected]