Leggi gli errori di compilazione C o C ++ dopo il primo?

Non ho mai capito perché i compilatori C e C ++ provano a recuperare dagli errori e continuano ad analizzare. Quasi sempre, il primo errore genera un flusso di errori fasulli che scompare non appena viene risolto il primo. Dopo diversi anni di esperienza, ho semplicemente smesso di cercare qualsiasi errore tranne il primo di ogni file. Eseguo nuovamente il compilatore e quindi lo faccio di nuovo fino a quando non ci sono più errori. È una pratica comune?

A volte gli errori non sono correlati. Trovo più facile esaminare un elenco di errori e correggere la causa principale di una serie di errori correlati, quindi correggere l' errore successivo non correlato. Se il progetto è di grandi dimensioni e richiede un po 'di tempo per essere costruito, trovo che lavorare in questo modo sia meno frustrante di correggere il primo errore, ricompilare, ripetere ...

Dipende dal tempo di compilazione . Ad esempio, se so che ho appena cambiato un'intestazione principale che attiverà una ricostruzione dell'intero progetto, certamente darò un'occhiata più da vicino al resto dello stack di errori e vedrò se posso risolverne alcuni. Mi dà una sensazione migliore quando mi alzo per fare il caffè mentre il compilatore è in esecuzione.

Sì, faccio lo stesso, a meno che non stia utilizzando il compilatore per aiutarmi a refactoring, nel qual caso mi piace l'elenco completo degli errori :)

Se c'è un gap nei numeri di riga, probabilmente il compilatore si è ripreso e ha trovato un altro errore.

Di solito, però, prova a correggere solo un errore in ogni gruppo.

I migliori compilatori produrranno risultati migliori e ti daranno errori più utili dopo il primo, spesso attraverso una sorta di correzione automatica degli errori in modo che almeno un buon codice possa essere verificato. Ma poi, sono abituato a lavorare in Java, in Eclipse, dove gli errori di sintassi vengono immediatamente rilevati e corretti facilmente, e altri errori del compilatore tendono ad essere più diversi e più facili da recuperare per il compilatore. Posso solo supporre che sia simile quando si lavora negli IDE di Microsoft e altri in C ++ o C #.

Sì - o almeno li sfioro. È abbastanza facile capire se gli errori sono correlati (di solito basta dare un'occhiata al numero di riga) e mi piace sistemarli tutti in un passaggio e poi ricompilare.

Faccio questo (per leggere gli errori oltre il primo) solo se la compilation 1 cpp è molto lunga. O non disponibile Quindi preferisco assicurarmi di aver corretto tutto ciò che potevo identificare negli errori del compilatore come non correlato al primo errore.

Quando il tuo file cpp può essere compilato da solo e lo fa in meno di un secondo (o hai un "intellisense" che indica errori prima ancora che la compilazione abbia inizio) non devi farlo per la maggior parte del tempo.

Attualmente lavoro su un progetto in cui non riesco a compilare un cpp da solo (e non ho la mano sul sistema di compilazione, quindi non posso cambiare quel O__o) e alcuni file cpp possono richiedere più di dieci minuti per la compilazione ( anche dopo molti sforzi per ridurlo, lo abbiamo ridotto solo al 50% del tempo di compilazione originale ...).

In questo tipo di installazione di compilazione molto lunga, tendi a pensare molto prima di toccare "build" ... e anche a pensare molto dopo, forse a trovare bug prima del compilatore poiché sei sicuramente più veloce a ottenerli mentalmente di così .

È abbastanza comune fare come te. Di solito dico a stagisti o programmatori principianti sopraffatti dal numero di errori di ignorare quasi tutti gli errori tranne il primo. È molto probabilmente un vero errore che deve essere corretto, e non un errore fantasma fuorviante causato da uno precedente. Alcuni (quasi?) Compilatori hanno la possibilità di interrompere la compilazione dopo il primo errore per questo motivo. Generalmente i sistemi di compilazione possono essere configurati per arrestarsi anche dopo il primo file che presenta errori.

Tuttavia, ci sono motivi per continuare a compilare anche dopo aver rilevato errori. Ad esempio, potresti voler contare quanti file presentano errori o vedere se un file di intestazione incluso causa errori in più di un file.