CDTを使用したEclipse3.7.0 Indigoは、多くの誤ったコンパイルエラーを示します
Ubuntuボックスを11.10に更新した後、EclipseもCDT8.0.1で3.7.0Indigoに更新しました。
次に、次の問題が発生します。
ベクトルヘッダーファイルをインクルードしましたが、コンパイラーはSymbol 'vector' could not be resolvedと言いました。 #define int Comparableも定義しましたが、EclipseはSymbol 'Comparable' could not be resolvedなども言いました。
多くのエラーが発生しますが、コンパイルは正常に終了しました。
G ++を使用してコードをコンパイルしようとしましたが、問題はありませんでした。
Eclipseがクラッシュするたびに、VMまたはコンピューター、あるいはほんの数か月の開発でさえ、Eclipseがすべてを格納するワークスペースの安定性が損なわれ始めます。
<workspace dir>\.metadataディレクトリを確認して、Eclipseが生成してワークスペースに保存する量を確認してください。プラグインを追加するたびに、プラグインをアップグレードし、ワークスペースに情報を配置および変更するプラグインを削除します。
証拠は、この問題は通常、Eclipseをアップグレードした直後に発生することです。 （私の場合はインディゴ）。
ほこりっぽいワークスペースを修正する最も簡単な方法は、Eclipse.exe実行可能ファイルへの -clean コマンドライン引数を使用することです。
Eclipseヘルプドキュメントは、このコマンドの機能を教えてくれます。
「true」に設定すると、OSGiフレームワークとEclipseランタイムで使用されるキャッシュデータはすべて消去されます。これにより、バンドルの依存関係の解決とEclipse拡張レジストリデータの保存に使用されるキャッシュがクリーンアップされます。このオプションを使用すると、Eclipseはこれらのキャッシュを再初期化します。
-cleanコマンドライン引数を使用する方法は3つあります。
- にあるEclipse.iniファイルを編集し、最初の行の最初の引数として追加します。
- Eclipseの起動に使用するショートカットを編集し、それを最初の引数として追加します。
-clean引数を使用してEclipse実行可能ファイルを呼び出すバッチまたはシェルスクリプトを作成します。
手順3の利点は、スクリプトを保持して、ワークスペースをクリーンアップするたびに使用できることです。
これ ページ 私に問題を解決しました！それが他のみんなを助けることができることを願っています。
問題は、インデクサーの観点から欠落しているインクルードディレクトリがたくさんあることです。
以下を追加することは私にとってはうまくいきましたが、それらが実際に存在する特定の設定に依存する可能性があります。
/usr/include/c++/4.6.1
/usr/include/
/usr/include/c++
/usr/include/c++/4.6
/usr/include/x86_64-linux-gnu
/usr/include/asm-generic
/usr/include/c++/4.6.1/x86_64-linux-gnu/
Project>Properties>C++ Include Pathsで設定できます
おそらく、将来的には、CDTのプラットフォームスペシャライゼーションにこれらが自動的に含まれるようになるでしょう。どこかで読んだことを思い出しますが、参考にはなりません。
プロジェクトのプロパティで、[C/C++ビルド]> [ツールチェーンエディター]に移動し、[互換性のあるツールチェーンのみを表示する]にチェックマークを付け、[Linux GCC]を選択して、[適用]ボタンをクリックします。
ここで、C\C++ General> Paths and Symbolsに移動すると、追加されたインクルードパスの新しいリストが表示されます。インデックスを再構築すると、エラーメッセージが消えるはずです。
C++プロジェクト（私の場合は既存のコードから）を作成するときは、「インデクサー設定のツールチェーン」を使用するコンパイラー（私の場合は「GNUAutotoolsツールチェーン」）に設定する必要があります。この後、「パスとシンボル」は、コンパイラのインクルードファイルへの正しいパスを表示します。バグは消えます。この設定は、プロジェクトの作成中にのみ役立ちました。後で設定しても効果はありませんでした。
Indigo 3.7.2バージョン（およびそれ以降）では、インデックスの再作成後に変更を有効にすることができます。 Eclipseは「インデックスの再作成」を要求します。下位バージョンでは、ヘッダータグなどを手動で再インデックス化する必要があります。
アクティブなビルド構成に更新されたインデックスオプションは私のために機能します、
また、事前にインデックスが作成されているファイルリストからいくつかのファイルを削除しました。
コード分析がこれを引き起こしています。実際にコードをコンパイルするのではなく、迅速なフィードバックのために静的チェックを行うだけです。残念ながら、修正方法がわかりません。無効にしただけです。申し訳ありませんが、私は仕事をしているので、目の前にCDTはありませんが、次のようなものだと思います。
Window > Preferences > C++ General > Code Analysis
そこに移動し、すべてのチェックボックスをオフにして無効にします。
これが私のために働いたものです：
インクルードパスから作成したヘッダーファイルへのパスを削除しました
プロジェクトをコンパイルしました（ユーザー定義のヘッダーがないため、コンパイラーは明らかに文句を言います）
作成したヘッダーファイルへのパスを再挿入しました
プロジェクトを再度コンパイルしました-完全に機能しました
ケースを説明することはできません:(
これが私の問題に最も近い質問なので、私はここで答えています。
QT EclipseとHelios（3.6.2）の統合を使用しましたが、大きな問題はありませんでした。 c：\ mingwにインストールしたmingw4.6.2を使用していました。 Indigoにアップグレードしたかったので、CDTで発生していたいくつかの小さな問題が修正されました。
ただし、Indigo（3.7 SR2）では、Eclipseは、次のような未解決の機能として、些細な機能に下線を引き始めました。
function 'fprintf' could not be resolved
function 'memset' could not be resolved
#includeに下線が引かれていなくても、開くことができ、ヘッダーにfprintfが含まれていました。そして、コード自体は正常にコンパイルされましたが。
ヘリオスに戻ると、問題は解決しました。
インデックスを付け直してみましたが、役に立ちませんでした。インクルードパスを確認したところ、次のようになりました。
c:\mingw\include
C:\MinGW\lib\gcc\mingw32\4.6.2\include
最初は、最初のものを含めたばかりでしたが、2番目のものは含めませんでした。しかし、「未解決のインクルード」を検索したところ、stdio.hにはmingwのメインインクルードフォルダーにないstdarg.hが含まれていたため、2番目を追加しました。しかし、それでも、printfは解決されず、「未解決のインクルード」はもうありませんでした。
1つのクラスで新しいC++プロジェクトを作成しました。 stdio.h、上記のパス、およびfprintfの呼び出しを追加しました。下線が引かれました！ stdioの他のものには下線が引かれていませんでしたが。
これで、Qtの問題だけではないことがわかりました。
インクルードパスを削除してコンパイルすることを提案するここの一番下の投稿を読む前に、私はしばらくこれに取り組みました。私はそれがうまくいくとは思っていませんでしたが、それを試してみました。驚くべきことに、コンパイルが失敗したにもかかわらず、エラーはなくなりました！
そのとき、インクルードパスをもう一度確認しました。これらは、コンパイル手順によって次のように更新されていました。
c:/mingw/lib/gcc/mingw32/4.6.2/include-fixed
c:/mingw/include
c:/mingw/lib/gcc/mingw32/4.6.2/include
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/backward
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++/mingw32
c:/mingw/lib/gcc/mingw32/4.6.2/include/c++
これらは「組み込み」値としてマークされていました。これは、これらが私によって追加されたものではなく、次にビルドを実行したときに更新される可能性があることを意味すると思います。
したがって、Eclipseが未解決のインクルードであると検出しなくても、mingwの下にすべてのインクルードパスを含めるという教訓があると思います。
次のステップは、これらすべてのパスをQtプロジェクトに入れることでした。残念ながら、そうした後、未解決の関数はまだそこにありました。 Qt C/C++インクルードパスには、CDT C/C++インクルードパスとは異なる何らかのバグがあるようです。