Jak odebrać zwracaną wartość na funkcjach zwrotnych

Mam poniższą funkcję która zwraca numer błędu i wygląda ona tak

bool SettingsFile::readSettings()
{
    QFile readFileJson;

    readFileJson.setFileName(QString("settings.json"));

    if(!readFileJson.open(QIODevice::ReadOnly | QIODevice::Text)){
        qInfo()<< "nie mozna odczytac pliku";

        return 2; //numer błędu
    }
    else{
        QByteArray data;
        data = readFileJson.readAll();

        return 0; //numer informujący, że coś się powiodło
    }

    return -2; //nieprzewidzany wyjątek...
}

i ten numer błędu chcę odebrać w innej klasie (ściślej w oknie podrzędnym) która może się tym zająć i teraz pytanie jest takie.

Jak odebrać numer błędu na funkcjach zwrotnych ? Bo nie chcę robić sygnałów i slotów.

Sygnał i slot działa i jest prosty do ogarnięcia ale w tym przypadku wolałbym tego uniknąć

Człowieku (przepraszam że obrażam ludzi), czy ty rozumiesz że wartości 2,0,-2 nie są wartościami typu bool?
Czy rozumiesz że zwrócenie 0 oznacza zwrócenie false zaś pozostałe wartości zwrócą true (bo zadziała konwersja implicit)?
Użyj wyjątków aby złapać błędne wykonanie.

Weź do q-wy nędzy przeczytaj jakiś kurs z podstawami !!!!!!!!!

Nazwa funkcji nie odpowiada temu co funkcja faktycznie robi. Nie wczytuje ona żadnych ustawień a jedynie ładuje zawartość pliku do pamięci. Poza tym jeśli w bloku if masz return to else jest zbędne. No i to return -2 nigdy się nie wykona.

Przy wczytywaniu surowych bajtów z pliku nie ma żadnych "nieprzewidzianych wyjątków". Ma trzy możliwe rezultaty:

• plik nie istnieje
• plik istnieje ale jest pusty
• plik istnieje i został wczytany

Obsłużyć to można na kilka sposobów

• bool + jakieś oddzielne GetErrorCode()
• int jako error-code
• enum (imho najlepsze wyjście)

Wyjątków bym niestosował, bo funkcja jest zbyt "ogólnikowa" żeby stwierdzić czy niemożność wczytania pliku jest wyjątkową sytuacją dla aplikacji czy nie.

dobra, ostatecznie zrobiłem na sygnałach i slotach...

void SettingsFile::readSettings()
{
    QFile readFileJson;

    readFileJson.setFileName(QString("settings.json"));

    if(!readFileJson.open(QIODevice::ReadOnly | QIODevice::Text)){

        emit messageOfnumber(2);
    }
    else{
        QByteArray data;
        data = readFileJson.readAll();

        emit messageOfnumber(0);
    }
}

ciężko od was wyciągnąć wiedzę o czymś na wyższym poziomie niż podstawa, odbieracie chęć poznania i dowiedzenia się czegoś, jesteście cholernie toksycznymi ludźmi jprdl... kto was tak wychował ? Starzy są pewnie z was dumni :>

tajny_agent napisał(a):

• plik nie istnieje
• plik istnieje ale jest pusty
• plik istnieje i został wczytany

W zasadzie dodałbym jeszcze trzy opcje:

• plik istnieje i został wczytany ale nie jest poprawnym JSON'em
• plik istnieje i został wczytany i jest poprawnym JSON'em ale zawiera nieodpowiednie opcje dla ustawień.
• plik istnieje i został wczytany i jest poprawnym JSON'em i zawiera odpowiednie opcje dla ustawień ale @zkubinski i tak nie rozumie o co w tym wszystkim chodzi bo chce callback'a nawet nie wiedząc czym to jest i z czym to się je.

tajny_agent napisał(a):

Nazwa funkcji nie odpowiada temu co funkcja faktycznie robi. Nie wczytuje ona żadnych ustawień a jedynie ładuje zawartość pliku do pamięci.

na to nie wpadłem, mogłem nazwać funkcję loadFile

• enum (imho najlepsze wyjście)

czy podałbyś jakiś przykład jak to zrobić ? Bo nie mam na to żadnego pomysłu.

zkubinski napisał(a):

dobra, ostatecznie zrobiłem na sygnałach i slotach...

void SettingsFile::readSettings()
{
    QFile readFileJson;

    readFileJson.setFileName(QString("settings.json"));

    if(!readFileJson.open(QIODevice::ReadOnly | QIODevice::Text)){

        emit messageOfnumber(2);
    }
    else{
        QByteArray data;
        data = readFileJson.readAll();

        emit messageOfnumber(0);
    }
}

ciężko od was wyciągnąć wiedzę o czymś na wyższym poziomie niż podstawa, odbieracie chęć poznania i dowiedzenia się czegoś, jesteście cholernie toksycznymi ludźmi jprdl... kto was tak wychował ? Starzy są pewnie z was dumni :>

dobra zaczynamy orkę, chociaż późną nieche mi się i jestem zmęczony(więc się nawet nie będę zagłębiał chociaż kod krótki i znęcanie się nad nim jest na siłę:

1. Przez 7 lat nie nauczyłeś się używać formatera.
2. Zawsze w takich wypadkach warto się zastanowić czy readSettings nie powinien mieć const qstring path jako argument(a może nawet w konstruktorze! można? można) albo jako const qstring path w klasie. Tu zawsze się zastanawiam dość głęboko nad deklaracją jak czytam jakieś pliki. Ale to zależy konkretnie od sytuacji i co chcemy zrobić. znowu ruszamy głową i myślimy nie ma jednej odpowiedzi.
3. Nic nie robisz z danymi
4. Po co if else? Wiem że niektórzy nie lubią early return ale tu aż się prosi.
5. I teraz znowu wszystko zależy od pomysłu, czym jest klasa i co reprezentuje czyli Jak bym wywołał metodę readSettings to bym oczekiwał że dostanę jednak jakieś dane(ale znów to zależy od kontekstu bo patrz pkt. 2) jak wartość zwrotną ba spotyka się czasami połączenie zgłaszania błędów z danymi przez zwracanie std::optional czy pary <kod, wartość> jak odczyt danych jest nie co bardziej skomplikowany ba nawet emit struktury nawet za pomocą Q_REGISTER_METATYPE? Jak się bawić to się bawić. możliwości jest więcej jak jedna.
6. Ktoś mógłby nawet powiedzieć że idźmy o krok do przodu ukryjmy implementację za jakimś interfacem zwracającym dane tak aby można było czytać z json, xml czy bazy danych. Ale oczywiście jeśli planuje się coś takiego. Mnożenie bytów na zapas nie ma sensu, ale wspominam tu w kontekście twojego majaczenia o polimorfizmie w w innym wątku.

Twój problem jest ten sam co zawsze, szukasz jednej odpowiedzi na mgliste źle zadane pytania z brakiem podstaw. Jak przedstawiłem wyżej są różne podejścia i jedna decyzja może implikować inne. Powyżej rzuciłem pewne pomysły które mogą być co gorsza złe! ale to zależy od kontekstu.
Jako podsumowanie twojej 7 letnie walki z qt, c++, c# i bóg jeszcze wie czym. Programisty z ciebie nie będzie. Powody twego masochizmu nie są mi znane.

zkubinski napisał(a):

ciężko od was wyciągnąć wiedzę o czymś na wyższym poziomie niż podstawa

Problem polega na tym, że podstaw ci brakuje, a twoje pytania o rzeczy "bardziej zaawansowane" nie mają sensu przez ten brak podstaw. Wyobraź sobie, że wrzucasz zdjęcie samochodu osobowego i pytasz czy z Londynu do Nowego Jorku najlepiej jechać na piątym biegu, bo bagażnik trochę mały na zapasowe paliwo. I naskakujesz na każdego, kto zwróci ci uwagę, że taka trasa samochodem jest bez sensu/prawie niemożliwa, albo że przewóz paliwa w bagażniku to naruszenie norm bezpieczeństwa, albo że samo pytanie na którym biegu jechać jest dość wątpliwe.

Tak samo tutaj: pytasz o callbacki, dajesz kontekst sygnałów/slotów (to nie są konkurencyjne rozwiązania, ich użycia pokrywają sie co najwyżej częściowo), jednocześnie pokazując funkcję, która nie powinna używać ani jednego ani drugiego, niezależnie od tego czy patrzymy na jej implementację czy też nazwę. Ponadto zamiast czytelnie komunikować o błędzie zwracasz jakieś magiczne wartości. Ponownie dopasowujesz problem do rozwiązania. Nieudolnie.

kq napisał(a):

Problem polega na tym, że podstaw ci brakuje, a twoje pytania o rzeczy "bardziej zaawansowane" nie mają sensu przez ten brak podstaw.

z całym szacunkiem do ciebie. Ale wyobraź sobie, że nawet twórca języka C++ zaczynał od początku, od podstaw, od wymyślenia - zanim zaszedł dalej czy wracał ciągle do podstaw ? Czy raczej szedł dalej i uczył się na błędach ? Wykonywał jakieś programy czyli szlifował nabytą wiedzę.

Trochę wrócę do twoich umiejętności - czy od razu z grubej rury byłeś mistrzem kodu ? Czy jednak trochę ci to zajęło ? Popełniałeś błędy ? Nie jest istotne jakie ale jednak je popełniałeś. Czy brakowało ci pomysłu na coś, na jakieś rozwiązanie ? Myślę, że na pewno. Nawet nie sądzę, że od razu wiedziałeś jak użyć jakąś składnię i w jakim przypadku, powiem więcej, umiejąc już coś nie sądzę, że od razu byłeś w stanie napisać jakiś algorytm jakikolwiek nawet najprostszy - zanim cokolwiek zrozumiałeś trochę ci jednak zajęło.

Podsumowując wasz wywód o tych podstawach - idąc waszym tokiem myślenia, szczególnie niejakiego @_13th_Dragon to już po przeczytaniu pierwszej lepszej książki od podstaw C++ powinienem być juz ekspertem w tej dziedzinie i powinienem już umieć pisać systemy operacyjne. Teraz pytanie do was miszcze. Czy wy po przeczytaniu podstaw staliście się od razu biegłymi ? Nie sądzę, powiem więcej, wasze doświadczenie przyszło z czasem, a po drugie najważniejsza rzecz, z kodem stykacie się na co dzień, ja z kodem stykam się "od czasu do czasu" - jeżeli tego nie rozumiecie, to ja w ogóle się dziwię, że jesteście programistami bo w zasadzie nie potraficie zrozumieć prostego przekazu - to jak zostaliście programistami ? Pracujecie z ludźmi ? Czy siedzicie w norach ?

Twojemu wywodowi brakuje spójności logicznej (ale za to nadrabiasz spacjami przed znakami interpunkcyjnymi). Podstawy są konieczne do zrozumienia bardziej zaawansowanych tematów, tego nie przeskoczysz. Jeśli je opanujesz, to nie musisz do nich "wracać", bo już je masz. I nie, nie stajesz się wtedy od razu ekspertem. Ten temat wałkowaliśmy już wielokrotnie i nic z tego nie wynikało, bo jesteś odporny na myśl, że ktoś inny może mieć tutaj rację. Uczysz się "po swojemu", a efekty widzimy.

Trochę wrócę do twoich umiejętności - czy od razu z grubej rury byłeś mistrzem kodu ?

Nie, choć za takiego się uważałem. Z perspektywy czasu widzę jak śmieszne to było. Ponadto: widzę jak mogłem wykorzystać ten czas na efektywniejszą naukę - co przejawia się w moich radach do użytkowników tego forum.

Czy jednak trochę ci to zajęło ?

Tak

Popełniałeś błędy ?

Tak

Nie jest istotne jakie ale jednak je popełniałeś.

A jednak jest to istotne. Błędy programistyczne to mały problem, błędy w ogólnym podejściu do nauki i nadmierna pewność siebie spowolniły mój rozwój.

Czy brakowało ci pomysłu na coś, na jakieś rozwiązanie ? Myślę, że na pewno. Nawet nie sądzę, że od razu wiedziałeś jak użyć jakąś składnię i w jakim przypadku, powiem więcej, umiejąc już coś nie sądzę, że od razu byłeś w stanie napisać jakiś algorytm jakikolwiek nawet najprostszy - zanim cokolwiek zrozumiałeś trochę ci jednak zajęło.

No tak, ale o co chodzi?

gdybym nie znał podstaw, to Qt za nic w świecie bym nie ogarnął - ale jednak ogarnąłem i co teraz ? Będzie jakaś nowa teoria ?

Nie piszę zawodowo w C++, rzadko odpisuje w tym dziale w ogóle, ale wypowiem się dlatego, że jesteś uprzedzony do innych którzy próbują Ci pomóc.
Nie ogarnąłeś QT bo nie znasz podstaw i już. Posłuchaj rad innych. Ogarnij te podstawy.
Jest to zwykła konstruktywna krytyka.
W swoim toku myślenia zadaj sobie pytanie "Jaki interes mają Ci wszyscy co mi mówią, że nie znam podstaw? Dlaczego jest ich tak wielu?"

@zkubinski:

ok, ale gdy zapytasz konkretnie "czego brakuje mi w podstawach" - nikt nie wskaże co robię źle

OK, wskażę Ci zatem, co zrobiłeś źle tylko w tym temacie, i jakich konkretnie podstaw tutaj Ci brakuje:

• Nieprzemyślany typ funkcji — już nawet pomijając fakt, że polegasz na niejawnej konwersji inta na boola, to próbujesz zwracać trzy różne wartości tym boolem.
• Nieprzemyślana nazwa funkcji — ona nie czyta ustawień. Jakbym zobaczył w kodzie gdzieś funkcję o takiej sygnaturze, to moją reakcją by było natychmiastowo „zaraz, co!?”
• Piszesz kod, o którym wiesz, że się nie wykona (trzeci return).
• Próbujesz używać kodów błędów. Za całą dokumentację tych kodów błędów służą komentarze w kodzie.
• „Nie masz żadnego pomysłu” jak zrobić funkcję zwracającą enum.

Ale nie tylko o te problemy tutaj chodzi — w innych swoich tematach, chyba nawet we wszystkich swoich tematach, przewija się jeden wątek — bierzesz się za coś o średnim poziomie zaawansowania, po czym w ramach tłumaczenia Ci tego, albo już nawet przed, na samym starcie, wychodzą braki dużo bardziej podstawowe. Jak nawet sam piszesz, jesteś człowiekiem, który „nie zna podstaw, bo chce iść dalej” — nie da się iść dalej nie znając podstaw. Z samej definicji „podstawy”. Nie da się pomóc człowiekowi nieznającemu podstaw inaczej, niż próbując namówić do opanowania podstaw. „[C]iężko od was wyciągnąć wiedzę o czymś na wyższym poziomie niż podstawa”, bo nie zasz podstaw. Wtedy bardzo ciężko wyciągnąć wiedzę o czymś na wyższym poziomie niż podstawa skądkolwiek.

Więc, no, ten wątek mógłby być rozmową o tym, co to jest optional, co to jest variant, co to są parametry wyjściowe funkcji, co to są wyjątki, i jak używać wszystkich tych narzędzi do obsługi sytuacji nietypowych i kiedy. Mógłby być o callbackach. Mógłby być o sygnałach i slotach. Ale nie może być o wszystkich tych rzeczach na raz, bo to się nijak ma do siebie, ani do Twojego problemu, ani do Twojego poziomu zaawansowania.

Nie da się Ci udzielić sensownej rady innej niż „zacznij od nowa, od zera, od wybranej książki do C++ — tak, żeby stworzenie funkcji zwracającej enum to była kwestia naturalna, żeby instrukcje warunkowe miały ręce i nogi, żeby jak usłyszysz od kogoś, żeby zrobić w ramach jakiegoś rozwiązania tak, żeby Twoja funkcja przyjmowała jako argument inną funkcję i wykorzystywała ją do czegoś-tam (na przykład do posprzątania po sobie), to nawet jak nie wiesz, jak to się w żargonie technicznym nazywa (callback), to wiesz, jak to zaprogramować. Wiem, że to nie jest rada, którą chcesz usłyszeć. Ale żadna inna nie ma sensu.

Althorion napisał(a):

• Nieprzemyślany typ funkcji — już nawet pomijając fakt, że polegasz na niejawnej konwersji inta na boola, to próbujesz zwracać trzy różne wartości tym boolem.

nie chce mi się tego tłumaczyć ale powiem tak - pisząc tą funkcję, myślałem o typie zwracanym bool, a przez pomyłkę w warunkach dałem return int - i to nie jest brak podstaw, tylko zwykły błąd ludzki - można powiedzieć wyłożyłem się i nawet tego nie zauważyłem.

• Nieprzemyślana nazwa funkcji — ona nie czyta ustawień. Jakbym zobaczył w kodzie gdzieś funkcję o takiej sygnaturze, to moją reakcją by było natychmiastowo „zaraz, co!?”

nie wiedziałem, że nazwanie funkcji "po swojemu" należy do braku podstaw... każdy programista ma swoją wizję na coś i każdy to samo wykonałby inaczej... ale ok, przyjmuję, że nazwa funkcji jest nietrafna

• Piszesz kod, o którym wiesz, że się nie wykona (trzeci return).

tak, bo nie wiedziałem jak się pozbyć warningów... ale czy to znaczy, że "nie znam podstaw" ? Czy książki do C++ omawiają takie kwestie ? Jakoś nie napotkałem, bardziej mi to wynika z nabytego doświadczenia - czyli trzeba pisać, pisać i pisać...

• Próbujesz używać kodów błędów. Za całą dokumentację tych kodów błędów służą komentarze w kodzie.

kody błędów bardziej mają mi służyć aby odpalić okno typu QMessageBox ze stosownym komunikatem dla usera. 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 żadnego pomysłu” jak zrobić funkcję zwracającą enum.

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ć

Ale nie tylko o te problemy tutaj chodzi — w innych swoich tematach, chyba nawet we wszystkich swoich tematach, przewija się jeden wątek — bierzesz się za coś o średnim poziomie zaawansowania, po czym w ramach tłumaczenia Ci tego, albo już nawet przed, na samym starcie, wychodzą braki dużo bardziej podstawowe.

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ć.

Jak nawet sam piszesz, jesteś człowiekiem, który „nie zna podstaw, bo chce iść dalej” — nie da się iść dalej nie znając podstaw. Z samej definicji „podstawy”. Nie da się pomóc człowiekowi nieznającemu podstaw inaczej, niż próbując namówić do opanowania podstaw. „[C]iężko od was wyciągnąć wiedzę o czymś na wyższym poziomie niż podstawa”, bo nie zasz podstaw. Wtedy bardzo ciężko wyciągnąć wiedzę o czymś na wyższym poziomie niż podstawa skądkolwiek.

Więc, no, ten wątek mógłby być rozmową o tym, co to jest optional, co to jest variant, co to są parametry wyjściowe funkcji, co to są wyjątki, i jak używać wszystkich tych narzędzi do obsługi sytuacji nietypowych i kiedy. Mógłby być o callbackach. Mógłby być o sygnałach i slotach. Ale nie może być o wszystkich tych rzeczach na raz, bo to się nijak ma do siebie, ani do Twojego problemu, ani do Twojego poziomu zaawansowania.

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ę

@zkubinski, twój post jest nieco zagmatwany, ale abstrahując od popełnionych błędów i całej tej dyskusji, czy o to ci chodziło?

void SettingsFile::readSettings(std::function<void(int)> funkcjaZwrotnaXd)
{
  ...
  funkcjaZwrotnaXd(-1);
  ...
}

Nie programuję w c++ od wielu lat, nie wiem czy to jest poprawne.
Proponuję używać angielskich terminów, bo nikt nie wie co to jest "funkcja zwrotna".

zkubinski napisał(a):

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ę

Może stare ksiązki miałeś? strona https://en.cppreference.com/w/cpp/utility/variant podaje że wiariant weszło w C++17 a tu jest ksiązka co ma to opisane https://helion.pl/ksiazki/c-17-stl-receptury-jacek-galowicz,cpp17r.htm#format/e

Optional https://en.cppreference.com/w/cpp/utility/optional zresztą tak samo w C++17 i też jest w tej książce

@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.

KamilAdam napisał(a):

zkubinski napisał(a):

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ę

Może stare ksiązki miałeś? strona https://en.cppreference.com/w/cpp/utility/variant podaje że wiariant weszło w C++17 a tu jest ksiązka co ma to opisane https://helion.pl/ksiazki/c-17-stl-receptury-jacek-galowicz,cpp17r.htm#format/e

Właśnie to jest problem z fw gui dostaczajacymi obszerne rodziny klas poza-GUI, typy, kontenery (własny string - horror ekosystemu C++) - najstarsi Indianie nie wiedzą na ile std:: variant jest kompatybilny z Qt.
Może jest, ale z góry "bez studiowania zagadnienia" nie powiem.

Gdyby @zkubinski poświęcił na naukę tyle czasu ile spędza na tym forum na kłócenie się w swoich tematach, to już dawno by zaniechał ich zakładania.

dawno temu wrzucałem tu link do książki o refaktoryzacji której nawet nie tyknąłeś wykonam pierwszy krok za ciebie. I to pierwsa ieracja

bool SettingsFile::readSettings()
{
    QFile readFileJson;

    readFileJson.setFileName(QString("settings.json"));

    if(!readFileJson.open(QIODevice::ReadOnly | QIODevice::Text)){
        qInfo()<< "nie mozna odczytac pliku";

        return 2; //numer błędu
    }
    else{
        QByteArray data;
        data = readFileJson.readAll();

        return 0; //numer informujący, że coś się powiodło
    }

    return -2; //nieprzewidzany wyjątek...
}
//////////////////////////////////
std::optional<Settings> SettingsFile::readSettings()
{
    auto jsonDataByte = loadJsonData("settings.json");
    if (!jsonDataByte) return std::nullopt; // nawiasem mówiąc to pierwsza iteracja można pomyśleć później jaki to "rodzaj" if wprowadzono w C++17
    return decodeJsonData(jsonDataByte);
}

To ledwie pierwsza iteracja, można pomyśleć o różnych zmianach(nazw, tego co wskazałem w komentarzu) itd. Podejście iteracyjne no ale to musiałbyś książki które tu polecano poczytać.

Althorion napisał(a):

Dlaczego wybrałeś akurat kod błędu jako rozwiązanie? Jakie inne rozwiązania znasz, i czemu je odrzuciłeś?

nie znam innych rozwiązań - wymyśliłem sobie, że jak zwrócę typ int, to odpalę tym komunikat QMessageBox za pomocą liczby która będzie zwrócona.

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ć.

noo, już przynajmniej jakiś konkret, a nie "weź naucz się podstaw" - mnie to nic nie mówi

„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.

ok, zgoda

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.

masz tytuł książki w której to jest opisane ? Bo ja mam ich sporo i w żadnej nie ma wzmianki o tym co piszesz

nie znam innych rozwiązań - wymyśliłem sobie, że jak zwrócę typ int, to odpalę tym komunikat QMessageBox za pomocą liczby która będzie zwrócona.

OK, czemu nie. Proste, ale działające. Czemu zatem właśnie tak nie zrobisz, tylko próbujesz użyć callbacka lub sygnału/slotu? Jaki widzisz zysk w callbacku lub sygnale/slocie? To nie jest tak, że twierdzę, że jedno z tych rozwiązań tutaj jest jedynym słusznym, a inne są niesłuszne — w różnych warunkach się stosuje różne — tylko próbuję Cię zmusić do zastanowienia się i ujęcia w słowa, dlaczego wybrałeś takie, a nie inne rozwiązanie architektoniczne. Innymi słowy, czemu nie mieć jak piszesz, funkcji zwracającej int, i odpalenia potem innej funkcji przy użyciu tego zwróconego inta.

masz tytuł książki w której to jest opisane ? Bo ja mam ich sporo i w żadnej nie ma wzmianki o tym co piszesz

Tak. Dostałeś niepełną listę wyżej, mogę wrzucić i rozwinąć tutaj. Kolejność mniej-więcej od mniej do bardziej zaawansowanych:

• „C++ Programming Language”, Bjarne Stroustroup
• „C++ Standard Library”, Nicolai Josuttis
• „C++17 - The Complete Guide”, Nicolai Josuttis
• „C++ Concurrency in Action”, Anthony Williams
• „Hands-On Design Patterns with C++”, Fedor G. Pikus

Można dopchnąć C++ Core Guidelines, ale to bardziej zbiór porad, co zrobić gdy, niż dokument, który warto przeczytać ciągiem, jak książki wyżej.

Althorion napisał(a):

nie znam innych rozwiązań - wymyśliłem sobie, że jak zwrócę typ int, to odpalę tym komunikat QMessageBox za pomocą liczby która będzie zwrócona.

OK, czemu nie. Proste, ale działające. Czemu zatem właśnie tak nie zrobisz, tylko próbujesz użyć callbacka lub sygnału/slotu? Jaki widzisz zysk w callbacku lub sygnale/slocie?

Nie wiem czy czytałeś mojego pierwszego posta, ale pisałem w nim, że nie chcę robić tego na sygnale/slocie - po prostu, a powód jest taki, że od kilku lat zastanawiam się jak robi się callback function i jak to działa z pętlą zdarzeń i chciałem się tego nauczyć i tylko tyle.

Ale ostatecznie zrobiłem to na sygnale/slocie - owszem działa ale to już znam :> A chciałem poznać inną metodę - po prostu coś innego, nowego i nieznanego

Jak szukasz pomysłu na problem, który jest sens rozwiązywać callbackiem, to mogę np. zaproponować sytuację, w której chcesz mieć możliwość różnych sposobów logowania zdarzeń — czasem zapis do pliku, czasem zapis do SQLite’a, czasem e-mail do admina, co Ci tam przyjdzie na myśl.

Zastanów się, jak to osiągnąć nie duplikując kodu ponad miarę. Zastanów się, co się ma stać w sytuacji, gdy nastąpi błąd logowania — która warstwa ma się o tym dowiedzieć i próbować temu zaradzić. Postaraj się to napisać pod kątem łatwej rozszerzalności o kolejne metody logowania.

Naucz się analizować kod, wyszukiwać błędów, grzebać w dokumentacji, grzebać w internecie w poszukiwaniu rozwiązań czy wiedzy i naucz się myśleć samodzielnie a nie spamujesz pytaniami, które są uważane przez innych za troll.

To że posklejałeś z poradników działający kod np. na callbackach wcale nie oznacza że się ich nauczyłeś. Nauką jest zrozumienie dlaczego to działa tak a nie inaczej, ale do tego są potrzebne podstawy o których każdy tu pisze a ty twierdzisz że to nie jest potrzebne bo trzeba iść dalej. W tym przypadku zamiast nauczyć się podstawy jak działają funkcje, co robi return to idziesz w GUI,signale zaraz pewnie wjadą wątki nie wiedząc co się dzieje po wywołaniu "int Foo()". Zacznij od aplikacji konsolowej i sprawdź swoje możliwości z wykorzystaniem dokumentacji a nie poradników.