Saya akan mencoba untuk menjawab pertanyaan Anda, meskipun itu adalah pertanyaan lama, dan tidak terlihat sangat penting (sebenarnya tidak sangat penting dalam dirinya sendiri ), dan telah menerima jawaban cukup baik sudah. Alasan saya ingin menjawabnya adalah karena ini berkaitan dengan masalah mendasar evolusi standar dan desain bahasa ketika bahasa didasarkan pada bahasa yang ada: kapan fitur bahasa harus dihentikan, dihapus, atau diubah dengan cara yang tidak kompatibel?
Dalam C ++ dimungkinkan untuk menggunakan kata kunci statis dalam unit terjemahan untuk mempengaruhi visibilitas simbol (baik variabel atau deklarasi fungsi).
Keterkaitan itu sebenarnya.
Di n3092, ini sudah tidak digunakan lagi:
Penghentian menunjukkan:
- The niat untuk menghapus beberapa fitur di masa depan; ini tidak berarti bahwa fitur yang tidak digunakan lagi akan dihapus pada revisi standar berikutnya, atau harus dihapus "segera", atau sama sekali. Dan fitur yang tidak digunakan lagi dapat dihapus pada revisi standar berikutnya.
- Upaya formal untuk mencegah penggunaannya .
Poin terakhir ini penting. Meskipun tidak pernah ada janji resmi bahwa program Anda tidak akan rusak, terkadang diam-diam, oleh standar berikutnya, panitia harus berusaha menghindari pelanggaran kode yang "masuk akal". Penghentian harus memberi tahu programmer bahwa tidak masuk akal untuk bergantung pada beberapa fitur .
Itu memang menggarisbawahi, bahwa untuk kompatibilitas dengan C (dan kemampuan untuk mengkompilasi program-C sebagai C ++) penghentian itu mengganggu. Namun, mengompilasi program C secara langsung sebagai C ++ bisa menjadi pengalaman yang membuat frustrasi, jadi saya tidak yakin apakah itu perlu dipertimbangkan.
Sangat penting untuk mempertahankan subset umum C / C ++, terutama untuk file header. Tentu saja, staticdeklarasi global adalah deklarasi simbol dengan linkage internal dan ini tidak terlalu berguna dalam file header.
Tapi masalahnya bukan hanya kompatibilitas dengan C, itu juga kompatibilitas dengan C ++ yang ada: ada banyak program C ++ valid yang menggunakan staticdeklarasi global. Kode ini tidak hanya legal secara formal, tetapi juga masuk akal, karena menggunakan fitur bahasa yang terdefinisi dengan baik seperti yang dimaksudkan untuk digunakan .
Hanya karena sekarang ada "cara yang lebih baik" (menurut beberapa) untuk melakukan sesuatu tidak membuat program yang ditulis dengan cara lama "buruk" atau "tidak masuk akal". Kemampuan menggunakan statickata kunci pada deklarasi objek dan fungsi pada lingkup global dipahami dengan baik di komunitas C dan C ++, dan paling sering digunakan dengan benar.
Dengan nada yang sama, saya tidak akan mengubah model C doublemenjadi static_cast<double>hanya karena "C-style cast buruk", karena static_cast<double>menambahkan informasi nol dan keamanan nol.
Gagasan bahwa setiap kali cara baru untuk melakukan sesuatu ditemukan, semua programmer akan buru-buru menulis ulang kode kerja mereka yang sudah terdefinisi dengan baik adalah gila. Jika Anda ingin menghapus semua keburukan dan masalah C yang diwariskan, Anda tidak mengubah C ++, Anda menciptakan bahasa pemrograman baru. Menghapus setengah satu penggunaan statichampir tidak membuat C ++ kurang C-jelek.
Perubahan kode membutuhkan pembenaran, dan "lama itu buruk" tidak pernah menjadi pembenaran untuk perubahan kode.
Pemutusan perubahan bahasa membutuhkan pembenaran yang sangat kuat. Menyederhanakan bahasa ini tidak pernah menjadi pembenaran untuk perubahan besar.
Alasan yang diberikan mengapa staticburuk hanya sangat lemah, dan bahkan tidak jelas mengapa deklarasi objek dan fungsi tidak digunakan bersama-sama - memberi mereka perlakuan yang berbeda hampir tidak membuat C ++ lebih sederhana atau lebih ortogonal.
Jadi, sungguh, ini adalah kisah yang menyedihkan. Bukan karena konsekuensi praktis yang dimilikinya: ia sama sekali tidak memiliki konsekuensi praktis. Tapi karena itu menunjukkan kurangnya akal sehat dari panitia ISO.