最初のエラーの後、CまたはC ++のコンパイルエラーを読みますか？

CおよびC ++コンパイラがエラーから回復して解析を続行しようとする理由を理解できませんでした。ほとんどの場合、最初のエラーは偽のエラーのストリームを生成し、最初のエラーが修正されるとすぐに消えます。数年の経験の後、私はすべてのファイルの最初のエラー以外のエラーを見ることを止めました。コンパイラを再実行し、エラーがなくなるまでもう一度実行します。それは一般的な習慣ですか？

時々、エラーは無関係です。エラーのリストを見て、関連する一連のエラーの根本原因を修正してから、次の関連しないエラーを修正する方が簡単です。プロジェクトが大きく、ビルドに時間がかかる場合は、最初のエラーを修正し、再コンパイルし、繰り返すよりも、この方法で作業する方がイライラすることはありません...

コンパイル時間に依存します。たとえば、プロジェクト全体の再構築をトリガーするマスターヘッダーを変更したことがわかっている場合、残りのエラースタックを詳しく調べて、それらの一部を修正できるかどうかを確認します。これにより、コンパイラーの実行中にコーヒーを作るために立ち上がったときの気持ちが良くなります。

はい、リファクタリングを支援するためにコンパイラを使用していない限り、同じことを行います。その場合、エラーの完全なリストが好きです:)

行番号にギャップがある場合、コンパイラはおそらくなかった回復し、その後、別のエラーを検出しました。

通常は、各束で1つのエラーのみを修正しようとします。

より良いコンパイラーはより良い結果を生み、最初のエラーの後、より良いコードを少なくともチェックできるように、しばしば何らかのエラーの自動修正を通して、より有用なエラーを与えます。しかし、その後、Java、Eclipseでの作業に慣れています。そこでは、構文のタイプミスが即座に検出され、簡単に修正され、他のコンパイラーエラーはより多様で、コンパイラーが回復しやすい傾向があります。MicrosoftのIDEや他のC ++またはC＃で作業している場合にのみ、同様であると想定できます。

はい-または少なくとも私はそれらをスキムします。エラーが関連しているかどうかを判断するのは非常に簡単です（通常は行番号を見るだけで十分です）。1回のパスですべてを修正してから再コンパイルするのが好きです。

1 cppのコンパイルが非常に長い場合にのみ、これを行います（最初のエラーを過ぎたエラーを読み取るため）。または利用できません。次に、コンパイラエラーで最初のエラーとは無関係であると特定できるものをすべて修正したことを確認します。

cppファイルを単独でコンパイルでき、1秒未満で実行できる場合（または、コンパイルが開始される前に「インテリセンス」ポインティングエラーが発生する場合）、ほとんどの場合これを行う必要はありません。

私は現在、1つのcppだけをコンパイルできないプロジェクトに取り組んでおり（また、ビルドシステムを使用できないため、そのO__oを変更できません）、一部のcppファイルはコンパイルに10分以上かかることがあります（それを減らすための多大な努力の後でも、元のコンパイル時間の50％にまで短縮しました...）。

この種の非常に長いコンパイルのセットアップでは、「ビルド」をヒットする前に最初に多くのことを考える傾向があります ...そしてコンパイラーの前にバグを見つけるために多くのことを考えることさえあります。 。

あなたがするように行うことは非常に一般的です。私は通常、インターンまたは初心者のプログラマーに、最初のエラーを除くほとんどすべてのエラーを無視するように、エラーの数に圧倒されていることを伝えます。ほとんどの場合、修正が必要なのは実際のエラーであり、以前のエラーによって引き起こされた誤解を招く幻想エラーではありません。一部の（ほとんどの？）コンパイラには、この理由で最初のエラーの後にコンパイルを停止するオプションがあります。通常、ビルドシステムは、エラーのある最初のファイルの後に停止するように構成できます。

ただし、エラーを検出した後もコンパイルを続行する理由があります。たとえば、エラーのあるファイルの数をカウントしたり、インクルードされたヘッダーファイルが複数のファイルでエラーを引き起こしたかどうかを確認したい場合があります。