W dniu niedziela, 18 listopada 2018 10:10:22 UTC+1 użytkownik fir napisał:
> W dniu piątek, 16 listopada 2018 16:48:18 UTC+1 użytkownik s...@g...com
napisał:
> > > Czy w związku z tym zagadnienie niezmienników jest niepotrzebne? A może nadal
jest potrzebne i coś innego je zastępuje?
> >
> > 1. Wiedziałem co to jest.
> >
> > 2. Stosuję
> >
> > 3. Sam też stosujesz
> >
> > Najprostrze zastosowanie:
> > QList<int> lList = {0, 1, 2, 3, 4, 5};
> > for(int i(0); i < lList.size(); ++i)
> > // tu robisz coś z lList
> > W tej pętli niezmiennikiem sprawdzanym przed wejściem w pętlę i po kazdej
iteracji jest:
> > i < lList.size()
> >
> > Nieco bardziej ogólne jest:
> > QList<int> lList = {0, 1, 2, 3, 4, 5};
> > for(int& lItem : lList)
> > // tu robisz coś z lItem
> > W tym przypadku niezmiennikiem (ukrytym) jest fakt iteracji po wszystkich
elementach listy.
> >
> > 4. Zazwyczaj dalszych niezmienników w pętli nie sprawdzam. Głównie ze względu na
2 wady:
> > 4.1. Puchnięcie i zaciemnianie kodu.
> > 4.2. Spowolnienie programu.
> >
> > 5. Bardzo często sprawdzam parametry wejściowe funkcji (wierzę i stosuję coś w
rodzaju programowania kontraktowego).
> > 5.1. Wierzę w try, throw, catch (wyjątki obowiązkowo dziedziczone po
std::exception z opisem i kodem błędu).
> > 5.2. Nie wierzę w i nie cierpię Assert (to tak jak by bez ostrzeżenia uderzyć
kogoś w twarz bez dalszego komentarza).
> > 5.3. Toleruję wartości zwracane (jako informacje o błędach) i brak standaryzacji
w dostępie do opisów błędów w Qt.
>
> ostatnio odkrylem dosyc odkrywczy sposob
> dilowania (tj forme kodowanie obslugi bledow) z bledami w jezykach podobnych
> do c
>
> wymaga on pewnej poprawki do jezyka,
>
> (i jest opisany na clc, troche nie che mi sie tu opisywac bo nie lubie sie
powtarzac)
>
> jest on ogolnie ciekawy bo mz pokazuje co to jest normalne dilowanie z bledami i na
czym to normalne dilowanie z bledami normalnie polega (ma polegac)
>
> nawiasem mowiac w swietle tego asercje
> albo bledy przypadkowe (jak np zmienienie sie jakiejs komorki w rami i wyjatek typu
nielegalna instrukcja) nie sa normalnymi sposobami dilowania z bledami tylko pewnymi
case'ami nadspecjalnymi
>
> NORMALNY i najbardziej typowy sposob z
> handlowaniem z bledami w programie to zwykle zwrocenie informacji o bledzie do
funkcji w tyl - tylko ze nie powinno to byc mieszane ze zwracaniem poprawnej wartosci
w tym kanale w ktorym zwraca sie wartosci w sytuacjach niebledowych..
>
> dzis jesli ktos zwraca blad w tyl (jak rozne api robia) to ogolnie robi dobrze,
> tylko ze jesli wtyka kody bledow w wartosci zwracane to zarazem robi zle ;c
>
> https://groups.google.com/forum/#!topic/comp.lang.c/
p1CcmgZKkV4

albo ok niech, bedzie opisze po polsku


sposob polage on na tym


int x = foo(20,10) on error { printf("error"); }


polaga on na tym ze wywolanie kazdej funkcja ktora moze zwrocic error powinno
obsluzyc branch tj wstawic tam dowolny kod do obslugi bledu

po stronie ciala funkcji wyglada to tak ze, wychodzisz z funkcji nie przez return ale
inne slowo kluczowe np error

int foo(int a, int b)
{
if(a<b) error;

return a-b;
}

implementacja, ustawiasz po wyjsciu z funkcji jakas flage, np carry, zero czy cos w
tym stylu

niektore zalety

1. musisz jawnie napisac klauzule obslugi bledu (zacheca do klarownej obslugi)

2. w ciele wolanej funkcji obsluga bledow jest dosyc jasna i klarowna (zacheca do
klarownej obslugi)

obie strony zachecaja do klarownej obslugi, po prostu kodowanie bledow jako
normalnych stanow programu do czego obecne c jakos nie zacheca

jest to wielka zaleta ... kody sa bardziej kompletne, moga byc 'zamniete na bledy'

3. nie mieszasz wartosci zwracanej i kodu bledu (to mieszanie to syf)

jest to wielka zaleta ... kody sa czystsze

4. skladania jest wzglednie ladna (moze poprobuje poprawic to wyzej to draft)

(napewno sprobuje poprawic bo to zarys, nie wiem np co z tymi domyslnymi sygnalami,
tj ze skladnia do tego o czym troche nizej)

5.jest szybkie w runtime (chyba szybciej nie mozna, nie jestem pewien, kiedys mozna
pomyslec)

6, rozwiazuje duzo abstrakcyjnego chaosu, bo ludzi zastaawiaja sie jak dilowac z
bledami to jest tak naprawde poprawny sposob

to jest tez duza zaleta boludzi emaja sporo problemow ze zrozumieniem co robic z
bledami - to co ja tutaj proponuje jest tak naprawde dosyc poprawneym rozwiazaniem -
zwracasz bald wyzej, kod wywolywacza podejmie decyzje


dopuszczam lub rozwazam jeszcze opcje dla super leniwych, opcje opuszczania tych
klauzul (ew jakiegos zaznaczania ze sa opuszczane, nie ejestem pewien) w takim
wypadku, na kazdy zwrocony a nie zbranczowany blad lecialby sygnal do
zarejsetrowanego handlera eventow - co tez jest wygodne jak ktos jest superleniwy

pytaniem jest troche 1) czy dopuszczac opuszczanie tych branczy czy raczej to
poprostu zawsze wymuszac (do tego zdanie moga byc podzielone, ale raczej wydaje sie
ze na specjalna prosbe autora kodu przynajmniej (jakas opcja kompilaci czy cos nalezy
na o dozwolic)) 2) drygie pytanie czy na takie opuszczenie kompletnie ignorowac te
brancze czy zmuszac do oznaczania jakims prostym slowem , chocby "SIG" zeby bylo
wiadome
ze blad teoretycznie moez poleciec 3)
trzecie pytanie co robic w wypadku gdy taki nieobsluzony blad poleci,
najrozsadzniejsza opcja chyba wydaje sie wywalanie signal handlera z jakims domyslnym
kodem w tym handlerze (typu wywalenie message boxa z informacja
"error taki a taki w funkcji takiej a takiej zwrocony przez funkcje taka a taka,
nacisnij ok by zamknac program (ignoruj by zignorowac?"

lekko otwarta kwestia jest tez w jakis sporob te polecenie arror powinny zwracac info
o bledzie oraz co robic z wartoscia zwracana w tym wypadku (w duchu starego c
znaczyloby chyba ze jest undefined, ale ew mozna wymyslec cos innego)