Como devo detectar arquivos #include desnecessários em um grande projeto C ++?

Estou trabalhando em um grande projeto C ++ no Visual Studio 2008 e há muitos arquivos com #includediretivas desnecessárias . Às vezes, os #includes são apenas artefatos e tudo irá compilar bem com eles removidos e, em outros casos, as classes podem ser declaradas e o #include pode ser movido para o .cpparquivo. Existem boas ferramentas para detectar esses dois casos?

Embora não revele arquivos de inclusão desnecessários, o Visual Studio tem uma configuração /showIncludes(clique com o botão direito em um .cpparquivo Properties->C/C++->Advanced) que produzirá uma árvore de todos os arquivos incluídos no momento da compilação. Isso pode ajudar a identificar arquivos que não deveriam ser incluídos.

Você também pode dar uma olhada no idioma pimpl para permitir que você escape com menos dependências de arquivo de cabeçalho para tornar mais fácil ver a sujeira que você pode remover.

PC Lint funciona muito bem para isso e também encontra todos os tipos de problemas idiotas para você. Ele tem opções de linha de comando que podem ser usadas para criar Ferramentas Externas no Visual Studio, mas descobri que o suplemento Visual Lint é mais fácil de trabalhar. Até a versão gratuita do Visual Lint ajuda. Mas dê uma chance ao PC-Lint. Configurá-lo de forma que não emita muitos avisos leva um pouco de tempo, mas você ficará surpreso com o que acontece.

Há uma nova ferramenta baseada no Clang, inclua o que você usa , que tem como objetivo fazer isso.

!!AVISO LEGAL!! Eu trabalho em uma ferramenta comercial de análise estática (não PC Lint). !!AVISO LEGAL!!

Existem vários problemas com uma abordagem simples de não análise:

1) Conjuntos de sobrecarga:

É possível que uma função sobrecarregada tenha declarações provenientes de arquivos diferentes. Pode ser que a remoção de um arquivo de cabeçalho resulte na escolha de uma sobrecarga diferente, em vez de um erro de compilação! O resultado será uma mudança silenciosa na semântica que pode ser muito difícil de rastrear depois.

2) Especializações de modelo:

Semelhante ao exemplo de sobrecarga, se você tiver especializações parciais ou explícitas para um modelo, deseja que todas elas fiquem visíveis quando o modelo for usado. Pode ser que as especializações para o modelo principal estejam em arquivos de cabeçalho diferentes. Remover o cabeçalho com a especialização não causará um erro de compilação, mas pode resultar em um comportamento indefinido se a especialização tivesse sido selecionada. (Veja: Visibilidade da especialização de template da função C ++ )

Conforme apontado por 'msalters', realizar uma análise completa do código também permite a análise do uso da classe. Ao verificar como uma classe é usada através de um caminho específico de arquivos, é possível que a definição da classe (e, portanto, todas as suas dependências) possa ser removida completamente ou pelo menos movida para um nível mais próximo da fonte principal no include árvore.

Não conheço nenhuma dessas ferramentas e já pensei em escrever uma, mas descobri que esse é um problema difícil de resolver.

Digamos que seu arquivo de origem inclua ah e bh; ah contém #define USE_FEATURE_Xe bh usa #ifdef USE_FEATURE_X. Se #include "a.h"estiver comentado, seu arquivo ainda pode compilar, mas pode não fazer o que você espera. Detectar isso programaticamente não é trivial.

Qualquer ferramenta que faça isso também precisará conhecer seu ambiente de construção. Se ah se parece com:

#if defined( WINNT )
   #define USE_FEATURE_X
#endif

Então, USE_FEATURE_Xsó é definido se WINNTfor definido, de modo que a ferramenta precisaria saber quais diretivas são geradas pelo próprio compilador, bem como quais são especificadas no comando de compilação em vez de em um arquivo de cabeçalho.

Como Timmermans, não estou familiarizado com nenhuma ferramenta para isso. Mas conheço programadores que escreveram um script Perl (ou Python) para tentar comentar cada linha de inclusão, uma de cada vez, e depois compilar cada arquivo.

Parece que agora Eric Raymond tem uma ferramenta para isso .

O cpplint.py do Google tem uma regra "inclua o que você usa" (entre muitas outras), mas, pelo que posso dizer, não "inclua apenas o que você usa". Mesmo assim, pode ser útil.

Se você estiver interessado neste tópico em geral, pode dar uma olhada no design de software C ++ em grande escala de Lakos . É um pouco desatualizado, mas envolve muitos problemas de "design físico", como encontrar o mínimo absoluto de cabeçalhos que precisam ser incluídos. Eu realmente não vi esse tipo de coisa sendo discutido em nenhum outro lugar.

Experimente o Include Manager . Ele se integra facilmente ao Visual Studio e visualiza seus caminhos de inclusão, o que ajuda a encontrar coisas desnecessárias. Internamente, ele usa o Graphviz, mas há muitos outros recursos interessantes. E embora seja um produto comercial tem um preço muito baixo.

Você pode construir um gráfico de inclusão usando o Observador de dependências de arquivo de inclusão C / C ++ e localizar inclusões desnecessárias visualmente.

Se seus arquivos de cabeçalho geralmente começam com

#ifndef __SOMEHEADER_H__
#define __SOMEHEADER_H__
// header contents
#endif

(ao contrário de usar # pragma uma vez), você pode alterar para:

#ifndef __SOMEHEADER_H__
#define __SOMEHEADER_H__
// header contents
#else 
#pragma message("Someheader.h superfluously included")
#endif

E uma vez que o compilador mostra o nome do arquivo cpp sendo compilado, isso permitiria que você soubesse pelo menos qual arquivo cpp está fazendo com que o cabeçalho seja trazido várias vezes.

O PC-Lint pode realmente fazer isso. Uma maneira fácil de fazer isso é configurá-lo para detectar apenas arquivos de inclusão não utilizados e ignorar todos os outros problemas. Isso é bastante simples - para ativar apenas a mensagem 766 ("Arquivo de cabeçalho não usado no módulo"), apenas inclua as opções -w0 + e766 na linha de comando.

A mesma abordagem também pode ser usada com mensagens relacionadas, como 964 ("Arquivo de cabeçalho não usado diretamente no módulo") e 966 ("Arquivo de cabeçalho incluído indiretamente não usado no módulo").

FWIW Escrevi sobre isso com mais detalhes em uma postagem do blog na semana passada em http://www.riverblade.co.uk/blog.php?archive=2008_09_01_archive.xml#3575027665614976318 .

Se você está procurando remover #includearquivos desnecessários para diminuir os tempos de compilação, seu tempo e dinheiro podem ser melhor gastos paralelizando seu processo de compilação usando cl.exe / MP , make -j , Xoreax IncrediBuild , distcc / icecream , etc.

Claro, se você já tem um processo de construção paralelo e ainda está tentando acelerá-lo, limpe suas #includediretivas e remova as dependências desnecessárias.

Comece com cada arquivo de inclusão e certifique-se de que cada arquivo de inclusão inclui apenas o que é necessário para compilar a si mesmo. Todos os arquivos de inclusão que estão faltando para os arquivos C ++ podem ser adicionados aos próprios arquivos C ++.

Para cada arquivo de inclusão e fonte, comente cada arquivo de inclusão, um de cada vez, e veja se ele compila.

Também é uma boa ideia classificar os arquivos de inclusão em ordem alfabética e, onde isso não for possível, adicione um comentário.

Adicionar um ou ambos os #defines a seguir excluirá arquivos de cabeçalho frequentemente desnecessários e pode melhorar substancialmente os tempos de compilação, especialmente se o código não estiver usando funções da API do Windows.

#define WIN32_LEAN_AND_MEAN
#define VC_EXTRALEAN

Veja http://support.microsoft.com/kb/166474

Se ainda não o fez, usar um cabeçalho pré-compilado para incluir tudo o que você não vai alterar (cabeçalhos de plataforma, cabeçalhos de SDK externos ou partes estáticas já concluídas de seu projeto) fará uma grande diferença nos tempos de compilação.

http://msdn.microsoft.com/en-us/library/szfdksca(VS.71).aspx

Além disso, embora possa ser tarde demais para o seu projeto, organizá-lo em seções e não agrupar todos os cabeçalhos locais em um grande cabeçalho principal é uma boa prática, embora exija um pouco de trabalho extra.

Se você trabalhar com o Eclipse CDT, experimente http://includator.com para otimizar sua estrutura de inclusão. No entanto, o Includator pode não saber o suficiente sobre as inclusões predefinidas do VC ++ e a configuração do CDT para usar o VC ++ com as inclusões corretas ainda não está incorporada ao CDT.

O IDE Jetbrains mais recente, CLion, mostra automaticamente (em cinza) os includes que não são usados ​​no arquivo atual.

Também é possível ter a lista de todos os includes não utilizados (e também funções, métodos, etc ...) do IDE.

Algumas das respostas existentes afirmam que é difícil. Isso é realmente verdade, porque você precisa de um compilador completo para detectar os casos em que uma declaração de encaminhamento seria apropriada. Você não pode analisar C ++ sem saber o que os símbolos significam; a gramática é simplesmente ambígua demais para isso. Você deve saber se um determinado nome nomeia uma classe (pode ser declarada para frente) ou uma variável (não pode). Além disso, você precisa estar ciente do namespace.

Talvez um pouco tarde, mas uma vez encontrei um script perl WebKit que fazia exatamente o que você queria. Vai precisar de alguma adaptação, acredito (não sou muito versado em perl), mas deve servir:

http://trac.webkit.org/browser/branches/old/safari-3-2-branch/WebKitTools/Scripts/find-extra-includes

(este é um ramo antigo porque o tronco não tem mais o arquivo)

Se houver um cabeçalho específico que você acha que não é mais necessário (digamos string.h), você pode comentar esse include e colocá-lo abaixo de todos os includes:

#ifdef _STRING_H_
#  error string.h is included indirectly
#endif

É claro que os cabeçalhos de sua interface podem usar uma convenção #define diferente para registrar sua inclusão na memória do CPP. Ou nenhuma convenção; nesse caso, essa abordagem não funcionará.

Em seguida, reconstrua. Existem três possibilidades:

• Ele constrói ok. string.h não era crítico de compilação e a inclusão para ele pode ser removida.

• As viagens #error. string.g foi incluído indiretamente de alguma forma Você ainda não sabe se string.h é necessário. Se for necessário, você deve # incluí-lo diretamente (veja abaixo).

• Você obtém algum outro erro de compilação. string.h era necessário e não está sendo incluído indiretamente, portanto, a inclusão estava correta para começar.

Observe que, dependendo da inclusão indireta quando seu .h ou .c usa diretamente outro .h, é quase certo que é um bug: você está prometendo que seu código só exigirá aquele cabeçalho, desde que algum outro cabeçalho que você esteja usando o exija, o que provavelmente não é o que você quis dizer.

As advertências mencionadas em outras respostas sobre cabeçalhos que modificam o comportamento em vez de declarar coisas que causam falhas de compilação também se aplicam aqui.