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

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 il successivo errore correlato a un . Se il progetto è di grandi dimensioni e richiede un po 'di tempo per essere realizzato, trovo che lavorare in questo modo è meno frustrante che 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, darò un'occhiata più da vicino al resto dello stack degli errori e vedrò se posso correggerne alcuni. Questo mi dà una sensazione migliore quando mi alzo per fare il caffè mentre il compilatore corre.

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

Se c'è un divario nei numeri di riga, il compilatore probabilmente ha ripristinato e poi ha trovato un altro errore.

Di solito provo solo a correggere un errore in ogni mazzo però.

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 presumibilmente un buon codice possa almeno essere controllato. Ma poi, sono abituato a lavorare in Java, in Eclipse, dove gli errori di sintassi vengono rilevati all'istante e facilmente correggibili, 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 in IDE di Microsoft e altri in C ++ o C #.

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

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

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

Attualmente lavoro su un progetto in cui non riesco a compilare un solo cpp (e non ho la mano sul sistema di compilazione, quindi non posso cambiarlo) e alcuni file cpp possono impiegare più di dieci minuti compilare (anche dopo un grande sforzo per ridurlo, lo riduciamo solo al 50% del tempo di compilazione originale ...).

In questo tipo di installazione di compilation molto lunga, tendi a pensare molto prima di "costruire" ... e anche a pensare molto dopo, per trovare bug prima del compilatore come sei sicuramente più veloce per prenderli mentalmente.

È abbastanza comune fare come fai tu. Di solito dico agli stagisti o ai programmatori alle prime armi sommersi dal numero di errori per ignorare quasi tutti gli errori tranne il primo. È molto probabile che sia necessario correggere un errore reale e non un errore fantasma fuorviante causato da uno precedente. Alcuni (più?) 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 con errori.

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