Kapan saya harus menggunakan noexcept?

Kata noexceptkunci dapat diterapkan secara tepat ke banyak tanda tangan fungsi, tetapi saya tidak yakin kapan saya harus mempertimbangkan menggunakannya dalam praktik. Berdasarkan apa yang telah saya baca sejauh ini, penambahan menit terakhir dari noexcepttampaknya mengatasi beberapa masalah penting yang muncul ketika memindahkan konstruktor. Namun, saya masih belum dapat memberikan jawaban yang memuaskan untuk beberapa pertanyaan praktis yang membuat saya membaca lebih lanjut noexcept.

1. Ada banyak contoh fungsi yang saya tahu tidak akan pernah dilempar, tetapi kompiler tidak dapat menentukannya sendiri. Haruskah saya menambahkan noexceptdeklarasi fungsi dalam semua kasus seperti itu?

   Harus memikirkan apakah saya perlu menambahkan atau tidak noexceptsetelah setiap pernyataan fungsi akan sangat mengurangi produktivitas programmer (dan terus terang, akan menyebalkan). Untuk situasi apa saya harus lebih berhati-hati dalam penggunaannya noexcept, dan untuk situasi apa saya bisa lolos dari yang tersirat noexcept(false)?

2. Kapan saya bisa secara realistis berharap untuk mengamati peningkatan kinerja setelah menggunakan noexcept? Secara khusus, berikan contoh kode yang kompiler C ++ dapat menghasilkan kode mesin yang lebih baik setelah penambahan noexcept.

   Secara pribadi, saya peduli noexceptkarena meningkatnya kebebasan yang diberikan kepada kompiler untuk secara aman menerapkan beberapa jenis optimasi. Apakah kompiler modern mengambil keuntungan noexceptdengan cara ini? Jika tidak, dapatkah saya mengharapkan beberapa dari mereka melakukannya dalam waktu dekat?

Saya pikir masih terlalu dini untuk memberikan jawaban "praktik terbaik" untuk ini karena belum ada cukup waktu untuk menggunakannya dalam praktik. Jika ini ditanyakan tentang specifier pelemparan tepat setelah mereka keluar maka jawabannya akan sangat berbeda untuk sekarang.

Harus memikirkan apakah saya perlu menambahkan atau tidak noexceptsetelah setiap pernyataan fungsi akan sangat mengurangi produktivitas programmer (dan terus terang, akan menyebalkan).

Nah, kemudian gunakan ketika sudah jelas bahwa fungsi tidak akan pernah membuang.

Kapan saya bisa secara realistis berharap untuk mengamati peningkatan kinerja setelah menggunakan noexcept? [...] Secara pribadi, saya peduli noexceptkarena meningkatnya kebebasan yang diberikan kepada kompiler untuk secara aman menerapkan beberapa jenis optimasi.

Sepertinya keuntungan pengoptimalan terbesar adalah dari pengoptimalan pengguna, bukan pengompilasi karena kemungkinan memeriksa noexceptdan membebani secara berlebihan. Sebagian besar kompiler mengikuti metode penanganan pengecualian tanpa-penalti-jika-Anda-jangan-lempar, jadi saya ragu itu akan banyak berubah (atau apa pun) pada tingkat kode mesin kode Anda, meskipun mungkin mengurangi ukuran biner dengan menghapus menangani kode.

Menggunakan noexceptdi empat besar (konstruktor, tugas, bukan destruktor seperti yang sudah mereka lakukan noexcept) kemungkinan akan menyebabkan peningkatan terbaik karena noexceptcek 'umum' dalam kode templat seperti dalam stdwadah. Misalnya, std::vectortidak akan menggunakan gerakan kelas Anda kecuali jika ditandai noexcept(atau kompilator dapat menyimpulkannya).

Karena saya terus mengulangi hari-hari ini: semantik yang pertama .

Menambahkan noexcept, noexcept(true)dan noexcept(false)yang pertama dan terutama tentang semantik. Itu hanya secara kebetulan mengkondisikan sejumlah kemungkinan optimasi.

Sebagai seorang programmer yang membaca kode, keberadaannya noexceptmirip dengan const: itu membantu saya lebih baik mengetahui apa yang mungkin atau tidak mungkin terjadi. Karena itu, ada baiknya meluangkan waktu untuk memikirkan apakah Anda tahu atau tidak fungsi akan dilempar. Untuk pengingat, segala jenis alokasi memori dinamis dapat dilemparkan.

Oke, sekarang ke optimasi yang mungkin.

Optimalisasi yang paling jelas sebenarnya dilakukan di perpustakaan. C ++ 11 menyediakan sejumlah sifat yang memungkinkan mengetahui apakah suatu fungsi noexceptatau tidak, dan implementasi Perpustakaan Standar itu sendiri akan menggunakan sifat-sifat tersebut untuk mendukung noexceptoperasi pada objek yang ditentukan pengguna yang mereka manipulasi, jika mungkin. Seperti memindahkan semantik .

Compiler mungkin hanya mencukur sedikit lemak (mungkin) dari pengecualian penanganan data, karena harus memperhitungkan fakta bahwa Anda mungkin telah berbohong. Jika fungsi yang ditandai noexceptmelempar, maka std::terminatedipanggil.

Semantik ini dipilih karena dua alasan:

• segera mendapat manfaat dari noexceptbahkan ketika dependensi tidak menggunakannya (kompatibilitas ke belakang)
• memungkinkan spesifikasi noexceptfungsi saat memanggil yang secara teoritis dapat melempar, tetapi tidak diharapkan untuk argumen yang diberikan

Ini sebenarnya membuat (berpotensi) perbedaan besar bagi pengoptimal dalam kompiler. Compiler benar-benar memiliki fitur ini selama bertahun-tahun melalui pernyataan throw kosong () setelah definisi fungsi, serta ekstensi kepatutan. Saya dapat meyakinkan Anda bahwa kompiler modern memanfaatkan pengetahuan ini untuk menghasilkan kode yang lebih baik.

Hampir setiap optimasi dalam kompiler menggunakan sesuatu yang disebut "flow chart" dari suatu fungsi untuk alasan tentang apa yang legal. Grafik aliran terdiri dari apa yang umumnya disebut "blok" dari fungsi (area kode yang memiliki satu pintu masuk dan satu pintu keluar tunggal) dan tepi antara blok untuk menunjukkan ke mana aliran dapat melompat. Noexcept mengubah grafik aliran.

Anda meminta contoh spesifik. Pertimbangkan kode ini:

void foo(int x) {
    try {
        bar();
        x = 5;
        // Other stuff which doesn't modify x, but might throw
    } catch(...) {
        // Don't modify x
    }

    baz(x); // Or other statement using x
}

Grafik aliran untuk fungsi ini berbeda jika bardiberi label noexcept(tidak ada cara untuk eksekusi untuk melompat antara akhir bardan pernyataan tangkapan). Ketika diberi label sebagai noexcept, kompiler yakin nilai x adalah 5 selama fungsi baz - blok x = 5 dikatakan "mendominasi" blok baz (x) tanpa tepi dari bar()pernyataan catch.

Kemudian dapat melakukan sesuatu yang disebut "propagasi konstan" untuk menghasilkan kode yang lebih efisien. Di sini jika baz digarisbawahi, pernyataan yang menggunakan x mungkin juga mengandung konstanta dan apa yang dulunya merupakan evaluasi runtime dapat diubah menjadi evaluasi waktu kompilasi, dll.

Pokoknya, jawaban singkat: noexceptmemungkinkan kompiler menghasilkan grafik aliran yang lebih ketat, dan grafik aliran digunakan untuk alasan tentang semua jenis optimasi kompiler umum. Bagi seorang kompiler, penjelasan pengguna dengan sifat ini sangat bagus. Kompiler akan mencoba mencari tahu hal ini, tetapi biasanya tidak bisa (fungsi yang dimaksud mungkin dalam file objek lain tidak terlihat oleh kompiler atau secara transparan menggunakan beberapa fungsi yang tidak terlihat), atau ketika itu terjadi, ada beberapa pengecualian sepele yang mungkin dilemparkan yang bahkan tidak Anda sadari, sehingga tidak dapat secara implisit melabelnya noexcept(mengalokasikan memori dapat melempar bad_alloc, misalnya).

noexceptdapat secara dramatis meningkatkan kinerja beberapa operasi. Ini tidak terjadi pada tingkat menghasilkan kode mesin oleh kompiler, tetapi dengan memilih algoritma yang paling efektif: seperti yang lain disebutkan, Anda melakukan pemilihan ini menggunakan fungsi std::move_if_noexcept. Misalnya, pertumbuhan std::vector(misalnya, ketika kita menelepon reserve) harus memberikan jaminan keselamatan-pengecualian yang kuat. Jika ia mengetahui bahwa Tmove constructor tidak melempar, ia hanya dapat memindahkan setiap elemen. Kalau tidak, itu harus menyalin semua Ts. Ini telah dijelaskan secara rinci dalam posting ini .

Kapan saya bisa secara realistis kecuali mengamati peningkatan kinerja setelah menggunakan noexcept? Secara khusus, berikan contoh kode yang kompiler C ++ dapat menghasilkan kode mesin yang lebih baik setelah penambahan noexcept.

Um, tidak pernah? Tidak pernah ada waktu? Tidak pernah.

noexceptadalah untuk optimisasi kinerja kompiler dengan cara yang sama yaitu constuntuk optimisasi kinerja kompiler. Itu hampir tidak pernah.

noexceptterutama digunakan untuk memungkinkan "Anda" untuk mendeteksi pada waktu kompilasi jika suatu fungsi dapat melempar pengecualian. Ingat: kebanyakan kompiler tidak mengeluarkan kode khusus untuk pengecualian kecuali itu benar-benar melempar sesuatu. Jadi noexceptbukan masalah memberikan petunjuk kompiler tentang bagaimana mengoptimalkan suatu fungsi seperti memberi Anda petunjuk tentang cara menggunakan suatu fungsi.

Templat like move_if_noexceptakan mendeteksi jika move constructor didefinisikan dengan noexceptdan akan mengembalikan tipe const&bukan &&jika bukan. Ini adalah cara untuk mengatakan untuk bergerak jika sangat aman untuk melakukannya.

Secara umum, Anda harus menggunakan noexceptketika Anda berpikir itu akan berguna untuk melakukannya. Beberapa kode akan mengambil jalur yang berbeda jika is_nothrow_constructiblebenar untuk jenis itu. Jika Anda menggunakan kode yang akan melakukan itu, jangan ragu untuk noexceptmenggunakan konstruktor yang sesuai.

Singkatnya: gunakan untuk memindahkan konstruktor dan konstruksi serupa, tetapi jangan merasa seperti Anda harus mengacaukannya.

Dalam kata-kata Bjarne ( Bahasa Pemrograman C ++, Edisi ke-4 , halaman 366):

Jika penghentian adalah respons yang dapat diterima, pengecualian yang tidak tertangkap akan mencapai hal itu karena itu berubah menjadi panggilan penghentian () (§13.5.2.5). Juga, noexceptspecifier (§13.5.1.1) dapat membuat keinginan itu eksplisit.

Sistem toleran kesalahan yang berhasil adalah bertingkat. Setiap level mengatasi kesalahan sebanyak mungkin tanpa terlalu berkutat dan membiarkan sisanya ke level yang lebih tinggi. Pengecualian mendukung pandangan itu. Lebih jauh lagi, terminate()mendukung pandangan ini dengan memberikan jalan keluar jika mekanisme penanganan pengecualian itu sendiri rusak atau jika telah digunakan secara tidak lengkap, sehingga meninggalkan pengecualian. Demikian pula, noexceptmemberikan jalan keluar sederhana untuk kesalahan di mana mencoba memulihkan tampaknya tidak mungkin dilakukan.

double compute(double x) noexcept;     {
    string s = "Courtney and Anya";
    vector<double> tmp(10);
    // ...
}

Konstruktor vektor mungkin gagal mendapatkan memori untuk sepuluh dobelnya dan melempar a std::bad_alloc. Dalam hal ini, program berakhir. Itu berakhir tanpa syarat dengan memohon std::terminate()(§30.4.1.3). Itu tidak memanggil destruktor dari memanggil fungsi. Ini adalah implementasi yang ditentukan apakah destruktor dari lingkup antara throwdan noexcept(misalnya, untuk s dalam compute ()) dipanggil. Program ini baru saja akan berakhir, jadi kita tidak harus bergantung pada objek apa pun. Dengan menambahkan noexceptspecifier, kami menunjukkan bahwa kode kami tidak ditulis untuk mengatasi lemparan.

1. Ada banyak contoh fungsi yang saya tahu tidak akan pernah dilempar, tetapi kompiler tidak dapat menentukannya sendiri. Haruskah saya menambahkan noexcept ke deklarasi fungsi dalam semua kasus seperti itu?

noexceptrumit, karena merupakan bagian dari antarmuka fungsi. Terutama, jika Anda menulis perpustakaan, kode klien Anda dapat bergantung pada noexceptproperti. Mungkin sulit untuk mengubahnya nanti, karena Anda mungkin merusak kode yang ada. Itu mungkin tidak terlalu menjadi perhatian ketika Anda menerapkan kode yang hanya digunakan oleh aplikasi Anda.

Jika Anda memiliki fungsi yang tidak dapat dilempar, tanyakan pada diri Anda apakah itu akan tetap noexceptatau apakah itu membatasi implementasi di masa depan? Misalnya, Anda mungkin ingin memperkenalkan pengecekan kesalahan argumen ilegal dengan melemparkan pengecualian (misalnya, untuk pengujian unit), atau Anda mungkin bergantung pada kode perpustakaan lain yang dapat mengubah spesifikasi pengecualiannya. Dalam hal ini, lebih aman bersikap konservatif dan mengabaikan noexcept.

Di sisi lain, jika Anda yakin bahwa fungsi tidak boleh melempar dan itu benar bahwa itu adalah bagian dari spesifikasi, Anda harus mendeklarasikannya noexcept. Namun, perlu diingat bahwa kompiler tidak akan dapat mendeteksi pelanggaran noexceptjika implementasi Anda berubah.

2. Untuk situasi apa saya harus lebih berhati-hati tentang penggunaan noexcept, dan untuk situasi mana saya bisa lolos dengan noexcept yang tersirat (salah)?

Ada empat kelas fungsi yang harus Anda berkonsentrasi karena mereka akan memiliki dampak terbesar:

1. memindahkan operasi (memindahkan operator penugasan dan memindahkan konstruktor)
2. operasi swap
3. memory deallocators (operator delete, operator delete [])
4. destruktor (meskipun ini secara implisit noexcept(true)kecuali Anda membuatnya noexcept(false))

Fungsi-fungsi ini umumnya harus noexcept, dan kemungkinan besar implementasi perpustakaan dapat menggunakan noexceptproperti. Misalnya, std::vectordapat menggunakan operasi pemindahan yang tidak melempar tanpa mengorbankan jaminan pengecualian yang kuat. Jika tidak, ia harus kembali ke elemen penyalinan (seperti yang terjadi pada C ++ 98).

Jenis optimasi ini ada pada level algoritmik dan tidak bergantung pada optimisasi kompiler. Ini dapat memiliki dampak yang signifikan, terutama jika elemen-elemennya mahal untuk disalin.

3. Kapan saya dapat secara realistis berharap untuk mengamati peningkatan kinerja setelah menggunakan noexcept? Secara khusus, berikan contoh kode yang kompiler C ++ dapat menghasilkan kode mesin yang lebih baik setelah penambahan noexcept.

Keuntungan dari noexcepttidak ada spesifikasi pengecualian atau throw()adalah bahwa standar memungkinkan kompiler lebih banyak kebebasan ketika datang ke stack unwinding. Bahkan dalam throw()kasus ini, kompiler harus sepenuhnya melepas tumpukan (dan harus melakukannya dalam urutan terbalik yang tepat dari konstruksi objek).

Dalam hal noexceptini, di sisi lain, tidak perlu melakukan itu. Tidak ada persyaratan bahwa stack harus dibatalkan (tetapi kompiler masih diperbolehkan untuk melakukannya). Kebebasan itu memungkinkan pengoptimalan kode lebih lanjut karena menurunkan overhead untuk selalu dapat melepaskan tumpukan.

Pertanyaan terkait tentang noexcept, stack unwinding, dan kinerja menjelaskan lebih lanjut tentang overhead saat stack unwinding diperlukan.

Saya juga merekomendasikan buku Scott Meyers "Effective Modern C ++", "Item 14: Deklarasikan fungsi-fungsi kecuali jika mereka tidak akan mengeluarkan pengecualian" untuk bacaan lebih lanjut.

Ada banyak contoh fungsi yang saya tahu tidak akan pernah dilempar, tetapi kompiler tidak dapat menentukannya sendiri. Haruskah saya menambahkan noexcept ke deklarasi fungsi dalam semua kasus seperti itu?

Ketika Anda mengatakan "Saya tahu [mereka] tidak akan pernah melempar", maksud Anda dengan memeriksa implementasi fungsi yang Anda tahu bahwa fungsi tersebut tidak akan melempar. Saya pikir pendekatan itu luar dalam.

Lebih baik untuk mempertimbangkan apakah suatu fungsi dapat membuang pengecualian untuk menjadi bagian dari desain fungsi: sama pentingnya dengan daftar argumen dan apakah suatu metode adalah mutator (... const). Menyatakan bahwa "fungsi ini tidak pernah melempar pengecualian" adalah kendala pada implementasi. Menghilangkannya tidak berarti fungsi tersebut dapat memberikan pengecualian; itu berarti bahwa versi fungsi saat ini dan semua versi yang akan datang dapat memberikan pengecualian. Ini adalah kendala yang membuat implementasi lebih sulit. Tetapi beberapa metode harus memiliki batasan agar praktis berguna; yang paling penting, sehingga mereka dapat dipanggil dari destructor, tetapi juga untuk implementasi kode "roll-back" dalam metode yang memberikan jaminan pengecualian yang kuat.