Eu tenho um projeto que usa as bibliotecas log4cxx, boost, etc. cujos cabeçalhos geram muitos avisos (repetitivos). Existe uma maneira de suprimir avisos de inclusões de biblioteca (por exemplo, #include <some-header.h>) ou inclusões de determinados caminhos? Eu gostaria de usar -Wall e / ou -Wextra como de costume no código do projeto sem que as informações relevantes sejam ocultadas. Atualmente, uso grep no make output, mas gostaria de algo melhor.
Você pode tentar incluir cabeçalhos de biblioteca usando em -isystemvez de -I. Isso os tornará "cabeçalhos do sistema" e o GCC não relatará avisos para eles.
Se você estiver tentando fazer isso no XCode, cole o caminho do sistema nos "outros sinalizadores do C ++" nos "sinalizadores do compilador personalizado" nas configurações de construção de destino.
Uma desvantagem potencial é que, em algumas plataformas, o g ++ envolve automaticamente todos os cabeçalhos do sistema extern "C", causando erros estranhos na ligação C se você tiver #includeum cabeçalho C ++ em um -isystemcaminho.
+1 me ajudou a resolver problemas com irritantes impulso avisos stackoverflow.com/questions/35704753/warnings-from-boost
Por que isso tem muito mais votos do que a resposta do OP que disse exatamente a mesma coisa 1,5 horas antes?
Para Xcode: E se não houvesse um caminho de pasta em "Outros sinalizadores de C ++" nas minhas configurações de criação de destino? Alguém poderia elaborar essas soluções?
— Ossir
Para aqueles que usam o CMake, você pode modificar suas include_directoriesdiretivas para incluir o símbolo SYSTEMque suprime avisos contra esses cabeçalhos.
E se a biblioteca fornecer uma ${LIBFOO_USE_FILE}variável que será usada com o comando include () do CMake ?
— 21816 Waldyrious #
Esta parece ser quase a solução para o meu problema. Eu tenho 1.) um destino binário, que depende de 2.) um cabeçalho apenas alvo escrito por mim, que depende de 3.) algumas bibliotecas externas. Não faço ideia de como obter apenas avisos para 1 e 2. Você tem alguma ideia?
Não parece funcionar. Eu tentei isso com um projeto que usa easylogging++e recebo a mesma quantidade enorme de avisos, easylogging++.hmesmo que a pasta em que ele reside tenha sido incluída com a SYSTEMopção.
— Rbaleksandar #
Muito obrigado por isso. Ele me salvou de páginas e páginas de avisos.
— Svalorzen 21/03
O mesmo comentário da resposta aceita: essa é uma prática ruim para mim.
Disponível apenas com GCC> = 4.6
— Caduchon
Eu estou amando a capacidade de empurrar / pop pragmas. Lembro-me de algo como java disponível há alguns anos e estar frustrado / com ciúmes de C / C ++. eu amo que isso esteja disponível em #gcc
@TrevorBoydSmith MS também cltem capacidade há anos ... Às vezes gccé um pouco lento para se adaptar.
Eu encontrei o truque. Para biblioteca inclui, em vez de -Idirusar -isystem dirno makefile. O GCC trata o impulso etc., pois o sistema inclui e ignora todos os avisos deles.
Observe que, se você usar o cabeçalho pré-compilado, precisará adicionar o sinalizador ao compilar o cabeçalho e o código.
#pragmasão instruções para o compilador. você pode definir algo antes do #include e desabilitá-lo depois.
Eu optaria pela opção de usar # pragma's no código-fonte e, em seguida, fornecer uma boa razão (como um comentário) do motivo pelo qual você está desativando os avisos. Isso significaria raciocínio sobre os arquivos de cabeçalho.
O GCC aborda isso classificando os tipos de aviso. Você pode classificá-los como avisos ou a serem ignorados. Os artigos vinculados anteriormente mostrarão quais avisos podem ser desativados.
Nota: você também pode massagear o código fonte para evitar certos avisos usando atributos ; no entanto, isso o vincula bastante ao GCC.
Nota2: O GCC também usa a interface pop / push, conforme usada no compilador da microsoft - a Microsoft desativa os avisos por essa interface. Sugiro que você investigue mais, pois não sei se é possível.
Eu considerei pragmas, mas se eu suprimir um aviso antes de incluir um cabeçalho, como faço para configurá-lo de volta ao estado anterior após #include? Quero ver todos os avisos para o código do projeto (já me ajudou algumas vezes), mas tenho controle na linha de comando.
Você pode tentar usar cabeçalhos pré-compilados . Os avisos não desaparecem, mas pelo menos os não aparecem na sua compilação principal.
Isso pode realmente ser uma boa ideia. As inclusões de terceiros não mudam todos os dias.
Exatamente. Embora eu não os tenha usado tanto no Linux, eles funcionam muito bem no Visual Studio.
Não, eles ainda vão aparecer na compilação menos que você use alguma outra maneira de suprimi-los (tais como -isystem, mas não se esqueça de usá-lo tanto na compilação do cabeçalho e no código)
Se você precisar substituir explicitamente um cabeçalho do sistema, estará restrito a pragmas. Você pode verificar qual inclui o que está usando via make dependsaída.
Consulte também push-pop de diagnóstico para gcc> = 4.6
— supaflav
Colocando o seguinte
desativará os avisos do GCC para todos os códigos a seguir neste arquivo.
Deve haver razões para esses avisos. Isso será causado por erros no seu código que usa a biblioteca ou por erros no próprio código da biblioteca. No primeiro caso, corrija seu código. No segundo caso, pare de usar a biblioteca ou, se for o código FOSS, corrija-o.
+1 para um bom conselho: D, mas ele está perguntando como fazer algo específico: D
Alguns avisos são impossíveis ou muito difíceis de corrigir, especialmente em códigos de terceiros, especialmente em códigos ricos em metaprogramações como os do Boost.
Pior ainda, o que está me incomodando é "a declaração de 'c' sombreia um membro 'this' [-Werror = shadow]" profundamente, profundamente em algum cabeçalho de impulso. Isso certamente não é um problema, mas problemas semelhantes estão divulgando resultados e tornando difícil para mim encontrar instâncias uma verdadeira sombra em nossa base de código.