Lisez-vous les erreurs de compilation C ou C ++ après la première?

Je n'ai jamais compris pourquoi les compilateurs C et C ++ tentent de récupérer des erreurs et de continuer l'analyse. Presque toujours, la première erreur génère un flux d'erreurs fausses qui disparaissent dès que la première est corrigée. Après plusieurs années d'expérience, j'ai tout simplement arrêté de regarder toute erreur, sauf la première de chaque fichier. Je réexécute le compilateur, puis je recommence jusqu'à ce qu'il n'y ait plus d'erreurs. Est-ce une pratique courante?

Parfois, les erreurs ne sont pas liées. Je trouve plus facile de consulter une liste d'erreurs et de corriger la cause première d'une série d'erreurs liées, puis de corriger la prochaine erreur non liée. Si le projet est volumineux et prend du temps à construire, je trouve que travailler de cette manière est moins frustrant que corriger la première erreur, recompiler, répéter ...

Cela dépend du temps de compilation . Par exemple, si je sais que je viens de changer un en-tête principal qui déclenchera une reconstruction de l'ensemble du projet, je vais certainement regarder de plus près le reste de la pile d'erreurs et voir si je peux corriger certains d'entre eux. Cela me donne une meilleure sensation lorsque je me lève pour faire du café pendant que le compilateur fonctionne.

Oui, je fais de même, sauf si j'utilise le compilateur pour m'aider à refactoriser auquel cas j'aime la liste complète des erreurs :)

S'il y a un écart dans les numéros de ligne, le compilateur probablement ne récupérer et a trouvé une autre erreur.

Cependant, n'essayez généralement de corriger qu'une seule erreur dans chaque groupe.

De meilleurs compilateurs produiront de meilleurs résultats et vous donneront des erreurs plus utiles après la première, souvent par le biais d'une sorte de correction automatique des erreurs afin qu'un bon code présumé puisse au moins être vérifié. Mais ensuite, j'ai l'habitude de travailler en Java, dans Eclipse, où les fautes de syntaxe sont instantanément détectées et facilement corrigées, et les autres erreurs du compilateur ont tendance à être plus diverses et plus faciles à récupérer pour le compilateur. Je peux seulement supposer que c'est similaire lorsque je travaille dans les IDE de Microsoft et d'autres en C ++ ou C #.

Oui - ou du moins je les écume. Il est assez facile de déterminer si les erreurs sont liées (en général, un coup d'œil au numéro de ligne suffit) et j'aime les corriger toutes en une seule fois, puis recompiler.

Je ne fais cela (pour lire les erreurs après la première) que si la compilation 1 cpp est très longue. Ou non disponible. Ensuite, je préfère m'assurer que j'ai corrigé tout ce que je pouvais identifier dans les erreurs du compilateur comme indépendant de la première erreur.

Lorsque votre fichier cpp peut être compilé seul et le fait en moins d'une seconde (ou si vous avez des erreurs de pointage "intellisense" avant même que la compilation ne commence), vous n'avez pas à le faire la plupart du temps.

Je travaille actuellement sur un projet où je ne peux pas compiler un seul cpp (et je n'ai pas la main sur le système de construction, donc je ne peux pas changer cet O__o) et certains fichiers cpp peuvent prendre plus de dix minutes à compiler ( même après beaucoup d'efforts pour réduire cela, nous ne l'avons réduit qu'à 50% du temps de compilation d'origine ...).

Dans ce type de configuration de compilation très longue, vous avez tendance à réfléchir beaucoup avant de cliquer sur "build" ... et même à réfléchir beaucoup après, pour peut-être trouver des bogues avant le compilateur car vous êtes certainement plus rapide pour les obtenir mentalement que .

Il est assez courant de faire comme vous. Je dis généralement aux stagiaires ou aux programmeurs novices dépassés par le nombre d'erreurs d'ignorer presque toutes les erreurs, sauf la première. Il s'agit très probablement d'une erreur réelle qui doit être corrigée, et non d'une erreur fantôme trompeuse causée par une précédente. Certains (la plupart?) Des compilateurs ont la possibilité d'arrêter la compilation après la première erreur pour cette raison. Les systèmes de build peuvent généralement être configurés pour s'arrêter après le premier fichier qui contient également des erreurs.

Cependant, il existe également des raisons de continuer à compiler après avoir détecté des erreurs. Par exemple, vous souhaiterez peut-être compter le nombre de fichiers contenant des erreurs ou voir si un fichier d'en-tête inclus provoque des erreurs dans plusieurs fichiers.