C / C ++で余分な#includeを検出していますか？

ファイルのヘッダーセクションが常に大きくなるのに、小さくならないことがよくあります。ソースファイルの存続期間を通じて、クラスは移動してリファクタリングされている可能性があり、そこに存在する#includes必要のないものも少なくない可能性があります。それらをそこに残すと、コンパイル時間が長くなり、不要なコンパイル依存関係が追加されます。どれがまだ必要かを理解しようとするのは、かなり退屈な作業です。

不要な#includeディレクティブを検出して、安全に削除できるものを提案できるツールはありますか？
リントは多分これをしますか？

自動ではありませんが、doxygenは#includedファイルの依存関係図を作成します。それらを視覚的に確認する必要がありますが、何が何を使用しているかの画像を取得するのに非常に役立ちます。

Googleのcppclean（リンク先：ダウンロード、ドキュメント）は、C ++の問題のいくつかのカテゴリを見つけることができ、今では余分な#includeを見つけることができます。

これを行うことができるClangベースのツールinclude-what-you-useもあります。include-what-you-useは、前方宣言を提案し（#includeをあまり必要としないため）、オプションで#includesをクリーンアップできます。

Eclipse CDTの現在のバージョンにも、この機能が組み込まれています。[ソース]メニューの下にある[インクルードの整理]をクリックすると、＃includeがアルファベット順に並べられ、Eclipseが使用していると思われるヘッダーが直接追加されずに追加され、ヘッダーがコメント化されます。あなたが必要だとは思わない。ただし、この機能は100％信頼できるわけではありません。

同様の問題を解決するinclude-what-you-useも確認してください。

余分なインクルードを検出する際の問題は、単なる型依存関係チェッカーではないということです。余分は、コンパイルに価値の何も提供していないファイルで含めると、他のファイルが依存して他の項目を変更しません。ヘッダーファイルがコンパイルを変更する方法はたくさんあります。たとえば、定数を定義したり、使用済みのマクロを再定義または削除したり、名前空間を追加して名前の検索を変更したりします。名前空間のようなアイテムを検出するには、プリプロセッサよりもはるかに多くのものが必要ですが、実際には、ほぼ完全なコンパイラが必要です。

Lintはよりスタイルチェッカーであり、確かにこの完全な機能はありません。

不要なインクルードを検出する唯一の方法は、スイートを削除、コンパイル、実行することだと思います。

PCLintでこれができると思っていましたが、これを見てから数年になります。あなたはそれをチェックするかもしれません。

私はこのブログを見て、筆者はPCLintを構成して未使用のインクルードを見つける方法について少し話しました。一見の価値があるかもしれません。

CScoutリファクタリングブラウザは余分検出することができるC（残念ながらいないC ++）コードの指令を含みます。このジャーナルの記事でそれがどのように機能するかの説明を見つけることができます。

単一の#includeディレクティブを消去してプロジェクトをコンパイルし、＃includeに名前を記録する簡単なスクリプトと、コンパイルエラーが発生しなかった場合に削除されたファイルを記述できます。

夜間に実行すると、翌日、削除できるインクルードファイルの100％正しいリストが表示されます。

ときどきブルートフォースが機能するだけです:-)

編集：そしてそれは時々:-)しません。ここにコメントからの情報の少しがあります：

1. 2つのヘッダーファイルを個別に削除できる場合がありますが、両方を一緒に削除することはできません。解決策は、実行中にヘッダーファイルを削除し、元に戻さないことです。これにより、安全に削除できるファイルのリストが見つかりますが、このアルゴリズムでは検出されない、削除するファイルの数が多い解決策があるかもしれません。（これは、削除するインクルードファイルのスペースに対する貪欲な検索です。ローカルの最大値のみを検出します）
2. いくつかの#ifdefsに応じて異なる方法で再定義されたマクロがある場合、動作に微妙な変化が生じる可能性があります。これらは非常にまれなケースだと思います。ビルドの一部である単体テストはこれらの変更をキャッチする必要があります。

ここに（再）投稿して申し訳ありませんが、人々はコメントを展開しないことがよくあります。

crashmstrへの私のコメントを確認してください。FlexeLint/ PC-Lintがこれを行います。情報メッセージ766。マニュアル（バージョン8.0）のセクション11.8.1でこれについて説明しています。

また、これは重要です。メッセージが消えるまで繰り返します。つまり、未使用のヘッダーを削除した後、lintを再実行すると、不要なヘッダーを削除すると、より多くのヘッダーファイルが「不要」になる可能性があります。（ばかげているように聞こえるかもしれませんが、ゆっくり読んで解析してください。理にかなっています。）

私はあなたが求めていることを達成する本格的なツールを見つけたことがありません。私が使用した最も近いものはIncludeManagerです。これは、ヘッダーインクルードツリーをグラフ化するため、1つのファイルにのみ含まれるヘッダーや循環ヘッダーインクルードなどを視覚的に見つけることができます。

Flexelint（UNIX版のPC-Lint）を使用してみましたが、結果はやや複雑でした。これは、私が非常に大きくて節のあるコードベースに取り組んでいるためと考えられます。未使用として報告された各ファイルを注意深く調べることをお勧めします。

主な心配は誤検知です。同じヘッダーの複数のインクルードは、不要なヘッダーとして報告されます。Flexelintは、ヘッダーが含まれている行やヘッダーが以前どこに含まれていたかを通知しないため、これは悪いことです。

自動化ツールがこれを誤る可能性がある方法の1つ：

A.hppの場合：

class A { 
  // ...
};

B.hppの場合：

#include "A.hpp

class B {
    public:
        A foo;
};

C.cppの場合：

#include "C.hpp"  

#include "B.hpp"  // <-- Unneeded, but lint reports it as needed
#include "A.hpp"  // <-- Needed, but lint reports it as unneeded

Flexelintからのメッセージを盲目的にフォローすると、＃includeの依存関係が崩れます。もっと病理的なケースがありますが、基本的には最良の結果を得るために自分でヘッダーを検査する必要があります。

ブログゲームの物理構造とC ++に関するこの記事を内側から強くお勧めします。彼らは#includeの混乱をクリーンアップするための包括的なアプローチを推奨しています：

ガイドライン

これは、ファイル間の物理的な依存関係の数を最小限に抑えるLakosの本からの抜粋した一連のガイドラインです。私はそれらを何年も使用しており、常に結果に本当に満足しています。

1. すべてのcppファイルには、最初に独自のヘッダーファイルが含まれます。[をちょきちょきと切る]
2. ヘッダーファイルには、解析に必要なすべてのヘッダーファイルを含める必要があります。[をちょきちょきと切る]
3. ヘッダーファイルには、それを解析するために必要な最低限の数のヘッダーファイルが必要です。[をちょきちょきと切る]

Eclipse CDTを使用している場合、http：//includator.comを試すことができます（これは、この記事の執筆時点で）ベータテスターに​​は無料であり、不要な#includeを自動的に削除したり、欠落しているものを追加したりできます。FlexeLintまたはPC-Lintを使用していて、Elicpse CDTを使用しているユーザーの場合、http： //linticator.com がオプションになる場合があります（ベータテストも無料）。Lintの分析を使用しながら、余分な#includeステートメントを自動的に削除するためのクイックフィックスを提供します。

この記事では、Doxygenの解析を使用して#includeを削除する手法について説明します。これは単なるperlスクリプトなので、非常に簡単に使用できます。

少し遅いかもしれませんが、私はかつてあなたが望んでいたことを実行するWebKit perlスクリプトを見つけました。私は信じているいくつかの適応が必要になります（私はperlに精通していません）が、それでうまくいくはずです。

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

（トランクにはもうファイルがないため、これは古いブランチです）

Visual Studioに統合できる無料ツールのInclude File Dependencies Watcherがあります。余分な#includeが赤で表示されます。

余分な#includeファイルには2つのタイプがあります。

1. 実際にはモジュール（.c、.cpp）ではまったく必要ないヘッダーファイル
2. ヘッダーファイルはモジュールで必要ですが、直接または間接的に複数回インクルードされています。

私の経験には、それをうまく検出するための2つの方法があります。

• gcc -Hまたはcl.exe / showincludes（問題2を解決）

  実際には、すべてのMakefileがCFLAGSオプションをオーバーライドしない場合は、makeの前にCFLAGS = -Hをエクスポートできます。または、私が使用したように、cc / g ++ラッパーを作成して、$（CC）および$（CXX）の各呼び出しに-Hオプションを強制的に追加できます。ラッパーのディレクトリを$ PATH変数の前に付加すると、makeはすべてラッパーコマンドを代わりに使用します。もちろん、ラッパーは実際のgccコンパイラーを呼び出す必要があります。Makefileが直接gccを使用する場合、このトリックを変更する必要があります。$（CC）または$（CXX）の代わり、または暗黙のルールによる。

  コマンドラインで微調整することにより、単一のファイルをコンパイルすることもできます。ただし、プロジェクト全体のヘッダーをクリーンアップする場合。次の方法ですべての出力をキャプチャできます。

  きれいにする

  make 2>＆1 | Tシャツのresult.txt

• PC-Lint / FlexeLint（1と2の両方で問題を解決）

  + e766オプションを追加してください。この警告は、未使用のヘッダーファイルに関するものです。

  pclint / flint -vf ...

  これにより、pclint出力にヘッダーファイルが含まれ、ネストされたヘッダーファイルは適切にインデントされます。

この議論を終わらせるために：c ++プリプロセッサが完成しつつあります。インクルードが不必要かどうかは、セマンティックプロパティです。したがって、ライスの定理から、インクルードが不必要かどうかは決定できないということになります。インクルードが不要かどうかを（常に正しく）検出するプログラムは存在できません。

これは、余分なヘッダーインクルードを識別する簡単な総当たりの方法です。それは完璧ではありませんが、「明白な」不必要なインクルードを排除します。これらを取り除くことは、コードをクリーンアップするのに大いに役立ちます。

スクリプトは、 GitHubの上で直接アクセスすることができます。

Gimpel SoftwareのPC Lintは、インクルードファイルがコンパイルユニットに2回以上インクルードされたことをレポートできますが、探している方法で不要なインクルードファイルを見つけることができません。

編集：できます。itsmattの答えを見てください

JetBrainsのC / C ++ IDEであるCLionは、冗長なインクルードをすぐに検出します。これらはエディターではグレー表示されますが、現在のファイルまたはプロジェクト全体のインクルードを最適化する関数もあります。

ただし、この機能は有料であることがわかりました。CLionが最初にロードされたとき、プロジェクトのスキャンと分析にしばらく時間がかかります。