Witam i zapraszam.
W tym filmie chcę ci wyjaśnić, czym są błędy kompilatora.
Do tego momentu.
Racja.
Napisaliśmy trochę kodu i zauważyliśmy, że w oknie wyjściowym builda wydajemy polecenie
compile i wiemy, kiedy mamy błędy.
Racja.
Zwykle jest ładny opis, który mówi, że w twoim kodzie jest błąd, ale co to dokładnie
oznacza?
Więc kiedy piszesz kod do programowania, języki, języki programowania są bardzo, bardzo surowe.
Oni mają zasady.
I musisz przestrzegać tych zasad, aby uzyskać program wykonywalny.
Kompilator faktycznie sprawdzi składnię kodu.
I jeśli jest poprawny i jeśli nie ma błędów semantycznych, wygeneruje z kodu źródłowego, kodu typu języka maszynowego,
i można uruchomić program.
I tak trzeba przestrzegać tych zasad, a są to bardzo szczegółowe zasady.
I tak trzeba być bardzo zorientowanym na szczegóły.
Tak więc błędy kompilatora mogą występować w dwóch formach.
Mogą one występować w postaci błędu składniowego lub błędu semantycznego.
Błąd składniowy jest wtedy, gdy masz coś nie tak ze strukturą kodu, nie przestrzegasz
zasad języka w zakresie jego składni, prawda?
Nie umieszczasz nawiasów w odpowiednim, prawidłowym miejscu.
Nie dodajesz wszystkich wypowiedzi ze średnikiem.
Nie jesteś, że źle wpisujesz słowa kluczowe.
To wszystko są powszechne przykłady.
Średnik jest naprawdę powszechny, gdy po raz pierwszy zaczynasz.
Więc jeśli zadeklarujesz zmienną i przypiszesz ją do pięciu, ale nie masz tego średnika na końcu,
to jest to błąd składni.
Coś jest nie tak z tą strukturą.
Tak samo, jak gdybyś miał użyć instrukcji printf i mówisz instrukcję printf wewnątrz podwójnych cudzysłowów, ale
zapominasz o zakończeniu, podwójnym cytacie.
To jest błąd w składni.
I tak coś jest nie tak z tą strukturą w kompilatorze zazwyczaj, gdy skanuje twój kod źródłowy
i znajduje ten błąd, zwykle daje opisowe znaczenie błędu, które może wskazać ci właściwy kierunek, a także zwykle
daje numer linii.
I widzieliśmy to już w poprzednich filmach.
Innym rodzajem błędu, który kompilator może złapać, jest błąd semantyczny.
Nie zawsze łapie błędy semantyki, jeśli są to błędy logiczne, ale semantyczne zwykle oznaczają, że coś jest
nie tak ze znaczeniem.
Intencje programu.
Czyli np. gdybyś miał dodać dwie zmienne A i B, ale te zmienne były różnych typów i nie
miało to sensu, prawda?
Nie ma sensu dodawać A i B.
Kompilator może czasami złapać te błędy semantyczne.
Inne błędy semantyczne mają związek z logiką i te omówimy.
A kompilator nie zawsze znajduje takie.
Struktura była poprawna i wszystko było w porządku ze strukturą, ale logicznie coś było niepoprawne.
W logice kodu jest błąd.
Więc kiedy myślisz o błędach semantycznych, co kompilator może złapać, to jest bardziej
ma do czynienia z łapaniem typów i i rzeczy, których nie powinieneś robić z, z różnymi zasadami języka
dotyczącymi jak zmienne typy.
I tak teraz spójrzmy w świetle kodu, aby zobaczyć kilka powszechnych przykładów niektórych błędów składniowych i semantycznych
w języku programowania C.
Tak więc jesteśmy tutaj w świetle kodu z prostą aplikacją typu Hello world.
To jest kod, który jest generowany dla Ciebie z ustawień projektu.
Jeśli zapisałeś go jako szablon.
Bardzo prosty kod, prawda?
A kiedy skompilujesz ten plik, powie ci, czy masz błędy w składni, czy nie.
Możesz ponownie kliknąć prawym przyciskiem myszy i powiedzieć skompiluj.
I właśnie teraz nie mamy żadnych błędów, prawda?
Ale syntaktycznie przestrzegamy wszystkich zasad.
Ale składnia obejmuje, ponownie, całą strukturę kodu.
Więc jeśli nie masz średnika lub jeśli nie masz symbolu funta przed include i próbujesz go skompilować.
Zobaczysz, że jest błąd i zwykle błąd kompilatora ma jakieś znaczenie.
Teraz, gdy piszesz coraz więcej kodu i masz coraz więcej praktyki, te kompilatory nie będą tak
obcesowe.
Nie będą one tak nieopisowe, że będziesz je znał, jak na przykład
ten błąd mówi, że mamy błąd w pierwszej linii, prawda?
I tak jest miło.
Możesz to kliknąć dwukrotnie.
Przejdzie do tego błędu, ale mówi, że oczekiwane równości znają średnik.
Tak naprawdę nie mówi, co jest nie tak.
Wiesz, dzięki praktyce programistycznej zdasz sobie sprawę, oh, zapomniałem symbolu funta.
Więc niektóre błędy kompilatora nie są tak opisowe, jak byś chciał, jeśli jesteś nowy w programowaniu.
Więc dodajesz to, dodajesz ten symbol funta, rekompilujesz i jesteś dobry, aby przejść.
Jeśli źle napiszesz standardowe i o czasami nie będzie w stanie go znaleźć.
Więc zapisujesz go i rekompilujesz i widzisz błąd, który mówi nieco bardziej opisowo.
Prawda?
No such file or directory Stdio. który mówi ci, że może źle to napisałeś.
Tak więc błędne zapisy są częstymi błędami.
Wiesz, nie umieszczając rzeczy w odpowiedniej perspektywie w postaci źle dobranych nawiasów.
Wiesz, zapominasz o nawiasie, wiesz, znowu rekompilujesz.
Zobaczmy, jak wygląda ten błąd.
Znowu, to nie jest super opisowe.
Mówi, wiesz, że w zasadzie jest nawias przed kończącym nawiasem klamrowym, ponieważ nie wie, że myśli,
że może ten prawy nawias ma się skończyć gdzieś na dole tutaj.
Nie zawsze może powiedzieć dokładnie, co się dzieje.
Więc nawiasy i brakujące nawiasy klamrowe czasami nie są tak opisowe.
Ale jeśli masz coś takiego jak brakujący średnik, to jest całkiem proste.
Ten błąd kompilacji mówi ci dokładnie, co się dzieje.
Oczekiwany średnik przed powrotem rodzaj nawet wskazuje ci, gdzie masz umieścić ten średnik.
Więc możesz dwukrotnie kliknąć to, umieścić średnik, jeśli brakuje ci podwójnego cytatu i rekompilujesz.
Prawda?
Widzisz teraz coś, co mówi zasadniczo brakujący, kończący się podwójny cytat.
I znowu, to jakby wskazuje ci, gdzie pierwszy cytat się dzieje i daje ci wiele błędów,
Prawo, mimo że naprawdę masz tylko jeden.
Więc miałeś ten podwójny cytat i jesteś dobry, aby przejść.
Teraz ten main mówi, że musisz zwrócić int.
Co by było, gdybyś faktycznie próbował zwrócić coś takiego jak inside wewnątrz podwójnych cudzysłowów?
Ponownie, nie podążasz za tą strukturą języka i mówi ci zasadniczo, że zwracasz wskaźnik
znaków z typu funkcji.
Ponownie, te błędy kompilacji mogą nie mieć sensu dla ciebie w tej chwili, ale gdy napiszesz
więcej i więcej kodu, będą miały więcej sensu.
Ale chodzi o to, żeby trzymać się tej struktury.
Teraz, jeśli spróbujesz zrobić rzeczy, które sprawiają, że ma to sens syntaktycznie, ale znaczenie nie jest poprawne.
Więc na przykład, powiedzmy, że robimy druk F, a następnie próbujemy wykonać operację arytmetyczną, taką jak dzielenie
przez osiem lub dzielenie przez siedem.
Zapisujemy go i kompilujemy, a teraz widzimy bardziej błąd semantyczny, w którym mamy symbol podziału po podwójnych
cudzysłowach.
Wiesz, gdzie faktycznie oczekiwało Semicolon C Głównie znajdziemy błędy składniowe, błędy semantyczne.
Znaczenie kodu zwykle ma związek z logiką.
Nie znaleziono tak dużo błędów semantycznych zdarza się bardziej w języku takim jak C plus plus, gdy używasz.
Obiekty.
Więc bądź na tropie błędów składniowych z kompilatora.
Rzeczy pospolite niewłaściwe pod względem ortograficznym.
Słowa kluczowe nie kończące nawiasów, gdy zaczynasz je bloki kodu, gdy nie masz bloku
kończącego i zaczynającego I możesz mieć wiele błędów, prawda?
Powiedzmy więc, że mamy Hello world.
Brakuje nam średnika.
Zwracamy ciąg znaków.
Wiesz, brakuje nam wspornika, wiesz, i budujemy go.
I to jest raczej mały program.
Ale kiedy próbujemy go teraz skompilować, widzimy wiele błędów, prawda?
Dwa błędy.
I to jest trochę trudne, jak, gdzie mam zacząć?
Zazwyczaj to, co zrobisz, to naprawisz pierwszy błąd, ponieważ czasami jeden błąd może spowodować więcej błędów.
Więc zawsze chcesz spojrzeć na błąd kompilatora na samej górze i naprawić ten jeden najpierw.
Więc chcesz naprawić ten z piątej linii, tak?
A następnie możesz chcieć naprawić, a następnie przekompilować, a następnie być może naprawić ten w linii szóstej po tym.
A teraz jest napisane Jason.
Więc teraz możesz powiedzieć, że zwróć zero, ale zawsze naprawiaj ten pierwszy błąd, zanim naprawisz kolejne błędy, ponieważ
jeden może być przyczyną drugiego.
A przy okazji zawsze będziemy mieli błędy w naszym kodzie.
My nawet najbardziej doświadczeni programiści będziemy mieli błędy składniowe.
I tak często zdarzają się błędy.
To, co jest naprawdę ważne, to zrozumienie wiadomości, które pochodzą z kompilatora, aby powiedzieć
ci, jak je poprawić.
I znowu, to przyjdzie w praktyce.
Będziemy mówić więcej o kompilatorach, wspólnych kompilatorach w przyszłych filmach, ale po prostu spróbuj
upewnić się, że śledzisz strukturę języka, gdy się go uczysz, języki syntaktyczne i tak dalej.
W kolejnych wykładach będziemy mówić o tym, jak możemy mieć różne rodzaje błędów.
Wspomniałem o błędach logicznych.
Możemy też porozmawiać trochę o ostrzeżeniach.
Będziemy też mówić o błędach linkera i błędach runtime.
Dziękuję.