REDGUY: no, až na to, že v C jsou moje nebezpečná okénka alternativa k traktoru, který nemá kapotu a tudíž ani okénka, což je z tohoto hlediska bezpečné :-)

hele, tvoje debata je marná, protože prostě nedokážeš vyvrátit výrok, že "v C lze snadno napsat potenciálně nebezpečný či chybný kód, který se bez varování přeloží". to, že se nebezpečný či chybný kód v C dnes většinou nepíše, je spíše zásluha jakési "profesní tradice", než že by dostupné konstrukce naplňovaly tvojí definici "nerozbitosti".

můj framework v tomhle ohledu nebude lepší ani horší.

Hele, ten SIGFPE, deleni nulou. Vzdyt IEEE754 deleni nulou v pripade precise modelu jednoznacne definuje, ne? kdyz delis kladny cislo, tak deleni kladnou nulou je +inf, deleni zapornou je -inf. Kdyz zaporny tak opacne.
Az kdyz delas 0/0, tak mas NaN a serious problem.
Ty inf hodej vyjimku vzdycky, nebo jen ve fast modelu, nebo...

Tak prosim chvili premejslej. Pokud bys delal umelej SIGFPE abys delal exceptiony, tak musis:
1) (jednou) Zaregistrovat signal handler. Signal handler neni context-aware, tudiz potrebujes mit kod kterej bude z dalsich dodatecnejch informaci schopnej identifikovat co se ma vlastne udelat, a kam se ma vlastne skocit.

2) (tolikrat kolik hazis exception) Vygenerovat signal. Jsou zde dve varianty:
2.a) kill(), proste ten signal manualne poslat. Jinak receno, dva kontext switche, pac je to syscall.
2.b) Fakt udelat floating point exception, tzn. umyslne delit nulou. Dva kontext switche + ten interrupt prijde od CPU (coz netusim jestli pridava nejakou cenu navic, ale implicitne bych veril ze muze).

3) (pro vyvojare) Bud ustanovit omezeni, ze SIGFPE je signal kterej aplikace pouzivajici tvuj jazyk nemuze odchytavat (coz by bylo dost smutny), nebo vykonstruovat system kterej umozni identifikovat jestli je to SIGFPE pac se neco posralo, nebo SIGFPE pac delat exception handling.

4) (tolikrat kolik delas odchytanou exception) Kdyz uz jsme si ten signal vygenerovali, musis odchytit signal. Coz by mel bejt dalsi nejmin jeden (spis dva?) context switch.

Nevidim vyhody.

(BTW...nikdy jsem třeba o C++ neřekl, že je "rozbité", jen proto, že mi přijde moc složité, a programuje se v něm jinak, než jsem zvyklý...)

REDGUY: nesouhlasím s tvojí definicí "rozbitosti", tečka.

"funguje to jinak, než jsem zvyklý" není ekvivalentní výroku "je to rozbité".

XCHAOS: abychom konečně opustili tuhle arénu, která mě už vůbec nebaví. - to me neprekvapuje. Akorat mam obavu, ze to jen a jen znamena ze rozbite kontexty pujdou k ledu a za par mesicu je zase vythanes, zacnes rikat jak jsou super a znovu ti budeme muset ukazat jak a proc jsou rozbite. Pokud dobre pocitam, tohle uz je aspon druha iterace debaty na tohle tema.

jestli by standardní proces odchytávání signálů v C šlo nabindovat na setjmp/longjmp standardní POSIX libc error handling ? - co presne tim chce basnik rici?

ISTEVE: popravdě, o režii odchytávání signálů v Unixu toho až tak moc nevím... předpokládal jsem, že právě jde o to, že dokud signál nenastane, že se nic neděje... že je to jenom nějaká tabulka pointerů na handlery, které se zavolají až když ten signál nastane...

(K ISTEVE bych mel dodat -- ten SIGFPE trik byl kvuli tomu, ze ta cilova instrukcni sada neznala sw interrupt)

Jo, v UNIXovym prostredi je to odchytitelnej signal. Presnejc by to mel bejt interrupt od procesoru, kterej kernel vezme a udela z toho SIGFPE. (Interesting fact: kdysi davno pri portovani nejakyho unixu se pouzil prave hw interrupt pri deleni nulou jako zpusob jak provadet syscally, spolu s specifickym nastavenim registru aby se to odlisilo od regulerni chyby)

Jakozto nerealne silenej mikrooptimizator ale predpokladam vis, ze signaly jsou kurevsky drahy, delat pres to exception-like veci je naprosto neuveritelny zahazovani CPU cyklu totalne bez duvodne, obzvlast kdyz to clovek srovna s setjmp/longjmp.

REDGUY: když jsme u toho dělení nulou... to je mimochodem odchytitelný signál, ne ? abychom konečně opustili tuhle arénu, která mě už vůbec nebaví... co takhle popřemýšlet, jestli by standardní proces odchytávání signálů v C šlo nabindovat na setjmp/longjmp standardní POSIX libc error handling ? pokud bude adresa získaná pomocí setjmp uložena v globální proměnné, tak snad nic nebrání tomu, aby handler ošetřující signál provedl longjmp, ne ?

(napadlo mi, že takhle by šlo odchytit vlastně i Ctrl+C .... jednoduše, Ctrl+C by se pak dalo odchytit na konci try { } bloku jako cokoliv jiného... a pokud se to neodchytilo, tak by ovšem program skončil... vlastně není jasné, jestli je to "očekávané" chování, ale každopádně by to bylo elegantní chování)

DAVIDOWITCH: víceméně ... z debaty vyplynulo, že bude muset mít :-) a je fakt, že jsem to zvlášť neřešil, to se přiznám.

prostě ve všech mých flow-control makrech budeš muset místo "break" psát "escape". ("continue" naproti tomu bude použitelné beze zeměny... BTW, pro vyskočení z kontextu bude bohatě stačit "continue" místo "break", a bude to ještě čitelnější...)

XCHAOS: Ma ten remember/forget mit explicitni "terminate context now!" makro? Ja uz si to z ty debaty nepamatuju.

XCHAOS: No a? Stejne tai budu v prdeli kdyz budu delit nulou, pristupovat na neinicializovanou pamet nebo zapisovat do RO souboru. No a? To ze existuji jine, nesouvisejici druhy chyb znamena, ze rozbitost kontextu je nejak v poradku?

Problem tvych kontextu je v tom, ze je vydavas za zpusob reseni problemu s alokaci pameti pres malloc v C. Jenomze (a) nejsou kompletni nahradou, v rade situaci _porad_ musim pouzivat malloc a _porad_ bojovat s jeho problemy a zaroven (b) prinasi celou radu omezeni, ktera jen komplikuji praci a zpusobuji dalsi problem. To proste je rozbity a spatny design.

REDGUY: pokud budeš používat return zprostředka funkce, která na konci něco de-incializuje, tak jsi v prdeli úplně stejně, jako když takhle použiješ můj hypotetický forget { }.

Manifesto for Software Craftsmanship
http://manifesto.softwarecraftsmanship.org/

XCHAOS: V IT branzi veci kde je navod counterintivni pomerne rychle koncej v propadlisti dejin. U kolika toolu a knihoven sis predem prostudoval navod, nez si je zacal pouzivat? (Ja za sebe presne 0)

XCHAOS: LOL!!! "To neni bug, to je feature!" Takhle ted pracuji umelecti kovari, er, chci rict, umelecti programatori? Haha 8) Nicmene, i tahle vymluva je mimo: pokud je rozbity uz zakladni design, tak zadna noticka v manualu "ehm, nepouzivejte return uprostred funkce" te nezachrani.