これまでの私の経験では、Eclipseのエラー検出は、解決策がないとひどくバグがあります(設定のすべてのポイントの近くで試してみました)__GXX_EXPERIMENTAL_CXX0X__
。私はもう解決策を探したくないという時点にいます。今、私は実際のコンパイラエラーだけを見たいだけです。しかし、これを達成する方法は?-std=c++0x
-std=c++11
5 に答える
更新: 元の回答を投稿してから長い時間が経ち、古くなっています。今日(2014年3月15日)を再確認しました:Eclipse Kepler(ビルドID 20130614-0229)では、
[プロジェクト]>[プロパティ]>[C/ C++ビルド]>[設定]で追加し、[ツール設定]タブ で[ GCCC++コンパイラ]>[その他
-std=c++11
]フラグを追加します。次に、[ウィンドウ]>[設定]>[C / C ++]>[ビルド]>[検出]タブの[設定]で、 [ CDT GCC組み込みコンパイラ設定]を選択し、コマンドに
-std=c++11
フラグを追加してコンパイラ仕様を取得します。私のマシンでは、変更後は次のようになります。${COMMAND} -E -P -v -dD -std=c++11 "${INPUTS}"
Eclipseはエラーメッセージをキャッシュし、設定を変更した後に消えても表示する傾向があるため、プロジェクトとインデックスの両方をクリーンアップして再構築します( [プロジェクト]> [C / C++インデックス]>[再構築])。
これは確かに私のマシンで動作します。それがあなたのものでない場合は、これを試してみることをお勧めします:EclipseでのC ++ 11の完全サポート。ただし、このアプローチの正確さについては確信がなく、自分のマシンで行う必要もありませんでした。2014年3月7日の時点で、ユーザーはそれが彼らを助けたと主張していますが、上記のアプローチはそうではありませんでした。
2012年の元の投稿、現在は古くなっています:
これらの偽のエラーはコーダン
から来ています。バグレポート(C ++ 03 !!!)も発行しましたが、最新の安定版Eclipseでも同じ問題が発生するため、あまり発生していないと思います:(
回避策:
プロジェクトのプロパティをクリックしてから、[ C / C++一般]>[コード分析]>[構文とセマンティックエラー]をクリックし、発生している誤ったエラーの選択を解除します。
実際のコンパイラエラーだけを見たい
もちろん、静的分析を完全に無効にすることもできます。その場合、必要なことを正確に実行できます。
更新: 2人のユーザーが、Jeevakaが書いたことが彼らを助けたと報告しました。私は彼が書いたものを試しましたが、JunoSR1とCDT8.1.1では役に立ちませんでした。おそらく、コーダンの開発者はJunoSR2とCDT8.1.2の静的分析を改善しました
すべての警告も有効にした状態でgccで完全にコンパイルされるc++11コードのCordianエラーに悩まされました。私が考えていることが根本的な原因であることがわかりました。少なくとも私の場合はそうだったのです。c ++ 11のコーディアンエラーに関する他のいくつかの質問は、この質問の複製として閉じられ、この質問を示しています。だから私はここに私の答えを投稿しますが。
これが私が見つけたものです: プロジェクトのプロパティ>C++一般>プリプロセッサ…>エントリ>GNUC ++> CDT GCCビルトインコンパイラ設定には、エントリの1つとして* __ cplusplus =199711L*があります。
次のように変更しました。ウィンドウ>設定>C/ C++>ビルド>設定>検出タブ でCDTGCC組み込みコンパイラ設定を選択し、 $ {COMMAND} -E -P -v -dD${INPUTS}を${COMMANDに変更しました。 } -E -P -v -std = c ++ 11-dD'${INPUTS}'。次に、[適用]をクリックします。次のビルド後にエラーはなくなりました。
私はJunoSR2とCDT8.1.2および手作りのmakeファイルを使用しています。
もう少し色を追加します:
私は専門家ではありませんが、私の場合は次のように思います。
コーディアンは複数の方法でエラーを収集します。
1つは、コンパイラの出力を解析することです。-std=c++11
私のMakefileでは、ターミナルから同じMakefileを呼び出してもエラーのフラグが立てられなかったため、この部分が正しく機能することが保証されました。
もう1つは、「コード分析」によるものです。このため、そしておそらく他のタスクのために、Ecpliseはコンパイラが使用する設定を知る必要があります。Eclipseは、上記で編集したコマンドを呼び出して出力を解析することにより、これらを見つけます。「適用」をクリックする前に「コンソールビューでコンソールを割り当てる」にチェックマークを付けると、このコマンドの出力を表示できます。これらの設定には、インクルードディレクトリと__cplusplusなどの定義が含まれます。これらがMakefileを介して呼び出されたときにgccが使用するものと一致する場合、結果は一貫しています。
ヘッダー内で#pragmaメッセージを使用して問題を実験していたとき、__ GXX_EXPERIMENTAL_CXX0X__が間違っていると思い、これを手動で設定するためのオンラインの提案を見ましたが、それも回避策のようでした。
Eclipseの新規インストールで、1つのマクロをトリガーし、インデックスを再構築すると、次のように解決されました。
[プロジェクト]->[プロパティ]->[プリプロセッサに含まれるもの][GNUC++の選択][CDTの選択]ユーザー設定エントリ[追加]を押します
__cplusplus
名前と値を指定してプリプロセッサマクロを追加します201103L
。
最後に、インデックスを再構築します。(プロジェクト-> C / C++インデックス->再構築)
次の手順に従って、CDTスコープからコードの問題のある部分を削除することもできます。
今、あなたは書くことができます:
#idndef MY_CODAN_MACRO
// this code is visible by compiler only
#else
// this code is visible by code analysis and CDT, but not visible by compiler
#endif
このトリックはIndigo+で可能だと思います。Junoを使用しています。
ずっと前に質問があったことはわかっていますが、問題が解決しないため(Keplerを使用して同じエラーが発生します)、別の可能な回避策を投稿します。
別のソースファイルを作成し、そこで使用したい関数を再定義することができます(一般的な名前空間など)。そのような関数を作成した後
std::string to_string(long long num) {
return std::to_string(num);
}
to_string
そして、メインソースの代わりに使用し始めましstd::to_string
た(私はインクルードで余分なものを追加しました)eclipseはコードをエラーとしてマークしなくなりました。
もちろん、エラーは追加のインクルードでマークされていますが、ロジックが含まれていないため、そこを見ることさえありません。