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

DAVIDOWITCH: heh, v bejvaly firme mi tudle techniku zakazali, protoze si nekde na netu precetli, ze "z funkce ma byt pouze jeden return" a prislo jim to jako super napad..

DAVIDOWITCH: Diky, neznal jsem. Vyzkousim jestli to dela to co chci a napis report (otazka je kdy :-)

JANFROG: V jazyce samotném skoro určitě nic není, ale gcc na to má:
c++ - Is there a compiler hint for GCC to force branch prediction to always go a certain way? - Stack Overflow
http://stackoverflow.com/...-a-compiler-hint-for-gcc-to-force-branch-prediction-to-always-go-a-certa

Já to mám rád protože na začátku funkce si ošetřím chyby (jako unlikely), a vlastní tělo je pak ve zbytku fce napsaný bez spousty indentace a dobře se to čte.

DAVIDOWITCH: Mozna ano, ale nevim, jek se to dela :-( Muzes dat nejaky priklad (C99) jak to udelat?

JANFROG: v tom tvém příkladu, nestačil by nějaký statický jump hint, místo změny kódu?

JANFROG: aha, no. já na mikrooptimalizace u toho, co se dělá fakt často, docela věřím. bohužel jsem vlastně už léta nic takového nepsal, a tedy neoptimalizoval (protože jsem vlastně s desktopovými pokusy skončil už dávno... a od té doby píšu víceméně jen skripty)

XCHAOS: Aha. V tom mem postu jsem vubec nenarazel na vyjimky a uvolnovani zdroju jako spis na fakt, ze i mikro-optimalizace jako mit fast-path bez skoku muze dost vyrazne pomoci. S vyjimkam to nesouviselo...