Jak můžu opustit funkci

DogWithFleas

Re:Jak můžu opustit funkci
« Odpověď #240 kdy: 17. 07. 2018, 20:00:45 »
Chceš to rozebrat?
Kód: [Vybrat]
try {
    ...
    int rc = fx ();
    if (rc != 0)
        throw std::exception ("Error!");
    ...
catch (std::exception &e) {
    handle_exception ();
}

Tady jsou hned 2 chyby: Použití std::exception a text "Error!". To značně omezuje strukturování výjimek. Nejdříve bys jí měl udělat potomka:
https://www.tutorialspoint.com/cplusplus/cpp_exceptions_handling.htm dole.
Potom můžeš výjimky rozlišovat dle typu. Dále je dobré do nich umístit místo vzniku, text a kódové označení výjimky - obvykle číslo, ale například databáze používají pětiznakový string.

No hlavne ten kod toho pitomce z blogu je uplne blbe, "throw std::exception ("Error!");" je blbe a ani se nezkompiluje. Jestli nekdo takhle malo schopnej pouziva C++ a nekdo jeste min schopnej se z toho uci, tak se nedivim, ze se tu na patnacti stranach resi return a switch a nevyhody vyjimek...
https://en.cppreference.com/w/cpp/error/exception/exception


balki

Re:Jak můžu opustit funkci
« Odpověď #241 kdy: 17. 07. 2018, 20:49:37 »
Je zvláštní, že někteří lidé poté co vykonají velkou potřebu ve veřejném prostoru, mají ještě nutkání se v těch hovnech prohrabávat. Budiž.

Někde v polovině tohoto threadu jsem diskutujícím vytýkal, že pomíjejí kontext. Od té doby myslím jen Kiwi zdůraznil, že pokud píše v C, považuje následující za idiomatické. Různé jazyky mají různé pohledy na to, jak je dobré, aby kód vypadal. Většinou se vyplatí tohoto držet. Je komické se bavit o jediném exit pointu funkce v jazycích, které podporují výjimky, protože exit pointem může být jakékoliv volání funkce, které vyhodí výjimku (pokud to v dané funkci explicitně neošetřím, což zase podpírá smysl výjimek).

I když si Dijkstry považuji, nemyslím si že jeho téměř 50 let staré zásady strukturovaného programování nedoznaly za ta léta určitých změn a nelze je brát dogmaticky. Samozřejmě, že je lepší, když má funkce jen jeden exit point, ale abych toto pravidlo dodržel, nebudu kvůli tomu zavádět třeba 5 řídících proměných. Nakonec některé z těch zásad měly neméně slavné oponenty (Wirth, Knuth) a nemyslím, že kdokoliv z nás se komukoliv z nich rozhledem a vědomostmi alespoň přibližuje.

Abychom se dál nehrabali v těch hovnech, bylo by dobré, aby každý podpořil své tvrzení alespoň citátem nějaké uznávané autority. Takže pro začátek:

Nested conditional code often is written by programmers who are taught to have one exit point from a method. I've found that is a too simplistic rule. When I have no further interest in a method, I signal my lack of interest by getting out. Directing the reader to look at an empty else block only gets in the way of comprehension.
Martin Fowler - Refactoring

Myly "bodka", v hovnach sa hrabete teraz vy :P  Fowlera povazujem za velmi mudreho, ale v tomto s nim nie celkom suhlasim. Ano vyrastal som na pascale, kde to ani inak neslo robit. V niektorych jazykoch je navratova hodnota proste posledna hodnota spomenuta na konci bloku. Ano, ma to tu nevyhodu, ze clovek pouzije viacej riadiacich hodnot (najma, ked sa chce vyhnut prilisnemu zanoreniu). Ale nuti to cloveka viacej uvazovat o toku riadenia procedury, nez ked ukonci proceduru predcasne a tok riadenia je tak rozsekany. (A teraz uvazovat uz vam to von vyskocilo, ale vy by ste aj tak potrebovali vykonat nieco, uz nemozte, tak tam pridate redundantne volanie atd ...).  Vysrat sa do verejneho priestoru nebolo mojim cielom, bol som vsak zomlety Jirsakom - fanusikom predcasneho vypustenia bez diskusie hned ma zacal urazat autistickymi recami, ze neviem programovat.

Kit

Re:Jak můžu opustit funkci
« Odpověď #242 kdy: 17. 07. 2018, 20:59:33 »
Ano vyrastal som na pascale, kde to ani inak neslo robit.

Také jsem vyrůstal na Pascalu, ale už jsem z něj vyrostl. Posloužil dobře a je třeba jít dál.

Kiwi

Re:Jak můžu opustit funkci
« Odpověď #243 kdy: 17. 07. 2018, 22:08:16 »
"Požadovaný stav"? "Normální běh programu"? WTF?!
Žádný stav přeci není "požadovaný" a celý běh programu je "normální". Když si představím stavový diagram programu, nemám důvod některé uzly malovat nějak jinak. Program prostě reaguje a možné události a "chyba" je jen jednou z možných událostí. Záměrně píšu v uvozovkách, protože to je jen naše označení pro určitý stav. Ale to označení je dost zavádějící - chybou totiž ve skutečnosti je jakékoli neošetření/neuvažování možného stavu. Že mi nedojde paket je úplně stejně "normální" stav, jako že dojde. Pokud mám nabídku z 5 položek označených čísly 1-5, je stisk jakékoli klávesy stejně "normální". Přece není žádnou "chybou" pokud uživatel stiskne L a není důvod takovou situaci obsluhovat nějak zcela odlišně než číslice 1-5. Je to úplně normální situace, protože dotyčná funkce mi může vrátit cokoli, co se dá na klávesnici stisknout, a já s tím musím jako programátor počítat.
To je typický pohled programátora s klapkami na očích. Pro všechny ostatní je samozřejmě nějaký běh programu normální, a to takový, kvůli kterému ten program používají. Třeba když si chce uživatel vytisknout PDF dokument, je normální běh PDF prohlížeče takový, že uživateli nakonec z tiskárny vyleze papír s vytištěným dokumentem. Můžete mít v programu ošetřené úplně všechny chyby, ale pokud se uživateli ten dokument vytisknout nepodaří, bude oprávněně nadávat, že ten program je k ničemu.

Jeden extrém jsou programy, které s chybami vůbec nepočítají a neošetřují je. Druhý extrém jste popsal vy, a spočívá v tom, že se někdo soustředí jenom na ošetření chyb a zapomene, že kromě toho by ten program také měl ještě něco rozumného dělat.
Kde tvrdím, že se soustřeďuji jenom na ošetření chyb a zapomínám kvůli tomu, že má program taky něco rozumného dělat? Nebo jak jste na to přišel? Protože ošetřuji chyby stejně pečlivě jako kterýkoli jiný stav, mám podle vás klapky na očích? Co to pro boha melete za nesmysly?

Jaký mají výjimky kladný efekt na návrh programu? Co je správného na reagování na určité stavy nějakým úplně jiným kanálem někde v úplně jiné části programu? Postnul jsem dva články, na něž Kit napsal, že autor výjimky použil chybně. A jak je to tedy správně?
Správného je na tom to, že se na každý stav reaguje v té části programu, kde se na něj nějak reagovat dá. Například u toho tisku PDF může dojít k tomu, že v průběhu vykreslování stránky na tiskárnu dojde ke ztrátě spojení s tiskárnou. Vykreslovací kód s tím samozřejmě nic neudělá a ani s tím nic dělat nemá, na druhou stranu velice vhodné místo kde takovou událost řešit je kód pro interakci s uživatelem. Který může uživateli třeba zobrazit zprávu, že tiskárna bohužel přestala komunikovat, a nabídnout možnost vytisknout to na jiné tiskárně.
Vhodné místo, kde řešit takovou událost, je v modulu, který zajišťuje komunikaci s tiskárnou - například formou if error && attempt_cntr-- => retry. Pokud tiskárna nereaguje, generuje chybu volajícímu, tedy asi vykreslujícímu kódu. Ten se podle toho zařídí po svém - např. uklizením svého kontextu a propagováním chyby ze své úrovně - zatímco komunikační úroveň zajistila konzistenci svého kontextu a hlásila nahoru chybu s komunikací, vykreslovací modul zajistí konzistenci na své úrovni a hlásí nahoru chybu při vykreslování písmenka X. Volající modul uklidí svůj kontext a propaguje výš chybu při pokusu vytisknout 5. písmenko 10. řádku 23. stránky. Teprve tady někde se o tom zpraví uživatel a případně se mu nabídne, co s tím dál. Může se třeba rozhodnout, že dokument počínaje 23. stránkou dotiskne na jiné tiskárně jak sám naznačujete, nebo překontrolovat tiskárnu a pokračovat v tisku stránkou, kde došlo k chybě apod. Ale pokud do této úrovně spadne nějaká low level chyba "printer communication error", tak co se s tím dá na této úrovni rozumného udělat, kromě "milý uživateli, tiskárna nekomunikuje, hroutím se k zemi"? Mám tomu rozmět tak, že kdybyste takový pdf-prohlížeč psal vy, tak při nějakém nahodilém zajiskření v konektoru se tisk zhroutí a musel bych běžet k tiskárně, abych zjistil, kam až a jestli vůbec se něco vytisklo, abych to pak mohl ručně poslat někam jinam nebo to zkusit znova, tipuji, že nejlépe celé od začátku? Děkuji pěkně, to teda píšete opravdu "velmi kvalitní a robustní" software.

Soustředíte se na nepodstatné detaily a ne na to podstatné, co chtěl ten autor říci, tj. že reakce na chybu je přes výjimky izolována od místa jejího vzniku, což tady někteří neustále vyzdvihujete jako přednost, ale podle mě je to zcela špatně, protože dochází k narušení a ztrátě kontextu. Kdybych reagoval v místě vzniku chyby, nepotřebuji balit informace o ní do žádného objektu, protože všechny dostupné informace o ní mám v rámci jejího kontextu k dispozici. A naopak - vyhození nějakého objektu - byť odvozeného speciálně pro danou úroveň - nemůže tuto informaci a ten kontext nahradit. Ono je to problematické i u těch hardwarových výjimek, ale tím spíše nechápu, proč bych si podobným mechanismem měl komplikovat práci i tam, kde to vůbec není nutné.

Svým způsobem ti rozumím, chápu, že objekt může nést více informací než nějaký errorcode, že je to konzistentní oproti vracení errocodu (návratovou hodnotou? referencí? globální proměnnou? někdy tak, jindy onak?), ale to řešení přes try-catch-throw se mi vůbec nelíbí a myslím, že je velmi znepřehledňující a komplikující.

Vždycky jsem se snažil oddělovat testy chybových stavů od zbytku kódu - IMHO je to ospravedlnění pro returny uprostřed funkcí - nejprve otestuji základní podmínky a případně skončím s chybovým kódem. Dále algoritmus pokračuje už s vědomím, že některé situace v daném bodě nastat nemohou - hodnoty jsou smysluplné, prostředky jsou alokované atp. Ale pořád je ještě spousta situací, kdy se testují podmínky v rámci samotného algoritmu - a tam mi try-catche jeho zápis neuvěřitelně zatemňují a komplikují.

Při ignorování/zapomenutí ošetření chyb z bezprostředně nižší úrovně vnímám výjimky spíš jako debugovací nástroj, ale rozhodně nesdílím názor, který tu opět několikrát padl, že se na to v podstatě díky výjimkám můžu vykašlat a chytit ji někde o 3 úrovně výš. Takto programovat je podle mě prasečina. Důsledné používání principu reinterpretace a případné propagace reinterpretované chyby se mi osvědčil do takové míry, že výjimky vnímám takto negativně.

Re:Jak můžu opustit funkci
« Odpověď #244 kdy: 17. 07. 2018, 22:45:30 »
Kde tvrdím, že se soustřeďuji jenom na ošetření chyb a zapomínám kvůli tomu, že má program taky něco rozumného dělat? Nebo jak jste na to přišel?
Netvrdíte to nikde, vy to přímo děláte – tady v komentářích. Přišel jsem na to tak, že jsem četl váš komentář.

Vhodné místo, kde řešit takovou událost, je v modulu, který zajišťuje komunikaci s tiskárnou - například formou if error && attempt_cntr-- => retry. Pokud tiskárna nereaguje, generuje chybu volajícímu, tedy asi vykreslujícímu kódu. Ten se podle toho zařídí po svém - např. uklizením svého kontextu a propagováním chyby ze své úrovně - zatímco komunikační úroveň zajistila konzistenci svého kontextu a hlásila nahoru chybu s komunikací, vykreslovací modul zajistí konzistenci na své úrovni a hlásí nahoru chybu při vykreslování písmenka X. Volající modul uklidí svůj kontext a propaguje výš chybu při pokusu vytisknout 5. písmenko 10. řádku 23. stránky. Teprve tady někde se o tom zpraví uživatel a případně se mu nabídne, co s tím dál. Může se třeba rozhodnout, že dokument počínaje 23. stránkou dotiskne na jiné tiskárně jak sám naznačujete, nebo překontrolovat tiskárnu a pokračovat v tisku stránkou, kde došlo k chybě apod. Ale pokud do této úrovně spadne nějaká low level chyba "printer communication error", tak co se s tím dá na této úrovni rozumného udělat, kromě "milý uživateli, tiskárna nekomunikuje, hroutím se k zemi"?
Dobře jste popsal, jak fungují výjimky. Přičemž „volající modul uklidí svůj kontext a propaguje výš chybu“ je jedna z podstatných vlastností výjimek – ten volající modul nemusí o chybě vědět vůbec nic, jenom ví, že došlo k nějaké chybě, tak že má  po sobě uklidit a propagovat chybu dál. Případně doplní k chybě další informace, pokud nějaké má. Další z výhod je, že až do toho místa vyřešení chyby doputuje ta původní low-level výjimka, takže je možné uživateli zobrazit detaily toho, co se stalo. Když to budete řešit návratovým typem, o tyhle detailní informace přijdete, budete tam mít tak maximálně „Chyba -1 – něco je špatně s tiskárnou“. A i to bude dobrý výsledek, protože to znamená, že vykreslovací modul počítal s tím, že bude vykreslovat na tiskárnu, tak pro to měl vyhrazený chybový kód.

Mám tomu rozmět tak, že kdybyste takový pdf-prohlížeč psal vy, tak při nějakém nahodilém zajiskření v konektoru se tisk zhroutí a musel bych běžet k tiskárně, abych zjistil, kam až a jestli vůbec se něco vytisklo, abych to pak mohl ručně poslat někam jinam nebo to zkusit znova, tipuji, že nejlépe celé od začátku? Děkuji pěkně, to teda píšete opravdu "velmi kvalitní a robustní" software.
Máte bujnou fantazii, já jsem nic takového nepsal. Příště zkuste nehodnotit ostatní podle vašich vlastních hloupých nápadů.

Soustředíte se na nepodstatné detaily a ne na to podstatné, co chtěl ten autor říci, tj. že reakce na chybu je přes výjimky izolována od místa jejího vzniku, což tady někteří neustále vyzdvihujete jako přednost, ale podle mě je to zcela špatně, protože dochází k narušení a ztrátě kontextu.
Ke ztrátě kontextu dojde jedině tehdy, pokud ten, kdo vyhazuje výjimku, kontextové informace do výjimky nezabalí. To, že reakce na výjimku je izolovaná od místa jejího vzniku, je správně – vychází to z principu jedné odpovědnosti, kdy každá ucelená část kódu (např. funkce) má dělat jen jednu věc. Pokud ten kód řeší například tisk, je už jeho zodpovědností ten tisk a neměl by řešit další věci, jako např. vypořádání se s výjimkou.
 
Kdybych reagoval v místě vzniku chyby, nepotřebuji balit informace o ní do žádného objektu, protože všechny dostupné informace o ní mám v rámci jejího kontextu k dispozici. A naopak - vyhození nějakého objektu - byť odvozeného speciálně pro danou úroveň - nemůže tuto informaci a ten kontext nahradit.
V místě vzniku té výjimky nemusíte mít informace ani prostředky potřebné k vyřešení té výjimky. Zabalit informace o kontextu výjimky do objektu je sice pracné, ale pokud chcete na výjimku reagovat pořádně, nic jiného vám nezbývá. Ostatně když to porovnáte s vaším postupem – přibalit ty informace do návratového typu, musíte tam ty informace přibalovat také, a ještě navíc o to musíte rozšířit ten návratový typ.

to řešení přes try-catch-throw se mi vůbec nelíbí a myslím, že je velmi znepřehledňující a komplikující.
To je možné, ale pořád je to milionkrát lepší, než když musím myslet na to, že tahle funkce sice podle logiky věci může vracet jen nezáporná čísla, ale někdo se rozhodl, že záporná v tom případě zneužije k hlášení chyb. Takže nejprve musím zjišťovat, zda vlastně funkce skončila úspěšně nebo neúspěšně, a pak musím paralelně vedle sebe řešit obě varianty. A navíc mám k zakódování informací o chybě k dispozici půlku integeru, to opravdu není mnoho.

Ale pořád je ještě spousta situací, kdy se testují podmínky v rámci samotného algoritmu - a tam mi try-catche jeho zápis neuvěřitelně zatemňují a komplikují.
Asi bych potřeboval vidět konkrétní příklad, takhle netuším, co přesně vám připadá zatemňující a komplikující.

Při ignorování/zapomenutí ošetření chyb z bezprostředně nižší úrovně vnímám výjimky spíš jako debugovací nástroj, ale rozhodně nesdílím názor, který tu opět několikrát padl, že se na to v podstatě díky výjimkám můžu vykašlat a chytit ji někde o 3 úrovně výš. Takto programovat je podle mě prasečina. Důsledné používání principu reinterpretace a případné propagace reinterpretované chyby se mi osvědčil do takové míry, že výjimky vnímám takto negativně.
Rozhodně by to nemělo být, že se na výjimku vykašlu – to, že jí budu beze změny propagovat dál, má být vždy vědomé rozhodnutí. Kvůli tomu třeba Java zavedla ty nenáviděné kontrolované výjimky – aby se jimi programátor musel zabývat. Programátoři to bohužel zvládají obejít i tak. Problém je v tom, že výjimka by se neměla reinterpretovat, spíš by se k ní měly nabalovat další informace – tj. jedna instance výjimky by postupně měla implementovat další rozhraní. S tím mají staticky typované jazyky problém.


n

Re:Jak můžu opustit funkci
« Odpověď #245 kdy: 17. 07. 2018, 23:22:22 »
Nechybí ti tam náhodou releaseMem() ve větvi if(!hwInit()) ?

Koukám, že chybí, chyba při kopírování. Normálně je odeslání chyby zabaleno v makru, tady jsem to ručně rozepsal...

BTW: Ten mutex, thread a queue není třeba uklízet?

Jo, ten se uklidí. Při initu jsou handle NULL. Funkce releaseMem testuje ty pointery a pokud je některý pointer NULL, uvolní ho. Takže bez ohledu na místo chyby se paměť uvolní...

Zlate C++(11+), tohle vsechno resi RAII(i kdyz ta zkratka je zavadejici), mutexy, dealokace(uvolnovani jakychkoli prostredku) v destruktoru, ktery je automaticky volany pri vypadnuti ze scopu. V podstate v novejsim(11+) C++ pri rozumnem programovani o memory leaky(a NEJEN - o jakekoli resource leaky) zakopnete jen velmi vyjimecne.
Jinak samozrejme souhlasim (dnes necekane i s)Kitem a PetrM. Tohle je klasika:
Kód: [Vybrat]
1) checknout chybne vstupy - pripadne vyhodit chybu
2) specialni hodnoty - vyhodit specialni vysledek
3) klasicke zpracovani, behem nehoz pokud natrefime na chybu, tak ji vyhodime co nejdriv.
....
oproti Balkiho(jak psal Kiwi):
Kód: [Vybrat]
1) checkneme chyby
      ...nekolikrat zanorene 2) checkenem specialni hodnoty
         ...nekolikrat zanorene... 3) delame vypocet.
      ... nekolikrat zanorene totalne neprehledne zacneme resit elsy na specialni vstupy
    ...a tady idealne dalsi polozapomenute elsy na chyby
     

To je "prehledne" az to boli... to vede k ruznym Xkrat zanorenym ifum, nebo podminkam typu:
Kód: [Vybrat]
while (neni chybaA && neni chybaB .... && neni chybaXY) {
...
(a "idealne" vevnitr vnorene cykly s o jednou podminkou min)

.. nebo jeste lepsi:
Kód: [Vybrat]
while (nenastala_jakakoli_blize_nespecifikovana_chyba_o_ktere_vim_prd) {
...
}
.. anebo nejlepsi:
Kód: [Vybrat]
while (neni chybaA) {
  if (v poradku - delej_neco_co_nema_samoosobe_vyznam_ale_oddel_to_do_funkce_jmenem_wtf)
    if (v poradku - wtf_fce_2)
        ....
}
 

DogWithFleas

Re:Jak můžu opustit funkci
« Odpověď #246 kdy: 17. 07. 2018, 23:25:19 »
Soustředíte se na nepodstatné detaily a ne na to podstatné, co chtěl ten autor říci, tj. že reakce na chybu je přes výjimky izolována od místa jejího vzniku, což tady někteří neustále vyzdvihujete jako přednost, ale podle mě je to zcela špatně, protože dochází k narušení a ztrátě kontextu. Kdybych reagoval v místě vzniku chyby, nepotřebuji balit informace o ní do žádného objektu, protože všechny dostupné informace o ní mám v rámci jejího kontextu k dispozici. A naopak - vyhození nějakého objektu - byť odvozeného speciálně pro danou úroveň - nemůže tuto informaci a ten kontext nahradit. Ono je to problematické i u těch hardwarových výjimek, ale tím spíše nechápu, proč bych si podobným mechanismem měl komplikovat práci i tam, kde to vůbec není nutné.
A co kdyz nemas zadny vliv na misto vzniku, co kdyz tu knihovnu psal nekdo uplne jiny? Ma ti ji propagovat pres vsechny ty returny? Co kdyz to ani neni mozne (protoze treba vraci int v celem jeho rozsahu)? Budes kazdy return z kazde funkce resit pres if? Citelnost utrpi.

Treba ve tvem kontextu (embedded) jsou vyjimky na skodu, ale to preci neznamena, ze jsou na skodu obecne.

n

Re:Jak můžu opustit funkci
« Odpověď #247 kdy: 17. 07. 2018, 23:30:19 »
Ok, vy si kodte taky softver, co vam nespracuje vstup na vystup, lebo vam sa nepaci. Ked sa vstup ale uctuje, tak sa nemoze vyparit. Musi sa oznacit patricne spracovat, opravit a oznacit ako chybny pre dalsie pouzitie. Ono, ked sa spracuva kvantum dat realtime a ide zo modulu A do modulu B cez ine moduly, tak sa asi zakaznik spyta, ze kam mu nieco zmizlo, nie?

Účetnictví není moc realtime, tam se prodlevy do několika sekund snesou. Pokud se něco nepovede, je potřeba vyhodit a zalogovat výjimku. V C to moc nejde a tak se na to vymýšlí různé berličky, i když jsou vcelku zbytečné.

To nie je uctovnictvo.

Viděl jsem jednu skutečně realtime aplikaci v C, která ze země řídí přistání letadel pomocí radarů a dalších senzorů. Pokud nejde o život, jde o ho*no. Před touto aplikací však mám respekt.
Aplikace tohoto typu((kde zalezi na zivotech, nebo hodne velkych prachach) se vetsinou pisou v omezenem C, kde se prostredky nealokuji za behu, ale na zacatku a jsou presne spocitane jeste pred zacatkem behu, takze k leakum nedochazi;  prekladace i cely behovy system je certifikovany, testovaci systemy jsou certifikovane, kazdy prd je certifikovany... jako nechtel bych se do toho sveta vratit, ale neco do sebe to ma...

Kit

Re:Jak můžu opustit funkci
« Odpověď #248 kdy: 18. 07. 2018, 00:07:44 »
Viděl jsem jednu skutečně realtime aplikaci v C, která ze země řídí přistání letadel pomocí radarů a dalších senzorů. Pokud nejde o život, jde o ho*no. Před touto aplikací však mám respekt.
Aplikace tohoto typu((kde zalezi na zivotech, nebo hodne velkych prachach) se vetsinou pisou v omezenem C, kde se prostredky nealokuji za behu, ale na zacatku a jsou presne spocitane jeste pred zacatkem behu, takze k leakum nedochazi;  prekladace i cely behovy system je certifikovany, testovaci systemy jsou certifikovane, kazdy prd je certifikovany... jako nechtel bych se do toho sveta vratit, ale neco do sebe to ma...

To souhlasí. Proto jsem vzpomínal Fortran, který tyto certifikace má a je pro podobné účely mnohem výhodnější. Je v něm docela dost užitečných vychytávek, které C/C++ nemá a zřejmě je ani mít nebude.

n

Re:Jak můžu opustit funkci
« Odpověď #249 kdy: 18. 07. 2018, 00:27:27 »
Viděl jsem jednu skutečně realtime aplikaci v C, která ze země řídí přistání letadel pomocí radarů a dalších senzorů. Pokud nejde o život, jde o ho*no. Před touto aplikací však mám respekt.
Aplikace tohoto typu((kde zalezi na zivotech, nebo hodne velkych prachach) se vetsinou pisou v omezenem C, kde se prostredky nealokuji za behu, ale na zacatku a jsou presne spocitane jeste pred zacatkem behu, takze k leakum nedochazi;  prekladace i cely behovy system je certifikovany, testovaci systemy jsou certifikovane, kazdy prd je certifikovany... jako nechtel bych se do toho sveta vratit, ale neco do sebe to ma...

To souhlasí. Proto jsem vzpomínal Fortran, který tyto certifikace má a je pro podobné účely mnohem výhodnější. Je v něm docela dost užitečných vychytávek, které C/C++ nemá a zřejmě je ani mít nebude.

S Fortranem mam prilis male zkusenosti, takze si nedovolim vubec nejake toto porovnavat, ci dokonce hodnotit. Chtel jsem tim jenom rict, ze C/C++ je relativne velmi presne specifikovany jazyk(samozrejme neni bezchybny - zvlaste vzhledem ke kouli na noze vyplyvajici z dodrzovane zpetne kompatibility s davnymi(dnes uz prokazetelne spatnymi) rozhodnutimi v minulosti), kde omezena mnozina jazyka muze garantovat presne a dobre odhadnutelne/"predikovatelne"(to snad umi kazdy jazyk, ale ne vzdy je jednoduche domyslet dusledky) chovani v realnem svete.

.

Re:Jak můžu opustit funkci
« Odpověď #250 kdy: 18. 07. 2018, 02:13:56 »
Pro mainstreamove/aplikacni programovani je to neocenitelny konstrukt.
A proto nové jazyky jako Rust nebo Go výjimky nemají?

Go je odpad.
A Rust má docela pěkné řešení ve stylu Left/Right, ale docela by mě zajímalo, jak to bude škálovat, když se člověk pustí do nějakého aplikačního vývoje a ne jen low-level.
Pokud jsi takhle hotov se vším, nemá smysl diskutovat. Ale u tebe mne to překvapilo. Nepříjemně.

Spousta veci stoji za dlouhe a peclive zvazeni.

Ale fakt ne Go, kde je zoufale videt, ze autori minuli 30 let vyvoje v programovacich jazycich a pak si rekli, ze to zkusi jeste jednou, tentokrat snad lepe.
Moudří lidé často používají slova jako zpravidla, obvykle a většinou, protože ví, jak problematické je vynášení kategorických soudů. To jen pro hlupáky jsou všichni hloupí.

balki

Re:Jak můžu opustit funkci
« Odpověď #251 kdy: 18. 07. 2018, 06:22:15 »
Moudří lidé často používají slova jako zpravidla, obvykle a většinou, protože ví, jak problematické je vynášení kategorických soudů. To jen pro hlupáky jsou všichni hloupí.

Moudří lidé takové slova nepoužívají, protože je to zbytečná slovní vata. Moudrý poslucháč chápe, že něco v určitém kontextu prostě neplatí.

balki

Re:Jak můžu opustit funkci
« Odpověď #252 kdy: 18. 07. 2018, 06:27:03 »
Moudří lidé často používají slova jako zpravidla, obvykle a většinou, protože ví, jak problematické je vynášení kategorických soudů. To jen pro hlupáky jsou všichni hloupí.

Moudří lidé takové slova nepoužívají, protože je to zbytečná slovní vata. Moudrý poslucháč chápe, že něco v určitém kontextu prostě neplatí.

Teda čo sa týka urážok jazyka go, je kontext niekde v zadeki. Osobne ten jazyk nepoznám, ale asi budú mať dôvod, prečo rôzne vychytávky odignorovali.

Re:Jak můžu opustit funkci
« Odpověď #253 kdy: 18. 07. 2018, 07:34:46 »
Pro mainstreamove/aplikacni programovani je to neocenitelny konstrukt.
A proto nové jazyky jako Rust nebo Go výjimky nemají?

Go je odpad.
A Rust má docela pěkné řešení ve stylu Left/Right, ale docela by mě zajímalo, jak to bude škálovat, když se člověk pustí do nějakého aplikačního vývoje a ne jen low-level.
Pokud jsi takhle hotov se vším, nemá smysl diskutovat. Ale u tebe mne to překvapilo. Nepříjemně.

Spousta veci stoji za dlouhe a peclive zvazeni.

Ale fakt ne Go, kde je zoufale videt, ze autori minuli 30 let vyvoje v programovacich jazycich a pak si rekli, ze to zkusi jeste jednou, tentokrat snad lepe.
Moudří lidé často používají slova jako zpravidla, obvykle a většinou, protože ví, jak problematické je vynášení kategorických soudů. To jen pro hlupáky jsou všichni hloupí.

A proto take pisi, ze "Spousta veci stoji za dlouhe a peclive zvazeni."

Ale na druhou stranu... clovek nemuze meditovat nad kazdym nesmyslem, to by pak nedelal nic jineho.

Re:Jak můžu opustit funkci
« Odpověď #254 kdy: 18. 07. 2018, 07:42:54 »
Podmínky testuji sekvenčně. Každá zaloguje vysvětlení. Máš nějaký příklad?

Přesněji: Napiš ukázku, jak bys to udělal ty a já to refaktoruji do podoby, jak bych to dělal já.

Zhruba neco takoveho:

Kód: [Vybrat]
val readyA = isReadyAForDay(d)
val readyB = isReadyBForDay(d)
val readyAlternativeA = isReadyAlternativeForDay(d)
...

val ready = (readyA & readyB) | (readyAlternativeA & something)

log.debug("Operace Robert Dabel day=${d} is ready=${ready} (readyA=${readyA}, readyB=${readyB}, readyAlternativeA=${readyAlternativeA}) ")

Posunout logovani dovnitr jednotlivych isReadyX _neni_ alternativa.