Kapan membuat tipe tidak dapat dipindahkan di C ++ 11?

Saya terkejut ini tidak muncul di hasil pencarian saya, saya pikir seseorang akan menanyakan ini sebelumnya, mengingat kegunaan semantik bergerak di C ++ 11:

Kapan saya harus (atau apakah sebaiknya saya) membuat kelas tidak dapat dipindahkan di C ++ 11?

(Alasan lain selain masalah kompatibilitas dengan kode yang ada, yaitu.)

Jawaban Herb (sebelum diedit) benar-benar memberi contoh yang baik dari jenis yang seharusnya tidak menjadi bergerak: std::mutex.

Jenis mutex asli OS (misalnya pthread_mutex_tpada platform POSIX) mungkin bukan "invarian lokasi" yang berarti alamat objek adalah bagian dari nilainya. Misalnya, OS mungkin menyimpan daftar pointer ke semua objek mutex yang diinisialisasi. Jika std::mutexberisi jenis mutex OS asli sebagai anggota data dan alamat jenis asli harus tetap diperbaiki (karena OS menyimpan daftar penunjuk ke mutexnya) maka salah satu dari std::mutexmereka harus menyimpan jenis mutex asli di heap sehingga akan tetap di lokasi yang sama ketika dipindahkan antar std::mutexobjek atau std::mutextidak boleh bergerak. Menyimpannya di heap tidak mungkin, karena a std::mutexmemiliki constexprkonstruktor dan harus memenuhi syarat untuk inisialisasi konstan (yaitu inisialisasi statis) sehinggastd::mutexdijamin akan dibangun sebelum eksekusi program dimulai, sehingga konstruktornya tidak dapat menggunakannya new. Jadi satu-satunya pilihan yang tersisa adalah std::mutexmenjadi tidak tergoyahkan.

Alasan yang sama berlaku untuk jenis lain yang berisi sesuatu yang membutuhkan alamat tetap. Jika alamat sumber daya harus tetap, jangan pindahkan!

Ada argumen lain untuk tidak bergerak, std::mutexyaitu akan sangat sulit melakukannya dengan aman, karena Anda perlu tahu bahwa tidak ada yang mencoba mengunci mutex pada saat mutex sedang dipindahkan. Karena mutex adalah salah satu blok bangunan yang dapat Anda gunakan untuk mencegah balapan data, akan sangat disayangkan jika mereka tidak aman terhadap balapan itu sendiri! Dengan immovable, std::mutexAnda tahu satu-satunya hal yang dapat dilakukan siapa pun padanya setelah dibuat dan sebelum dihancurkan adalah dengan menguncinya dan membukanya, dan operasi tersebut secara eksplisit dijamin aman untuk thread dan tidak memperkenalkan data race. Argumen yang sama ini berlaku untuk std::atomic<T>objek: kecuali mereka dapat dipindahkan secara atomis, tidak mungkin untuk memindahkannya dengan aman, utas lain mungkin mencoba memanggilcompare_exchange_strongpada objek tepat pada saat itu sedang dipindahkan. Jadi kasus lain di mana jenis tidak boleh dipindahkan adalah di mana mereka adalah blok bangunan tingkat rendah dari kode bersamaan yang aman dan harus memastikan atomisitas dari semua operasi pada mereka. Jika nilai objek dapat dipindahkan ke objek baru kapan saja, Anda perlu menggunakan variabel atom untuk melindungi setiap variabel atom sehingga Anda tahu apakah aman untuk menggunakannya atau telah dipindahkan ... dan variabel atom untuk melindungi variabel atom itu, dan seterusnya ...

Saya pikir saya akan menggeneralisasi untuk mengatakan bahwa ketika sebuah objek hanyalah sepotong memori murni, bukan jenis yang bertindak sebagai pemegang nilai atau abstraksi nilai, tidak masuk akal untuk memindahkannya. Tipe mendasar seperti inttidak bisa bergerak: memindahkannya hanyalah salinan. Anda tidak dapat merobek nyali dari sebuah int, Anda dapat menyalin nilainya dan kemudian mengaturnya ke nol, tetapi itu masih intdengan nilai, itu hanya byte memori. Tapi intmasih bisa dipindahkandalam istilah bahasa karena salinan adalah operasi pemindahan yang valid. Namun untuk jenis yang tidak dapat disalin, jika Anda tidak ingin atau tidak dapat memindahkan bagian memori dan Anda juga tidak dapat menyalin nilainya, maka itu tidak dapat dipindahkan. Mutex atau variabel atom adalah lokasi memori tertentu (diperlakukan dengan properti khusus) sehingga tidak masuk akal untuk dipindahkan, dan juga tidak dapat disalin, jadi tidak dapat dipindahkan.

Jawaban singkat: Jika suatu jenis dapat disalin, ia juga harus dapat dipindahkan. Namun, kebalikannya tidak benar: beberapa tipe seperti std::unique_ptrdapat dipindahkan namun tidak masuk akal untuk menyalinnya; ini secara alami adalah tipe yang hanya bergerak.

Jawaban yang sedikit lebih panjang mengikuti ...

Ada dua jenis tipe utama (di antara yang lebih bertujuan khusus seperti ciri):

1. Jenis nilai seperti, seperti intatau vector<widget>. Ini mewakili nilai-nilai, dan secara alami harus dapat disalin. Dalam C ++ 11, secara umum Anda harus memikirkan pemindahan sebagai pengoptimalan salinan, sehingga semua jenis yang dapat disalin secara alami harus dapat dipindah ... pemindahan hanyalah cara yang efisien untuk melakukan penyalinan dalam kasus yang sering umum yang tidak Anda lakukan ' Saya tidak membutuhkan objek aslinya lagi dan hanya akan menghancurkannya.

2. Tipe mirip referensi yang ada dalam hierarki pewarisan, seperti kelas dasar dan kelas dengan fungsi anggota yang dilindungi atau virtual. Ini biasanya dipegang oleh penunjuk atau referensi, sering kali base*atau base&, dan karenanya tidak menyediakan konstruksi salinan untuk menghindari pemotongan; jika Anda ingin mendapatkan objek lain seperti yang sudah ada, Anda biasanya memanggil fungsi virtual seperti clone. Ini tidak memerlukan konstruksi pemindahan atau penugasan karena dua alasan: Mereka tidak dapat disalin, dan mereka sudah memiliki operasi "pemindahan" alami yang lebih efisien - Anda cukup menyalin / memindahkan penunjuk ke objek dan objek itu sendiri tidak harus pindah ke lokasi memori baru sama sekali.

Sebagian besar jenis termasuk dalam salah satu dari dua kategori itu, tetapi ada jenis jenis lain juga yang juga berguna, hanya lebih jarang. Secara khusus di sini, jenis yang mengekspresikan kepemilikan unik suatu sumber daya, seperti std::unique_ptr, secara alami merupakan jenis yang hanya bergerak, karena tidak seperti nilai (tidak masuk akal untuk menyalinnya) tetapi Anda menggunakannya secara langsung (tidak selalu dengan penunjuk atau referensi) dan ingin memindahkan objek jenis ini dari satu tempat ke tempat lain.

Sebenarnya ketika saya mencari-cari, saya menemukan beberapa tipe di C ++ 11 tidak dapat dipindahkan:

• semua mutexjenis ( 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
• semua atomictipe
• once_flag

Rupanya ada diskusi di Clang: https://groups.google.com/forum/?fromgroups=#!topic/comp.std.c++/pCO1Qqb3Xa4

Alasan lain yang saya temukan - kinerja. Katakanlah Anda memiliki kelas 'a' yang memiliki nilai. Anda ingin mengeluarkan antarmuka yang memungkinkan pengguna mengubah nilai untuk waktu terbatas (untuk cakupan).

Cara untuk mencapai ini adalah dengan mengembalikan objek 'scope guard' dari 'a' yang mengembalikan nilainya ke destruktornya, seperti:

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);
    }
}

Jika saya membuat change_value_guard dapat dipindahkan, saya harus menambahkan 'jika' ke destruktornya yang akan memeriksa apakah penjaga telah dipindahkan - itu adalah tambahan jika, dan berdampak pada kinerja.

Ya, tentu, itu mungkin dapat dioptimalkan oleh pengoptimal yang waras, tetapi tetap bagus bahasanya (ini membutuhkan C ++ 17 meskipun, untuk dapat mengembalikan jenis yang tidak dapat dipindahkan membutuhkan penghapusan salinan yang dijamin) tidak memerlukan kami untuk membayar itu jika kita tidak akan memindahkan penjaga selain mengembalikannya dari fungsi pembuatan (prinsip jangan-bayar-untuk-apa-jangan-gunakan).