REDGUY: no ale tím, že mě na něco nasměruješ ty, to spíš oddálí :) nevím, dostal jsem se k tomu přes "Sapir–Whorf hypothesis or Whorfianism, is a concept-paradigm in linguistics and cognitive science that holds that the structure of a language affects its speakers' cognition or world view."

XCHAOS: Ten samej Graham, o kterym jsem mluvil v souvislosti s Lispem? Zda se, ze jsi na dobre ceste 8))

Paul Graham (computer programmer) - Wikipedia
https://en.wikipedia.org/wiki/Paul_Graham_(computer_programmer)#The_Blub_paradox

Linguistic relativity - Wikipedia
https://en.wikipedia.org/wiki/Linguistic_relativity#Programming_languages

DAVIDOWITCH: Jj, jasny. Sice mi pripada, ze jde spis o to jaky ma rozhrani ten stream (srovnano treba s volanim destruktoru joinable std::thread) nez obecnou vadu RAII ale rozumim. Mit na zreteli kontext ve kterym vyvijim smysl dava.

DAVIDOWITCH: Co to je RIAA?

KOJA: Spravne by to asi melo bejt "nema rad slepe spolehani na to ze RIAA uklidi jak ma".
Myslim ze na soubory mame specialni wrapper kterej proste jeste bere pointer na nas logger.. ale nikdo to moc nepouziva protoze u nas to ze doslo misto na disku a neni kam udelat fflush je neco co se bezne nedeje a kdyz, tak to holt proste o kus pozdejc segfaultne, nekdo na to koukne ocima a po naprave situace process zrestartuje.

DAVIDOWITCH: Hm, jo, s tema souborama je to prusvih. Proste close neni cista destrukce, je to nejakej rekneme fflush + fclose (u kteryho ted uz snad muzes zarucit, ze projde...?). Ten flush musi byt zvlastni volani. Coz znamena, ze to budes muset hlidat, a bude se na to zapominat. Opruz.

DAVIDOWITCH: Copak o to, na nejaky flamovani uz jsem moc starej, to me nezajima. Tomuhle uz rozumim. Taky to nezni tak senzacne jako , ze nekdo nema rad RAII ;-)

KOJA: Tenhle rant se vesmes tyka ciste pouzivani std::streamu, ktery samy od sebe nelogujou. A nahrazovat se to ma tim ze veci explicitne zavres v objektech a mistech ktera kontrolujes (abys mohl logovat), misto toho abys to nechal zavrit tim ze zabijes objekt kterej nekontrolujes (a nemuze logovat). Takze nic moc nazi flamewar worthy :-)

DAVIDOWITCH: Asi bych s vasim safety guy rad podiskutoval. Nerikam, ze nema pravdu ale je to zajimavej pristup k veci. Prvni co me napada je, ze stejne musis logovat protoze jsou situace kdy ani tvuj error handling nebude fungovat jak zamysleno (bug, hw chyba ...). Takze pokud clovek loguje a logy monitoruje, tak faily v destruktoru zalogovat neni tak nesmyslny, ne? A propos - cim teda nahrazejete (nebo by vas SG rad nahradil) RAII?

ANT_39: Nas nejvic "safety conscious" guy hodne nema rad RIAA, protoze "destruktory nemuzou reportovat chyby". Takze kdyz zkusis zavrit soubor a dojde k nejaky chybe, tak std::stream to (udajne) nema jak nahlasit. Na druhou stranu, v tom co delam je to uplne burta, takze to je jen takovy doplneni k debate :-D

ANT_39: Jeste bych k tomu doplnil, ze ten "náš" coding style dost trpi kdyz se alokuje nejaky resource cyklicky. Vypada to nejak takhle:

for (...) {
    bar_destroy(&bar);
    err = bar_create(&bar);
    bail_error_null(err, bar);
    /* Tady se pak s time barem pracuje.  */
}

Je tam ten neintuitivni pattern uvolnovani zdroje nez se alokuje. Ale tim, jak ty funkce funguji (destroy nuluje predany ukazatel, destroy NULLu je nop), tak to vsechno do sebe zapadne, a dela to to, co ma.

Taky pouziti v makrech neni uplne idealni, protoze to makro potom schovava baily, ktery pouziva, prepisuje err, prestoze to neni zrejme, a tak. Idealne by se takovy makro expandovalo na ({statement expression}), melo by svuj lokalni bail (deklarovany pres __label__), a svuj vlastni error code. V podstate by se chovalo jako funkce, akorat by to generovalo nejaky kus kodu, a pouzivalo by se taky tak: err = blah_that_happens_to_be_a_macro(...); bail_error(err);. Ale tyhle vyfikundace mi samozrejme (a pochopitelne) hodi na hlavu code reviewer, protoze je nikdo nezna.

DAVIDOWITCH: Oproti jinemu C zapisu. V C++ tohle IMHO z velke casti nemusim resit. Misto bailovani vyhazujes vyjimky, vsechny zdroje alokujes pres RIAA (vcetne zmen stavu), vsechno to zapadne do sebe a ten vyslednej kod je taky prehlednej. (Asi. Priznam se, ze na velke C++ codebase nemam odkrouceno X let, takze moc nevim, jestli a jak to funguje v praxi. Vyjimky jsou urcite dost konfliktni tema.)

TYCHOVRAHE: pardon, nerek sem ze v nasem pripade slo o c++. u c tomu rozumim

ANT_39: Usnadnuje oproti jinemu C zapisu, nebo oproti C++?
Ja, popravde, vyhodu v jedinem returnu nevidim.

Ale libi se mi ten zapis s goto, je to vyrazne lepsi nez nejaka nested-if zbesilost jen aby probuh nebylo goto.

KLEINZACH: My mame ve firme takovej zvlastni coding style zhruba tohohle typu:

int funkce(...)
{
    int err;
    bar_t *bar = NULL;

    err = foo(...);
    bail_error(err); /* if (err != 0) { log; goto bail; } */

    err = bar_create(&bar, ...);
    bail_error_null(err, bar); /* if (err != 0 || bar == NULL) { log; goto bail; } */

bail:
    bar_destroy(&bar); /* if (bar != NULL) { Nejaky destruktor }; bar = NULL; */
    return err;
}

Zezacatku me to dost stvalo (prisel jsem z C++, a absence automaticky vyvolavanych destruktoru me dost silne iritovala), ale celkem rychle jsem si zvykl, a jiste vyhody v tom vidim. Je to pravidelny, prehledny pro code review, celkem snadno je videt chybejici volani destruktoru. Jeden return z toho pak tak nejak vyplyva, a fakt je ten, ze to code review dost usnadnuje.

Nutno rict, ze duvody, proc se ten system pise v C, jsou prevazne historicke, na vykon nebo pametovy footprint se moc nejede. (Jedna se o programovani routeru, ten hlavni vykon odvadi custom ASIC, a v C se pise to integracni lepidlo mezi command line, protocol stackem, webovym rozhranim, perzistenci, a zejmena SDK, ktery resi ten offloading samotny).

KLEINZACH: A to sem myslel že naše neshody ohledně pragma once jsou absurdní...


JANFROG: kouknu pak na sem, fakt mě zajímá jestli dělá reorder nebo dává hint instrukce