Tentarei responder à sua pergunta, embora seja uma pergunta antiga e não pareça muito importante (na verdade não é muito importante por si só ), e já recebeu respostas muito boas. O motivo pelo qual desejo responder é que ele se relaciona a questões fundamentais de evolução padrão e design de linguagem quando a linguagem é baseada em uma linguagem existente: quando os recursos da linguagem devem ser descontinuados, removidos ou alterados de maneiras incompatíveis?
Em C ++, é possível usar a palavra-chave estática em uma unidade de tradução para afetar a visibilidade de um símbolo (variável ou declaração de função).
A ligação, na verdade.
No n3092, isso foi descontinuado:
A suspensão de uso indica:
- A intenção de remover algum recurso no futuro; isso não significa que recursos obsoletos serão removidos na próxima revisão padrão, ou que eles devem ser removidos "em breve", ou de todo. E recursos não obsoletos podem ser removidos na próxima revisão padrão.
- Uma tentativa formal de desencorajar seu uso .
O último ponto é importante. Embora nunca haja uma promessa formal de que seu programa não será quebrado, às vezes silenciosamente, pelo próximo padrão, o comitê deve tentar evitar quebrar o código "razoável". A depreciação deve dizer aos programadores que não é razoável depender de algum recurso .
No entanto, ele destaca que, para compatibilidade com C (e a capacidade de compilar programas C como C ++), a depreciação é irritante. No entanto, compilar um programa C diretamente como C ++ já pode ser uma experiência frustrante, portanto, não tenho certeza se merece consideração.
É muito importante preservar um subconjunto comum C / C ++, especialmente para arquivos de cabeçalho. Obviamente, staticas declarações globais são declarações de símbolo com ligação interna e isso não é muito útil em um arquivo de cabeçalho.
Mas o problema nunca é apenas compatibilidade com C, é compatibilidade com C ++ existente: há toneladas de programas C ++ válidos existentes que usam staticdeclarações globais. Este código não é apenas formalmente legal, é sólido, pois usa um recurso de linguagem bem definido da forma como deve ser usado .
Só porque agora existe uma "maneira melhor" (de acordo com alguns) de fazer algo não torna os programas escritos à maneira antiga "ruins" ou "irracionais". A capacidade de usar a staticpalavra-chave em declarações de objetos e funções em escopo global é bem compreendida nas comunidades C e C ++ e, na maioria das vezes, usada corretamente.
Na mesma linha, não vou mudar as projeções do estilo C doublepara static_cast<double>apenas porque "as projeções do estilo C são ruins", pois static_cast<double>adiciona zero informação e zero segurança.
A ideia de que sempre que uma nova maneira de fazer algo é inventada, todos os programadores se apressariam em reescrever seu código de trabalho bem definido existente é simplesmente louca. Se você deseja remover toda a feiura e problemas herdados do C, não altere o C ++, mas sim invente uma nova linguagem de programação. Remover pela metade um uso de staticdificilmente torna o C ++ menos feio para C ++.
As mudanças de código precisam de uma justificativa, e "velho é ruim" nunca é uma justificativa para mudanças de código.
Interromper as mudanças de linguagem precisa de uma justificativa muito forte. Tornar a linguagem um pouco mais simples nunca é uma justificativa para uma alteração significativa.
As razões dadas por que staticé ruim são notavelmente fracas, e nem mesmo está claro por que os objetos e as declarações de função não são reprovados juntos - dar a eles um tratamento diferente dificilmente torna o C ++ mais simples ou mais ortogonal.
Então, realmente, é uma história triste. Não por causa das consequências práticas que teve: teve exatamente zero consequências práticas. Mas porque mostra uma clara falta de bom senso do comitê ISO.