CおよびC++コンパイラがエラーから回復して解析を続行しようとする理由を理解できませんでした。ほとんどの場合、最初のエラーは偽のエラーのストリームを生成し、最初のエラーが修正されるとすぐに消えます。数年の経験の後、すべてのファイルの最初のエラー以外のエラーを見ることをやめました。コンパイラを再実行し、エラーがなくなるまでそれを繰り返します。それは一般的な習慣ですか?
時々、エラーは無関係です。エラーのリストを確認し、一連の関連エラーの根本原因を修正してから、次のn関連エラーを修正する方が簡単だと思います。プロジェクトが大きく、ビルドに時間がかかる場合、この方法で作業すると、最初のエラーを修正し、再コンパイルし、繰り返すよりもイライラしません...
コンパイル時間によって異なります。たとえば、プロジェクト全体の再ビルドをトリガーするマスターヘッダーを変更したことがわかっている場合は、残りのエラースタックを詳しく調べて、それらのいくつかを修正できるかどうかを確認します。コンパイラーの実行中にコーヒーを作るために立ち上がるとき、それは私に良い感じを与えます。
はい私は同じことをしますが、リファクタリングを助けるためにコンパイラを使用しているのでない限り、エラーの完全なリストが好きです:)
行番号にギャップがある場合、コンパイラーはおそらくdidリカバリーしてから、別のエラーを検出しました。
通常は、各束で1つのエラーのみを修正しようとします。
優れたコンパイラーは、より良い結果を生成し、最初のエラーの後により多くの有用なエラーを提供します。多くの場合、エラーの何らかの自動修正を通じて、おそらく良いコードを少なくともチェックできるようにします。しかし、私はJavaやEclipseでの作業に慣れています。そこでは、構文のタイプミスが即座に検出され、簡単に修正されます。他のコンパイラエラーは、コンパイラがより多様で簡単に回復できる傾向があります。 MicrosoftのIDEやその他のC++またはC#で作業する場合も同様であると想定できます。
はい-または少なくとも私はそれらをすくいます。エラーが関連しているかどうか(通常は行番号を確認するだけで十分かどうか)を判断するのは非常に簡単で、すべてを1つのパスで修正してから再コンパイルするのが好きです。
1 cppのコンパイルが非常に長い場合にのみ、これを実行します(最初のエラーの過去のエラーを読み取るため)。または利用できません。次に、コンパイラエラーで特定できるすべてのものが最初のエラーとは無関係であると修正したことを確認します。
Cppファイルを単独でコンパイルして1秒未満で実行できる場合(またはコンパイルを開始する前に「インテリセンス」のポインティングエラーが発生した場合)、ほとんどの場合これを実行する必要はありません。
私は現在、1つのcppだけをコンパイルできないプロジェクトで作業しています(そして、ビルドシステムを手に持っていないため、O__oを変更できません)。一部のcppファイルは、コンパイルに10分以上かかる場合があります(それを減らすために多くの努力をした後でも、私たちはそれを元のコンパイル時間の50%だけに削減しました...)。
この種の非常に長いコンパイル設定では、 "ビルド"を押す前に最初に多くのことを考える傾向があります ...そして、コンパイラの前にバグを見つけるために、多くのことをよく考えます。それらよりも精神的にそれらを取得するために高速。