Spróbuję odpowiedzieć na Twoje pytanie, chociaż jest to stare pytanie i nie wygląda na bardzo ważne (naprawdę nie jest bardzo ważne samo w sobie ), a otrzymałem już całkiem dobre odpowiedzi. Powodem, dla którego chcę na nie odpowiedzieć, jest to, że odnosi się to do fundamentalnych kwestii ewolucji standardu i projektowania języka, gdy język jest oparty na istniejącym języku: kiedy należy wycofać, usunąć lub zmienić funkcje języka w niekompatybilny sposób?
W C ++ możliwe jest użycie słowa kluczowego static w jednostce tłumaczeniowej, aby wpłynąć na widoczność symbolu (deklaracja zmiennej lub funkcji).
Właściwie to połączenie.
W n3092 to zostało wycofane:
Wycofanie oznacza:
- Plik intencją usunąć jakąś funkcję w przyszłości; nie oznacza to, że przestarzałe funkcje zostaną usunięte w następnej wersji standardowej lub że należy je usunąć „wkrótce” lub w ogóle. Funkcje, które nie są przestarzałe, mogą zostać usunięte w następnej wersji standardu.
- Formalna próba zniechęcenia do jego używania .
Ta ostatnia kwestia jest ważna. Chociaż nigdy nie ma formalnej obietnicy, że twój program nie zostanie złamany, czasami po cichu, zgodnie z następnymi standardami, komitet powinien starać się unikać łamania „rozsądnego” kodu. Wycofanie się powinno powiedzieć programistom, że nieuzasadnione jest poleganie na jakiejś funkcji .
Podkreśla jednak, że ze względu na zgodność z C (i możliwość kompilowania programów w C jako C ++) wycofanie się jest denerwujące. Jednak kompilowanie programu w języku C bezpośrednio jako C ++ może już być frustrujące, więc nie jestem pewien, czy wymaga to rozważenia.
Zachowanie wspólnego podzbioru C / C ++ jest bardzo ważne, szczególnie w przypadku plików nagłówkowych. Oczywiście,static deklaracje globalne są deklaracjami symboli z wewnętrznymi powiązaniami, co nie jest zbyt przydatne w pliku nagłówkowym.
Ale problem nigdy nie polega tylko na zgodności z C, jest to kompatybilność z istniejącym C ++: istnieje mnóstwo istniejących programów w C ++, które używają staticglobalnych deklaracji. Ten kod jest nie tylko formalnie legalny, ale także rozsądny, ponieważ wykorzystuje dobrze zdefiniowaną funkcję językową w sposób, w jaki jest przeznaczony .
Tylko dlatego, że istnieje obecnie „lepszy sposób” (według niektórych) na zrobienie czegoś, nie czyni programów napisanych w starym stylu „złymi” lub „nierozsądnymi”. Umiejętność używania staticsłowa kluczowego w deklaracjach obiektów i funkcji w zakresie globalnym jest dobrze rozumiana zarówno w społecznościach C, jak i C ++, i najczęściej używana poprawnie.
W podobnym duchu nie zamierzam zmieniać rzutów w stylu C doublena static_cast<double>tylko dlatego, że „rzuty w stylu C są złe”, ponieważ static_cast<double>dodaje zero informacji i zero bezpieczeństwa.
Pomysł, że za każdym razem, gdy wymyślany jest nowy sposób zrobienia czegoś, wszyscy programiści spieszyliby się, aby przepisać swój istniejący, dobrze zdefiniowany działający kod, jest po prostu szalony. Jeśli chcesz usunąć całą odziedziczoną C brzydotę i problemy, nie zmieniasz C ++, tylko wymyślasz nowy język programowania. Pół-usunięcie jednego użycia staticprawie nie czyni C ++ mniej brzydkim.
Zmiany kodu wymagają uzasadnienia, a „stare jest złe” nigdy nie jest uzasadnieniem dla zmian w kodzie.
Przełamywanie zmian językowych wymaga bardzo mocnego uzasadnienia. Trochę uproszczenie języka nigdy nie jest usprawiedliwieniem dla przełomowej zmiany.
Podane powody static jest zły, są po prostu wyjątkowo słabe i nie jest nawet jasne, dlaczego zarówno obiekty, jak i deklaracje funkcji nie są razem przestarzałe - nadanie im innego traktowania prawie nie czyni C ++ prostszym lub bardziej ortogonalnym.
Więc naprawdę jest to smutna historia. Nie z powodu praktycznych konsekwencji, jakie miał: miał dokładnie zero praktycznych konsekwencji. Ale ponieważ pokazuje wyraźny brak zdrowego rozsądku ze strony komitetu ISO.