Sorunuzu cevaplamaya çalışacağım, eski bir soru olmasına ve çok önemli görünmemesine rağmen ( kendi başına gerçekten çok önemli değil ) ve şimdiden oldukça iyi cevaplar aldı. Yanıtlamak istememin nedeni, dil mevcut bir dile dayandığında standart evrim ve dil tasarımının temel meseleleriyle ilgili olmasıdır: dil özellikleri ne zaman kullanımdan kaldırılmalı, kaldırılmalı veya uyumsuz şekillerde değiştirilmelidir?
C ++ 'da, bir sembolün görünürlüğünü (değişken veya işlev bildirimi) etkilemek için bir çeviri birimi içinde static anahtar sözcüğünü kullanmak mümkündür.
Bağlantı aslında.
N3092'de bu kullanımdan kaldırıldı:
Kullanımdan kaldırma şunu gösterir:
- Niyet gelecekte bir özelliği kaldırmak için; bu, kullanımdan kaldırılan özelliklerin bir sonraki standart revizyonda kaldırılacağı veya "yakında" kaldırılmaları gerektiği anlamına gelmez. Kullanımdan kaldırılmayan özellikler bir sonraki standart revizyonda kaldırılabilir.
- Kullanımını engellemeye yönelik resmi bir girişim .
İkinci nokta önemlidir. Programınızın bir sonraki standarda göre bazen sessizce bozulmayacağına dair resmi bir söz olmamasına rağmen, komite "makul" kodu kırmaktan kaçınmaya çalışmalıdır. Kullanımdan kaldırma, programcılara bazı özelliklere güvenmenin mantıksız olduğunu söylemelidir .
Bununla birlikte, C ile uyumluluk (ve C programlarını C ++ olarak derleme yeteneği) için kullanımdan kaldırmanın can sıkıcı olduğunun altını çiziyor. Bununla birlikte, bir C programını doğrudan C ++ olarak derlemek zaten sinir bozucu bir deneyim olabilir, bu yüzden dikkate alınması gerekip gerekmediğinden emin değilim.
Özellikle başlık dosyaları için bir C / C ++ ortak alt kümesini korumak çok önemlidir. Elbette, staticküresel bildirimler, iç bağlantıya sahip sembol bildirimleridir ve bu, bir başlık dosyasında pek kullanışlı değildir.
Ancak sorun hiçbir zaman sadece C ile uyumluluk değildir, mevcut C ++ ile uyumluluktur: staticküresel bildirimleri kullanan tonlarca mevcut geçerli C ++ programı vardır . Bu kod sadece resmi olarak yasal değildir, aynı zamanda kullanılması amaçlandığı şekilde iyi tanımlanmış bir dil özelliğini kullandığı için sağlamdır .
Sırf artık bir şeyi yapmanın "daha iyi bir yolu" olduğu için (bazılarına göre), eski şekilde yazılan programları "kötü" veya "mantıksız" yapmaz. staticAnahtar kelimeyi nesnelerin ve işlevlerin bildirimlerinde genel kapsamda kullanma yeteneği, hem C hem de C ++ topluluklarında iyi anlaşılmıştır ve çoğu zaman doğru şekilde kullanılır.
Benzer şekilde, C tarzı yayınları geçmek gitmiyorum doubleiçin static_cast<double>sırf "C tarzı yayınları kötü" olarak static_cast<double>sıfır bilgi ve sıfır güvenlik ekler.
Bir şeyi yapmanın yeni bir yolu icat edildiğinde, tüm programcıların mevcut iyi tanımlanmış çalışma kodlarını yeniden yazmak için acele edeceği fikri deliliktir. Devralınan tüm çirkinliği ve sorunları ortadan kaldırmak istiyorsanız, C ++ 'yı değiştirmezsiniz, yeni bir programlama dili icat edersiniz. Tek kullanımının yarı kaldırılması static, C ++ 'yı daha az C-çirkin hale getirir.
Kod değişikliklerinin gerekçelendirilmesi gerekir ve "eski kötüdür" asla kod değişiklikleri için bir gerekçe değildir.
Kırıcı dil değişiklikleri çok güçlü bir gerekçeye ihtiyaç duyar. Dili biraz daha basit hale getirmek, asla bir değişiklik için bir gerekçe değildir.
Neden statickötü olduğu verilen nedenler oldukça zayıftır ve hem nesnelerin hem de işlev bildirimlerinin neden birlikte kullanılmadığı bile net değildir - onlara farklı muamele vermek C ++ 'yı daha basit veya daha ortogonal kılmaz.
Yani gerçekten üzücü bir hikaye. Sahip olduğu pratik sonuçlardan dolayı değil: tam olarak sıfır pratik sonucu vardı. Ancak ISO komitesinden açık bir sağduyu eksikliği gösterdiği için.