To, czego oczekuje kompilator

Ale wniosek i tak został jeden. Praktyka, praktyka, praktyka… ;)

Popieram… jakość komunikatów pozostawia duużo do życzenia.
Szczególny ‘ubaw’ jest jeżeli zapomni się ‘gdzieś na górze’ pliku średnika – gcc/g++ w takim wypadku mają zwyczaj wyrzucać kilka ekranów errorów i warningów – a chodzi o głupi średnik (a konkretniej jego brak)…
Cóż, jak reVis napisał.. praktyka, praktyka, praktyka ;D

Ta, a najlepiej jak się zapomni średnika po definicji klasy… jak pierwszy raz spotkałem się z tym błędem i to jeszcze w całkiem sporym projekcie to zajęło mi prawie tydzień żeby go zlokalizować. Teraz w sumie tez się czasami zdarza że potrzebuje nawet 0,5h żeby pokojarzyć.

Nie wiem jak to kompilowałeś. U mnie program:
SomeType variable;
int main() {
return 0;
}

Daje komunikat:
/tmp/main.cpp:1: error: ‘SomeType’ does not name a type

Jeżeli wstawię średnik po SomeType to dostaję dwa błędy:
/tmp/main.cpp:1: error: expected constructor, destructor, or type conversion before ‘;’ token
/tmp/main.cpp:1: error: expected constructor, destructor, or type conversion before ‘;’ token

W obu przypadkach komunikaty są bardzo sensowne.

Zgadzam się, C++ ma skomplikowaną składnię. Bez trudu można też napisać kod mający 6 linii, który wygeneruje ~1k linii błędu.

Nie oszukujmy się jednak. Kompilatory potrafią radzić sobie z takimi, prostymi przypadkami.

Kompilowałem:
g++ -g -W -Wall -pedantic /tmp/main.cpp
g++ (Debian 4.3.1-2) 4.3.1

Język C++ daje się opisać gramatyką kontekstową, więc jest kontekstowy. Jest jakiś niuans?

I tak trzeba przyznać, że błędy związane z samą składnią, po pewnej ilości praktyki są stosunkowo łatwo rozpoznawalne. Sytuacja ma się znacznie gorzej jak do gry wchodzą szablony. Wtedy dopiero błędy potrafią być uciążliwe przez bardzo długie logi.
Od strony programisty ciekawym rozwiązaniem są sposoby wykorzystania komunikatów kompilatora jako rozszerzeń dla języka. Mam tutaj na myśli tworzenie constraints (ograniczeń) dla szablonów. Sama technika jest przydatna, ale też przebiegła. Użyte słowa przy ich deklaracji, które trafiają na ekran w czasie kompilacji wskazują na powstały problem i niezgodność.
http://www.research.att.com/~bs/bs_faq2.html#constraints

lmmilewski: Deklarowałem zmienną jako lokalną. A C++ jest kontekstowy, oczywiście, ale to tylko dlatego, że wszystkie języki bezkontekstowe też są kontekstowe. Lingwistyka jest naprawdę sensowna, nie ma co ;)

reVis: No no… To już całkiem blisko do słynnego przykładu z generowaniem liczb pierwszych w kolejnych komunikatach o błędach :)

Oj, mądra notka. C++ jest po prostu bardzo funkcjonalny, przez co to, co teoretycznie nie ma sensu, jest w nim poprawne. Na przykład mając jakąś zmienną, można sobie napisać:
zmienna;
To samo do stałych dosłownych:
5;
W pełni poprawna instrukcja kodu (z językowego punktu widzenia rzecz jasna ;) ). C i C++ pozwalają na takie rzeczy, więc i błędy są takie, a nie inne, bo kompilator nie ma możliwości się domyślić, o co nam chodziło. Nawet poczciwy średnik może się mścić:
instrukcja1();
instrukcja2();
Gdy po pierwszej zapomnimy średnika (niby oczywisty błąd), kompilator wyrzuci jakiś tam błąd, ale na pewno nie będzie to nic w stylu “expected ; at end of line”. Kompilator olewa białe znaki, więc równie dobrze mógłby tam (w danych warunkach) stać jakikolwiek operator, ot choćby przecinek, plus lub nawet znak przypisania.
“Wolność” składni C pozwala też na robienie wielu innych błędów, jak choćby tradycyjny wręcz while (i=0) { kod(); }. Tyle, że to jest o tyle gorsze od poprzednich przykładów, że się kompiluje… Na szczęście generując jednocześnie warninga na każdym sensownym kompilatorze, więc pół biedy.

Pamiętam, że gdy “wyrosłem” ze starego, dobrego Pascala i zacząłem uczyć się C++, miałem właśnie przez takie rzeczy sporo trudności z przerzutką. Oj, ile to ja wtedy miałem problemów przez te enigmatyczne nazwy błędów. :) Najwięcej miałem zabawy, gdy w programie miałem coś takiego:
#include “klasa.h”
#include
A w nagłówku klasa.h moim zwyczajem zapominałem średnika po klamrze zamykającej definicję. I otwierałem z pasją nagłówek OpenGLa, z nadzieją, że uda mi się poprawić w nim te liczne błędy i jednocześnie zastanawiając się, czemu nigdy wcześniej ich nie zauważyłem. :>

Motto proste: “With great power comes great responsibility”, co można w tym wypadku dość luźno przetłumaczyć jako “Skoro jesteś na tyle odważny, by pisać w C++, to sam sobie szukaj swoich błędów” :}
Wzdych… A programiści Javy to dopiero mają luksusy. Wpisze sobie user Eclipse pustą funkcję:
int funkcja() {
}
Od razu ma ładnie podkreślone na czerwono, z komunikatem w stylu “No return statement found”, a w menu kontekstowym od razu może sobie wybrać “Add a return statement” lub “Change returned type to void”. To dopiero IDE dla leniwych, wszystko chce zrobić za programistę :) A my, gamedevowe dziadki lubujące się w C++, musimy sobie radzić samemu…
Chociaż jako ciekawostkę dodam, że Eclipse, którego na co dzień używam, też już potrafi znajdywać niektóre błędy. Podkreśla wszelkiej maści błędy składniowe, nawet w skomplikowanych instrukcjach (niestety oznacza je raptem jako “Syntax error” – jak już wiemy, rozpoznać ‘faktycznego’ błędu w C++ nie idzie), potrafi też rozpoznać złe wywołanie funkcji (na podstawie niezgodności typów parametrów – chociaż tego w aktualnej wersji nie wyróżnia, raptem nie koloruje wywołania funkcji). MS VS pewnie też nie pozostaje w tyle pod względem wprowadzania w użytek tego typu bajerów? Choć z drugiej strony, z tego co wiem, nawet do semantycznego podświetlania składni potrzebuje płatnego plugina… zgroza! :/

Sytuacja programistów C++ nie jest w kwestiach rozpoznawania i znajdywania błędów taka bajkowa, jak w przypadku np. Javy (najfajniejsze są te długie tramwaje błędów przy szablonach), ale jak widać, narzędzia idą do przodu, stary nasz język uparcie nie chce się wynieść z rynku, więc kto wie? Może kiedyś doczekamy takich ‘bajerów’ ułatwiających życie, jak ot choćby ta wspomniana Java?

A zobaczcie jaki błąd pokazuje w tym kodzie C# !!!

error CS0246: The type or namespace name ‘SomeType’ could not be found (are you missing a using directive or an assembly reference?)

Czyli jak się chce to się da ! C++ jest po prostu do dupy :P

A ja myślałem, że Regedit to taki fajny gość…

@Gynvael:
To normalne, wtedy zaczynasz poszukiwania od pierwszego komunikatu z błędem, reszta jest najczęściej konsekwencją tego pierwszego.

@Reg:
Zgadzam się! Ale to nie C++ jest z tego powodu do dupy, tylko kompilator, no i w sumie nie aż tak o razu całkiem do dupy… ;)

@CittEr:
Regedit powiedział na głos to, co inni starannie przemilczają. +P

Też pamiętam jak pierszy raz zmagałem się z brakiem średnika na końcu definicji klasy…to był koszmar! :)

Po pewnym czasie zauważyłem, że w jednej książce/kursie (niepamiętam) ciekawie uczą programowania..

wg nich instrukcje sterującą if powinno się pisać tak

if(warunek)
{
instrukcja;
}; //nie napisali tutaj nic o nadmiarowym sredniku, ale urzekl mnie on dosc znacząco

podobnie posługiwali się

if()
{
instrukcja;
}
else
{
instrukcja2;
};

for(;;)
{};

while()
{};

do{}
while(); //no tutaj akurat zrozumiale! :)

w sumie, jezeli ktos sie nauczy, ze tak trzeba wstawiac sredniki, to przy definicji klasy sie juz zastanawiac nie bedzie…

jest w tym jakiś sposób…choć ja osobiście nie stawiam nadmiarowych średników.
Swoją drogą…przychodzi komuś do głowy jakaś taka sytuacja gdzie nadmiarowy średnik za jakąś parą {} może bardzo zaszkodzić?

Przynajmniej kilka:

1) Średnik po } a przed ‘else’.
2) Średnik po } a przed ‘while’ (w do-while).
3) Średnik po } w konstrukcjach typu:

4) Średnik po } w przy inicjalizacji tablic wielowymiarowych, tj.: