22

これまでの私の経験では、Eclipseのエラー検出は、解決策がないとひどくバグがあります(設定のすべてのポイントの近くで試してみました)__GXX_EXPERIMENTAL_CXX0X__。私はもう解決策を探したくないという時点にいます。今、私は実際のコンパイラエラーだけを見たいだけです。しかし、これを達成する方法は?-std=c++0x-std=c++11

4

5 に答える 5

20

更新: 元の回答を投稿してから長い時間が経ち、古くなっています。今日(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の静的分析を改善しました

于 2012-11-19T19:39:03.033 に答える
6

すべての警告も有効にした状態で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__が間違っていると思い、これを手動で設定するためのオンラインの提案を見ましたが、それも回避策のようでした。

于 2013-03-12T06:39:41.613 に答える
6

Eclipseの新規インストールで、1つのマクロをトリガーし、インデックスを再構築すると、次のように解決されました。

[プロジェクト]->[プロパティ]->[プリプロセッサに含まれるもの][GNUC++の選択][CDTの選択]ユーザー設定エントリ[追加]を押します

__cplusplus名前と値を指定してプリプロセッサマクロを追加します201103L

最後に、インデックスを再構築します。(プロジェクト-> C / C++インデックス->再構築)

于 2014-03-14T14:28:59.080 に答える
1

次の手順に従って、CDTスコープからコードの問題のある部分を削除することもできます。

  • [プロジェクトのプロパティ]->[C/ C++一般]->[プリプロセッサインクルードパス]、[マクロ]などに移動します
  • [エントリ]タブで目的の言語を選択します
  • 追加->プリプロセッサマクロ
  • 名前「MY_CODAN_MACRO」と値「1」を入力します
  • 今、あなたは書くことができます:

    #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を使用しています。

    于 2013-10-09T20:24:09.880 に答える
    -1

    ずっと前に質問があったことはわかっていますが、問題が解決しないため(Keplerを使用して同じエラーが発生します)、別の可能な回避策を投稿します。

    別のソースファイルを作成し、そこで使用したい関数を再定義することができます(一般的な名前空間など)。そのような関数を作成した後

    std::string to_string(long long num) {
        return std::to_string(num);
    }
    

    to_stringそして、メインソースの代わりに使用し始めましstd::to_stringた(私はインクルードで余分なものを追加しました)eclipseはコードをエラーとしてマークしなくなりました。

    もちろん、エラーは追加のインクルードでマークされていますが、ロジックが含まれていないため、そこを見ることさえありません。

    于 2013-08-21T05:04:12.980 に答える