Czy po pierwszym czytasz błędy kompilacji C lub C ++?

Nigdy nie zrozumiałem, dlaczego kompilatory C i C ++ próbują odzyskać po błędach i kontynuować analizę. Prawie zawsze pierwszy błąd generuje strumień fałszywych błędów, które znikną, gdy tylko pierwszy zostanie naprawiony. Po kilku latach doświadczenia po prostu przestałem patrzeć na każdy błąd oprócz pierwszego z każdego pliku. Ponownie uruchamiam kompilator, a następnie robię to ponownie, aż nie będzie już więcej błędów. Czy to powszechna praktyka?

Czasami błędy nie są ze sobą powiązane. I łatwiej spojrzeć na listę błędów i naprawić przyczynę szeregu powiązanych błędów, a następnie naprawić następnego un związane z modelem błąd. Jeśli projekt jest duży i jego budowa zajmuje trochę czasu, uważam, że praca w ten sposób jest mniej frustrująca niż naprawa pierwszego błędu, rekompilacja, powtórzenie ...

To zależy od czasu kompilacji . Na przykład, jeśli wiem, że właśnie zmieniłem nagłówek główny, który uruchomi przebudowę całego projektu, z pewnością przyjrzę się bliżej reszcie stosu błędów i zobaczę, czy mogę naprawić niektóre z nich. To daje mi lepsze wrażenie, gdy wstaję, aby zrobić kawę podczas działania kompilatora.

Tak, robię to samo, chyba że korzystam z kompilatora, aby pomóc mi refaktoryzować, w którym to przypadku podoba mi się pełna lista błędów :)

Jeśli istnieje luka w numerach linii, kompilator prawdopodobnie nie odzyskać, a następnie znaleźć inny błąd.

Zwykle jednak spróbuj naprawić tylko jeden błąd w każdej wiązce.

Lepsze kompilatory przyniosą lepsze wyniki i dadzą bardziej przydatne błędy po pierwszym, często poprzez pewnego rodzaju automatyczną korektę błędów, tak aby przypuszczalnie dobry kod można było przynajmniej sprawdzić. Ale potem jestem przyzwyczajony do pracy w Javie, w Eclipse, gdzie literówki składniowe są natychmiast wykrywane i łatwo korygowane, a inne błędy kompilatora są bardziej zróżnicowane i łatwiejsze do odzyskania przez kompilator. Mogę tylko założyć, że jest podobnie podczas pracy w IDE Microsoftu i innych w C ++ lub C #.

Tak - a przynajmniej je przeglądam. Łatwo jest ustalić, czy błędy są powiązane (zwykle wystarczy spojrzeć na numer linii) i lubię je wszystkie naprawiać w jednym przebiegu, a następnie rekompilować.

Robię to (aby odczytać błędy z pierwszego) tylko wtedy, gdy kompilacja 1 cpp jest bardzo długa. Lub niedostępne. Następnie wolę upewnić się, że naprawiłem wszystko, co mogłem zidentyfikować w błędach kompilatora jako niezwiązane z pierwszym błędem.

Gdy plik CPP można skompilować sam i robi to w mniej niż sekundę (lub masz błędy wskazujące „inteligencję” przed rozpoczęciem kompilacji), nie musisz tego robić przez większość czasu.

Obecnie pracuję nad projektem, w którym nie mogę skompilować jednego procesora samodzielnie (i nie mam ręki w systemie kompilacji, więc nie mogę zmienić tego O__o), a skompilowanie niektórych plików CPP może potrwać dłużej niż dziesięć minut ( nawet po wielu wysiłkach, aby to zredukować, skróciliśmy go tylko o 50% oryginalnego czasu kompilacji ...).

W tego rodzaju bardzo długiej konfiguracji kompilacji zwykle myślisz dużo, zanim zaczniesz „kompilować” ... a nawet dużo później, aby znaleźć błędy przed kompilatorem, ponieważ z pewnością szybciej je pozyskujesz. .

Robienie tego, co robisz, jest dość powszechne. Zwykle mówię stażystom lub początkującym programistom przytłoczonym liczbą błędów, aby zignorowali prawie wszystkie błędy oprócz pierwszego. Najprawdopodobniej jest to prawdziwy błąd, który należy naprawić, a nie wprowadzający w błąd błąd fantomowy spowodowany przez poprzedni. Niektóre (większość?) Kompilatory mają opcję zatrzymania kompilacji po pierwszym błędzie z tego powodu. Systemy kompilacji zwykle można skonfigurować tak, aby zatrzymywały się również po pierwszym pliku, który zawiera również błędy.

Istnieją jednak powody do kontynuowania kompilacji po wykryciu błędów. Na przykład możesz policzyć, ile plików zawiera błędy, lub sprawdzić, czy dołączony plik nagłówka powoduje błędy w więcej niż jednym pliku.