Когда в C ++ 11 сделать тип неподвижным?

Я был удивлен, что это не появилось в моих результатах поиска, я подумал, что кто-то спросил бы об этом раньше, учитывая полезность семантики перемещения в C ++ 11:

Когда мне нужно (или это хорошая идея) сделать класс неподвижным в C ++ 11?

(Причины, отличные от проблем совместимости с существующим кодом.)

Ответ Травы (прежде чем он был отредактирован) на самом деле дал хороший пример такого типа , который не должен быть подвижным: std::mutex.

Собственный тип мьютекса ОС (например, pthread_mutex_tна платформах POSIX) может не быть «инвариантным относительно местоположения», что означает, что адрес объекта является частью его значения. Например, ОС может хранить список указателей на все инициализированные объекты мьютекса. Если std::mutexв качестве члена данных содержится собственный тип мьютекса ОС, а адрес собственного типа должен оставаться фиксированным (поскольку ОС поддерживает список указателей на свои мьютексы), то любой из std::mutexних должен будет сохранить собственный тип мьютекса в куче, чтобы он оставался в одно и то же место при перемещении между std::mutexобъектами или объект std::mutexне должен перемещаться. Сохранение его в куче невозможно, потому что у a std::mutexесть constexprконструктор и он должен иметь право на постоянную инициализацию (т.е. статическую инициализацию), чтобы глобальныйstd::mutexгарантированно создается до начала выполнения программы, поэтому его конструктор не может использовать new. Так что остается единственный вариант - std::mutexоставаться неподвижным.

То же самое относится и к другим типам, которые содержат что-то, для чего требуется фиксированный адрес. Если адрес ресурса должен оставаться неизменным, не перемещайте его!

Есть еще один аргумент в пользу отказа от перемещения, std::mutexкоторый заключается в том, что было бы очень сложно сделать это безопасно, потому что вам нужно знать, что никто не пытается заблокировать мьютекс в момент его перемещения. Поскольку мьютексы являются одним из строительных блоков, которые вы можете использовать для предотвращения гонок данных, было бы прискорбно, если бы они были небезопасны против самих гонок! С неподвижным объектом std::mutexвы знаете, что единственное, что каждый может сделать с ним после того, как он был построен и до того, как он был уничтожен, - это заблокировать и разблокировать его, и эти операции явно гарантируются как потокобезопасные и не вызывают гонок данных. Тот же аргумент применяется к std::atomic<T>объектам: если они не могут быть перемещены атомарно, их невозможно будет безопасно перемещать, другой поток может пытаться вызватьcompare_exchange_strongна объекте прямо в момент его перемещения. Таким образом, другой случай, когда типы не должны быть подвижными, - это когда они являются низкоуровневыми строительными блоками безопасного параллельного кода и должны обеспечивать атомарность всех операций с ними. Если значение объекта может быть перемещено в новый объект в любое время, вам нужно будет использовать атомарную переменную для защиты каждой атомарной переменной, чтобы вы знали, безопасно ли ее использовать или она была перемещена ... и атомарную переменную для защиты эта атомарная переменная и так далее ...

Я думаю, что обобщил бы, сказав, что когда объект - это просто чистый фрагмент памяти, а не тип, который действует как держатель для значения или абстракции значения, нет смысла перемещать его. Основные типы, например, intне могут двигаться: их перемещение - это просто копия. Вы не можете вырвать кишки из a int, вы можете скопировать его значение, а затем установить его на ноль, но он все еще имеет intзначение, это просто байты памяти. Но intвсе еще подвиженв терминах языка, потому что копия является допустимой операцией перемещения. Однако для некопируемых типов, если вы не хотите или не можете перемещать фрагмент памяти, а также не можете скопировать его значение, он не может быть перемещен. Мьютекс или атомарная переменная - это определенное место в памяти (обрабатываемое особыми свойствами), поэтому не имеет смысла перемещать, а также не подлежит копированию, поэтому его нельзя перемещать.

Краткий ответ: если шрифт копируемый, он также должен быть перемещаемым. Однако обратное неверно: некоторые типы, например, std::unique_ptrможно перемещать, но копировать их не имеет смысла; это, естественно, типы только для передвижения.

Далее следует чуть более длинный ответ ...

Есть два основных типа типов (среди других, более специализированных, таких как черты характера):

1. Типы, подобные значениям, например intили vector<widget>. Они представляют собой значения и, естественно, должны быть копируемыми. В C ++ 11, как правило, вы должны думать о перемещении как об оптимизации копирования, и поэтому все копируемые типы должны, естественно, быть перемещаемыми ... перемещение - это просто эффективный способ создания копии в часто распространенном случае, который вы не делаете. Мне больше не нужен исходный объект, и мы все равно собираемся его уничтожить.

2. Типы, подобные ссылкам, которые существуют в иерархиях наследования, например базовые классы и классы с виртуальными или защищенными функциями-членами. Обычно они хранятся с помощью указателя или ссылки, часто с помощью base*или base&, и поэтому не обеспечивают создание копии, чтобы избежать разделения; если вы действительно хотите получить другой объект, такой как существующий, вы обычно вызываете виртуальную функцию, например clone. Они не нуждаются в построении или назначении перемещения по двум причинам: они не копируются, и в них уже есть еще более эффективная естественная операция «перемещения» - вы просто копируете / перемещаете указатель на объект, а сам объект не придется вообще переместиться в новое место в памяти.

Большинство типов попадает в одну из этих двух категорий, но есть и другие типы, которые также полезны, но реже. В частности, здесь типы, которые выражают уникальное владение ресурсом, например std::unique_ptr, естественно являются типами только для перемещения, потому что они не похожи на значения (нет смысла копировать их), но вы используете их напрямую (не всегда указателем или ссылкой) и поэтому хотите перемещать объекты этого типа из одного места в другое.

На самом деле, когда я поискал, я обнаружил, что некоторые типы в C ++ 11 не перемещаются:

• все mutexтипы ( recursive_mutex, timed_mutex, recursive_timed_mutex,
• condition_variable
• type_info
• error_category
• locale::facet
• random_device
• seed_seq
• ios_base
• basic_istream<charT,traits>::sentry
• basic_ostream<charT,traits>::sentry
• все atomicтипы
• once_flag

Видимо на Clang идет обсуждение: https://groups.google.com/forum/?fromgroups=#!topic/comp.std.c++/pCO1Qqb3Xa4

Еще одна причина, которую я нашел - производительность. Скажем, у вас есть класс «а», содержащий значение. Вы хотите вывести интерфейс, который позволяет пользователю изменять значение в течение ограниченного времени (для области действия).

Способ добиться этого - вернуть объект «охранник области видимости» из «a», который устанавливает значение обратно в свой деструктор, например:

class a 
{ 
    int value = 0;

  public:

    struct change_value_guard 
    { 
        friend a;
      private:
        change_value_guard(a& owner, int value) 
            : owner{ owner } 
        { 
            owner.value = value;
        }
        change_value_guard(change_value_guard&&) = delete;
        change_value_guard(const change_value_guard&) = delete;
      public:
        ~change_value_guard()
        {
            owner.value = 0;
        }
      private:
        a& owner;
    };

    change_value_guard changeValue(int newValue)
    { 
        return{ *this, newValue };
    }
};

int main()
{
    a a;
    {
        auto guard = a.changeValue(2);
    }
}

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

Да, конечно, его, вероятно, можно оптимизировать с помощью любого здравомыслящего оптимизатора, но все же приятно, что язык (для этого требуется C ++ 17, хотя, чтобы иметь возможность возвращать неподвижный тип, требует гарантированного копирования) не требует от нас заплатить, если мы все равно не собираемся перемещать охранник, кроме как вернуть его из функции создания (принцип «не плати за то, что ты не используешь»).