Quais são as características C99 são considerados prejudiciais ou não suportado [fechado]
-
19-09-2019 - |
Pergunta
Eu costumo código C escrever em C89, agora algumas características do C99 (como intxx_t
ou __VA_ARGS__
ou snprintf
) são muito úteis, e pode ser até mesmo vital.
Antes de mais os meus requisitos de C89 a C99 Eu queria saber qual das características C99 foram amplamente apoiadas e quais não foram amplamente apoiada ou mesmo considerado prejudicial.
Eu sei que poderia simplesmente verificar o nosso suporte de compilador alvo, mas isso iria diminuir o nosso apoio muito, e como este é para software de código aberto, eu prefiro ter um apoio mais amplo.
Por exemplo, usamos Solaris compilador (suncc) e gcc, mas pode haver outro compilador que iria se mover para fora do caminho, enquanto poderíamos manter a compatibilidade com muito pouco esforço.
Por exemplo, eu nunca trabalhei no Windows nem eu sei nada sobre compiladores Windows, mas seria bom para manter a compatibilidade do Windows.
Solução
Uma série de características C99 são opcionais, pelo que a sua falta não é tecnicamente não-conforme. Não vou distinguir abaixo.
-
Hmm, vitória não tem
<stdint.h>
, embora haja um aberto versão -source de stdint.h para Microsoft . Mesmo quando o arquivo for implementado, muitos dos tipos individuais estão faltando. -
Suporte Complex e imaginário é muitas vezes ausente ou quebrado.
-
identificadores estendidos e caracteres largos podem ser pontos de problema.
Outras dicas
goto
ainda é considerado prejudicial.
De alguma forma eu ter recolhido quatro down votos. I apresentado a declaração acima para adicionar leveza, e estou apenas 30% sério sobre o conceito por trás dele.
Espero que os abaixo votos são de jovens que não entendem a história das linguagens de programação. Não cada goto
é mau, mas, em comparação com código espaguete adulterado 100% Eu tenho trabalhado em (milhões de linhas de Fortran 66) -é razoável e produtiva para substituir o maior número de declarações goto
com declarações estruturados (for
, while
, do .. while
, switch
) quanto possível. Mas às vezes uma goto
é muito bem quando se evita a complexidade, tais como variáveis ??bandeira extras para sair de vários loops aninhados.
Bem, gcc é basicamente vai ser gcc independentemente de qual sistema operacional de desktop que você está alvejando.
Visual C ++, sendo principalmente um compilador C ++, não está tão preocupado com a especificação C99. stdint.h faz declarar suas macros intxx_t favoritas. __VA_ARGS__
está disponível. _Bool, _Complex e _Pragma não são implementadas no compilador Microsoft Visual C ++. Tenho certeza% de campos em printf / scanf não foram implementados, embora talvez VC2010 lida com elas. snprintf está presente, mas tem um sublinhado à esquerda e semântica ligeiramente diferente.
resposta curta: O "mais fácil" uma característica C99 é implementar sem alterar gramáticas compilador ou replumbing a biblioteca padrão, o mais provável VC ++ é para apoiá-lo. Se houver um conflito entre C99 e C ++, esperam C ++ para ganhar.
Runtime sizeof é um pesadelo de escritores de compilador. Então eu considero é prejudicial.
glibc não implementar um realloc
C99-conformes, então realloc(ptr, 0)
não é portátil.
restrict
tornou-se uma palavra-chave no C99. Que está invadindo a implementação de namespace dos usuários. Se você tem um programa de C89 válido que contém a palavra restrict
, você deve alterar o seu programa para fazê-lo funcionar com C99. Em outras palavras: não há compatibilidade com versões anteriores. Se eles estavam indo para quebrar compatibilidade com versões anteriores, eles devem ter gets
removido do primeiro padrão.
O tipo de matemática funções genéricas de <tgmath.h>
não são necessariamente amplamente implementado, embora eles parecem ser fornecido com GCC 4.2.1 em MacOS X 10.6.2.