@zkubinski:
tak, bo nie wiedziałem jak się pozbyć warningów... ale czy to znaczy, że "nie znam podstaw" ?
Tak. Zorientowanie się, że else
jest niepotrzebny, zlikwidowałoby ostrzeżenia lintera, nie stworzyło martwego kodu (swoją drogą, dziwi mnie nieco, że kompilator nie ostrzega o martwym kodzie tutaj) i należy do podstaw. Uciszenie wybranego ostrzeżenia odpowiednią #pragma
już, co prawda, podstawą nie jest, ale — tak na przyszłość — stanowi lepsze rozwiązanie od klepania dziwnego kodu. Ale, uwaga, ważne, dopiero wtedy, gdy się zrozumie dlaczego kompilatorowi coś przeszkadza i upewnieniu się, że faktycznie nie jest to problemem.
Czy książki do C++ omawiają takie kwestie ?
Tak.
kody błędów bardziej mają mi służyć aby odpalić okno typu QMessageBox ze stosownym komunikatem dla usera.
Dlaczego wybrałeś akurat kod błędu jako rozwiązanie? Jakie inne rozwiązania znasz, i czemu je odrzuciłeś?
Czyli co ? Mam rozumieć, że nie ma obsługi błędów i do tego są komentarze w kodzie ? A jak user się połapie, że coś nie tak ?
Nie, masz zrozumieć to, co Ci napisałem — gdzie wytykałem jako błąd używanie do tego komentarzy. To powinien być statycznie weryfikowany fragment kodu, nie komentarz.
tak, tutaj pełna 100% zgoda - BO TEGO NIGDY NIE ĆWICZYŁEM, BO NIE WIDZIAŁEM ZASTOSOWANIA typu wyliczeniowego, bo dla mnie to tylko liczba, która zastąpiona jest słowem - ale chcąc zobaczyć "co to da" chcę się nauczyć to robić
I to jest właśnie ta zła kolejność nauki, o której Ci piszemy. Najpierw powinieneś wiedzieć, jak się pisze różne funkcje, zwracające różne rzeczy, a dopiero potem eksperymentować, kiedy Ci się podoba taki a nie inny typ zwracany. Twoje podejście jest dydaktycznie błędne. Upierając się przy nim marnujesz czas — i swój, i nasz. Chcemy Ci w tym pomóc, doradzając zmianę podejścia. To najlepsza długofalowo rada, jakiej jestem w stanie udzielić.
„Liczba zastąpiona słowem” jest bardzo istotną kwestią poprawiającą czytelność programu — a czytelność programu jest, z kolei, bardzo istotną kwestią poprawiającą weryfikowalność programu, co zaś wpływa na jego poprawność, co znowu na jego jakość. Jak masz API, w którym jak coś pójdzie nie tak, to dostaniesz FileError::ReadOnly
, to znacznie trudniej się pomylić, niż jak masz API, w którym w tej samej sytuacji dostaniesz 17
.
zacznijmy od tego, że nigdy z wami nie było merytorycznej dyskusji - tylko było coś w rodzaju, "eee, nie znasz się, daj sobie na luz" - tylko TY jesteś pierwszą osobą, która właściwie zaczęła to robić.
Nie. Przede mną był na pewno kq, dawno temu. Ja nawet miałem Cię przez kilka lat na „czarnej liście”, za skasowanie tematu, w którym ludzie Ci pomagali — tylko znowu, pomagali tak, jak potrzebowałeś, a nie tak, jak chciałeś.
jeżeli chodzi o optional i variant ja nie spotkałem książki do podstaw C++ aby omawiała te zagadnienia - więc jak miałem się o nich dowiedzieć ? Szczerze ? Pierwszy raz to widzę
Na szczęście jest to problem, któremu łatwo zaradzić — możesz kupić lub wypożyczyć książkę do C++ i z niej się tego nauczyć, tak jak Ci doradzamy. Bo o tym właśnie piszemy. Wiadomo, że istnienia takich rzeczy się nie wywróży z fusów. Ale też i nie odgadnie się ich istnienia po samej praktyce. Jest to element tych podstaw, które trzeba nabyć — przed rozpoczęciem szeroko zakrojonej praktyki — na przykład czytając książki.