Você lê erros de compilação em C ou C ++ após o primeiro?

Eu nunca entendi por que os compiladores C e C ++ tentam se recuperar de erros e continuar analisando. Quase sempre, o primeiro erro gera um fluxo de erros falsos que desaparecem assim que o primeiro é corrigido. Após vários anos de experiência, simplesmente parei de olhar para qualquer erro, exceto o primeiro de cada arquivo. Executo novamente o compilador e, em seguida, faço isso novamente até que não haja mais erros. É uma prática comum?

Às vezes, os erros não estão relacionados. Acho mais fácil olhar para uma lista de erros e corrigir a causa raiz de uma série de erros relacionados e, em seguida, corrigir o próximo erro não relacionado. Se o projeto for grande e demorar um pouco para ser construído, acho que trabalhar dessa maneira é menos frustrante do que corrigir o primeiro erro, recompilar, repetir ...

Depende do tempo de compilação . Por exemplo, se eu souber que acabei de alterar um cabeçalho mestre que acionará uma reconstrução de todo o projeto, certamente examinarei mais atentamente o restante da pilha de erros e verificarei se consigo corrigi-los. Isso me dá uma sensação melhor quando me levanto para fazer café enquanto o compilador é executado.

Sim, faço o mesmo, a menos que esteja usando o compilador para me ajudar a refatorar, caso em que gosto da lista completa de erros :)

Se houver uma lacuna nos números de linha, o compilador provavelmente se recuperou e encontrou outro erro.

Normalmente, tente apenas corrigir um erro em cada grupo.

Compiladores melhores produzirão melhores resultados e fornecerão erros mais úteis após o primeiro, geralmente através de algum tipo de correção automática dos erros, para que, presumivelmente, um bom código possa pelo menos ser verificado. Porém, estou acostumado a trabalhar em Java, no Eclipse, onde erros de sintaxe são detectados e corrigidos facilmente instantaneamente, e outros erros do compilador tendem a ser mais diversos e mais fáceis de recuperar. Só posso assumir que é semelhante ao trabalhar nos IDEs da Microsoft e em outros em C ++ ou C #.

Sim - ou pelo menos eu os roço. É muito fácil descobrir se os erros estão relacionados (geralmente basta olhar o número da linha) e eu gosto de consertá-los de uma só vez e recompilar.

Eu faço isso (para ler os erros anteriores ao primeiro) apenas se a compilação de 1 cpp for muito longa. Ou não está disponível. Em seguida, prefiro garantir que corrigi tudo o que consegui identificar nos erros do compilador como não relacionado ao primeiro erro.

Quando o seu arquivo cpp pode ser compilado sozinho e em menos de um segundo (ou você tem um "intellisense" apontando erros antes mesmo da compilação começar), você não precisa fazer isso a maior parte do tempo.

Atualmente, trabalho em um projeto em que não consigo compilar um cpp sozinho (e não tenho a mão no sistema de compilação, portanto não posso alterar esse O__o) e alguns arquivos cpp podem levar mais de dez minutos para compilar ( mesmo depois de muito esforço para reduzi-lo, reduzimos apenas para 50% do tempo de compilação original ...).

Nesse tipo de configuração de compilação muito longa, você costuma pensar muito antes de clicar em "build" ... e até pensar muito depois, para talvez encontrar bugs antes do compilador, já que é mais rápido em obtê-los mentalmente do que ele .

É bastante comum fazer o que você faz. Normalmente digo a estagiários ou programadores iniciantes, sobrecarregados com o número de erros, para ignorar quase todos os erros, exceto o primeiro. Provavelmente, é um erro real que precisa ser corrigido, e não um erro fantasma enganoso causado por um erro anterior. Alguns compiladores (a maioria?) Têm a opção de parar de compilar após o primeiro erro por esse motivo. Os sistemas de compilação geralmente podem ser configurados para parar após o primeiro arquivo que também possui erros.

No entanto, existem razões para continuar a compilar após a detecção de erros também. Por exemplo, convém contar quantos arquivos têm erros ou verificar se um arquivo de cabeçalho incluído causa erros em mais de um arquivo.