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

XCHAOS: Heh, tobe se clovek nezavdeci. Kdyz ti napisu, ze mas nebo blbe, tak se vztekas. Kdyz i jen kliknu na to jedno maly blby minusko, taky se vztekas. Jestli tak spatne snasis kritiku ode me, mozna by sis me mel zablokovat, misto aby ses ponizoval timhle ufnukanym zalovanim, nemyslis?

Anyway, proc minus? Protoze snazit se ti znova vysvetlit to, co jsi nepochopil uz pred tema x rokama, co jsem ti to vysvetloval poprve, mi prijde jako zbytecne. Takze proc se snazit, kdyz staci minus, ze?

Nicmene, jo, nekolik veci v [ XCHAOS @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] je prekvapive pricetnejch. Napriklad každá posedlost použitými prostředky místo dosaženými cíli: kdybys tohle aplikoval na svoji posedlost slunecni energii... hmmm.. 8)))

JANFROG: no že prostě goto ti neaktivuje věci, které souvisí s opuštěním scope. Vyvolání throw() někde uvnitř try{} bloku (v C++) podle mě ano (i když REDGUY dal minus, tak se ho zeptej, které části toho textu dal minus). Když si to v C nasimuluju pomocí longjmp(), tak se jen obnoví úroveň stacku zaznamenaná v bodě setjmp() (podle mě) - ale jinak k žádnému automatickému uvolnění dalších zdrojů systému nedojde (jako ostatně v C nikdy)

XCHAOS: Ted jsem mirne ztracen. Jak to souvisi s vyjimkami?
KOJA: Taky se ztracim...