Mengapa seseorang ingin menonaktifkan peringatan kompiler?

Jawaban ini dan komentar yang ditambahkan kepadanya menunjukkan cara untuk menonaktifkan beberapa peringatan penyusun menggunakan #pragmaarahan.

Mengapa orang ingin melakukan itu? Biasanya peringatan ada karena suatu alasan, dan saya selalu merasa bahwa itu alasan yang bagus. Apakah ada "kasus yang valid" di mana peringatan harus dinonaktifkan? Saat ini aku tidak bisa memikirkan apa pun, tapi mungkin itu hanya aku.

Saya hanya pernah mengalami satu situasi ketika saya menonaktifkan peringatan. Saya menganggap kesalahan peringatan jadi saya biasanya tidak melepaskannya dengan peringatan. Namun, saat mengembangkan API di pelanggan, saya menghadapi masalah bahwa metode yang diperlukan dalam fase migrasi oleh satu aplikasi dan yang tidak harus digunakan oleh yang lain harus dimasukkan dalam perpustakaan.

Cara terbaik yang dapat saya temukan untuk memberi tahu semua pengguna API bahwa mereka seharusnya tidak memanggil metode ini adalah dengan menandainya sudah usang. Namun, itu berarti bahwa satu use case yang valid ditandai sebagai peringatan kompilasi.

Eric Lippert telah menulis beberapa posting tentang peringatan di mana Anda akan menemukan informasi tentang bagaimana tim penyusun berpikir tentang peringatan.

Bidang internal tipe Internal

Arahan yang tidak digunakan tidak ditandai dengan peringatan

Berikut adalah beberapa peringatan di mana dokumentasi memberikan alasan mengapa Anda ingin menonaktifkannya:

• http://msdn.microsoft.com/en-US/library/4bw5ewxy(v=VS.80).aspx
• http://msdn.microsoft.com/en-US/library/sa4zat99(v=VS.80).aspx
• http://msdn.microsoft.com/en-US/library/9x19t380(v=VS.80).aspx

Contoh lain termasuk peringatan tentang menggunakan metode yang disusutkan jika Anda tahu Anda masih ingin menggunakan metode lama atau memiliki anggota pribadi yang tidak pernah dibaca secara lokal, tetapi dengan refleksi sebagai gantinya.

Dalam pengalaman saya, C # memiliki lebih sedikit kebutuhan untuk menonaktifkan peringatan dibandingkan bahasa lain seperti C ++. Ini sebagian besar karena, seperti yang dikatakan Eric Lippert di blog - nya , mereka "mencoba memesan peringatan hanya untuk situasi-situasi di mana kita dapat mengatakan dengan hampir pasti bahwa kode itu rusak, menyesatkan atau tidak berguna."

Contoh dalam C yang saya temukan varian secara teratur:

int doSomething(int argument1)
{
#ifdef HARDWARE_TYPE_A
    performAction(argument1);
#else
    displayNotSupportedMessage();
#endif
}

Argumen ini hanya relevan pada beberapa platform, tetapi pada platform yang tidak relevan, kompiler saya akan mengeluh, dan karena saya memiliki peringatan yang dikonversi menjadi kesalahan, itu akan membuatnya tidak bisa dibangun.

Mengkonversi peringatan ke kesalahan cukup banyak membutuhkan jalan keluar untuk "bukan yang ini, saya tahu lebih baik daripada kompiler dalam kasus ini".

Banyak perpustakaan Java yang sangat diperlukan tidak pernah diperbarui untuk menghilangkan kebutuhan akan typecast yang tidak aman. Menekan peringatan itu diperlukan agar peringatan lain yang lebih penting akan diperhatikan dan diperbaiki.

Saya melakukan pekerjaan yang disematkan dan sepertinya saya ingat satu atau dua waktu ketika saya menonaktifkan peringatan karena saya melakukan sesuatu yang tampak tidak berguna bagi kompiler, tetapi sebenarnya memiliki efek dunia nyata dalam perangkat keras.

Satu-satunya waktu lain adalah ketika saya sedang mengerjakan basis kode dengan ide-ide yang berbeda dari beberapa struktur data (seperti bagaimana cara mewakili array byte - char atau unsigned char?). Dalam kasus ini saya dapat menonaktifkan peringatan karena alternatifnya adalah menghabiskan waktu berhari-hari untuk membaca kode dan memodifikasi satu bagian, atau memasukkan ratusan gips.

Ada beberapa alasan untuk menonaktifkan peringatan kompiler secara selektif, bahkan untuk proyek yang mengupayakan praktik terbaik.

• Compiler yang berbeda (atau versi yang berbeda dari kompiler yang sama) :
  Kompiler menangani peringatan dengan cara yang berbeda. Memberikan peringatan positif palsu yang tidak memengaruhi kompiler lain. Dalam hal ini mungkin masuk akal untuk menonaktifkan peringatan untuk kompiler tersebut, daripada mengedit kode yang valid untuk menghentikan peringatan positif palsu yang hanya berdampak pada kompiler tertentu, terutama untuk kompiler lama yang pada akhirnya akan menjadi tidak didukung pula.
• Dengan kode yang dihasilkan:
  Beberapa peringatan terkait dengan kebersihan kode (kode mati, duplikat pernyataan kondisional, perbandingan yang melebihi batas tipe) dapat diabaikan dengan aman karena tidak berbahaya dan kompiler akan mengoptimalkannya.
  Membuat kode yang tidak membangkitkan peringatan yang tidak berbahaya ini tentu saja merupakan opsi juga, tetapi mungkin lebih merepotkan daripada nilainya.
• Peringatan untuk kode eksternal:
  Mungkin Anda menggunakan implementasi qsort atau md5 checksum yang terkenal yang termasuk dalam proyek Anda. Kode ini digunakan oleh banyak proyek dan diketahui bekerja dengan baik, namun mungkin ada beberapa peringatan pilih-pilih yang biasanya Anda koreksi untuk kode Anda sendiri.
  Namun untuk kode eksternal, mungkin lebih mudah untuk menonaktifkan peringatan (dengan asumsi itu tidak berbahaya).
• Peringatan yang disebabkan oleh tajuk sistem:
  Meskipun GCC / Dentang misalnya dukungan -isystem, ada kasus di mana perbedaan tajuk sistem menyebabkan peringatan yang dapat diabaikan (mungkin suatu fungsi memiliki nilai pengembalian yang ditandatangani pada satu sistem tetapi tidak pada yang lain), memicu -Wsign-compareperingatan.
  Kasus lain mungkin makro yang didefinisikan dalam tajuk sistem, Anda dapat menyalin-menempelkan makro ke dalam kode Anda sendiri untuk memodifikasinya, tetapi semua hal dianggap lebih baik tidak perlu khawatir tentang memelihara makro dari perpustakaan pihak ke-3 ... jadi lebih baik hanya untuk menenangkan peringatan (mungkin makro meleset gips yang menyebabkan -Wsign-conversionmisalnya).
• Peringatan yang tidak digunakan dalam kode rintisan:
  Anda dapat memperingatkan parameter yang tidak digunakan, namun ketika mematikan seluruh perpustakaan dalam satu file yang hanya berisi fungsi rintisan - itu tidak membantu untuk memaksa (void)arg1; (void)arg2; (void)arg3; ...dalam tubuh setiap fungsi rintisan.
  Lebih baik menekan saja -Wunused-parameterdalam hal ini.

Perhatikan bahwa dalam semua contoh ini, yang diasumsikan menonaktifkan peringatan tidak akan menyembunyikan bug nyata, misalnya: -Wredundant-decls, -Wunused-parameter, -Wdouble-promotion, mungkin -Wpedantic... dan bahwa Anda tahu apa yang Anda lakukan!

Valid atau tidak, kadang-kadang dilakukan untuk memotong arahan "memperlakukan peringatan sebagai kesalahan" pada server build.

Selain itu, saya juga tidak bisa memikirkan apa pun. Peringatan yang dinonaktifkan biasanya merupakan tanda dari "orang jahat" ...

Terakhir kali kami menonaktifkan peringatan tertentu, itu karena magang telah meninggalkan kami dengan kode yang buruk. Saya membuatnya bekerja jauh lebih baik, dengan batas konversi yang jelas menggantikan representasi data yang serampangan.

Sementara itu, kami perlu mengkompilasinya, dan kami ingin opsi "peringatan adalah kesalahan", jadi kami menekan beberapa peringatan.

Saat ini, satu-satunya peringatan yang pernah saya abaikan adalah

  warning C4290: C++ exception specification ignored except to indicate a function is not __declspec(nothrow)  

Karena microsoft tidak mengimplementasikan spesifikasi C ++ (dokumentasi bahkan mengatakan tidak!) Dan mengizinkan fungsi untuk mendeklarasikan lemparan tertentu dan semua fungsi hanya bisa melempar melempar () atau melempar (...), yaitu tidak ada apa-apa atau semuanya.

Dari HelpViewer 1.1:

 A function is declared using exception specification, which Visual C++ accepts but does not implement. Code with exception specifications that are ignored during compilation may need to be recompiled and linked to be reused in future versions supporting exception specifications.