XCHAOS: "žádný jiný jazyk nepřišel s * a & gymnastikou, například" [citation needed]

...sice to neni konkretne hvezdicka a ampersand, nicmene treba Pascal: http://www.hkbu.edu.hk/~bba_ism/ISM2110/pas065.htm

DAVIDOWITCH: ale ok, teď kromě provokativní odpovědi ještě vážná:

tedy - v C je skutečně pár věcí, které mě pro začátečníka přijdou neintuitivní. žádný jiný jazyk nepřišel s * a & gymnastikou, například: já se před setkáním s C letmo setkal se Z-80 assemblerem, takže jsem okrajově chápal, o čem je řeč: Z-80 mělo jak instrukce pro práci s obsahem registrů, tak instrukce pro práci s pamětí na adrese uložené v registru. z tohoto úhlu pohledu C tak nějak od začátku dávalo smysl - což třeba z úhlu pohledu člověka, který začínal co já vím - skriptovacími jazyky, či objektovým programováním ? - by podle mě bylo úplně jinak (i když i mě trvalo dlouho, než jsem pochopil, že hlavní trik C je v tom, že "pod ním" už vlastně nic není, že je to jen "koberec na tvrdé podlaze", a ne kapota pod kterou je nějaký motor)

skutečně - uvažuji o dialektu, které by některé složitější koncepce C umožnil "obejít" - mj. i začátečníkům, pokud budou mít tu odvahu. má snaha má tedy "obfuskační" charakter - protože se víceméně chystám předstírat, že je to jednodušší, než to ve skutečnosti je. (nicméně - toto je přesně v duchu celé tradice osobních počítačů jako takových - ty se od začátku snažily předstírat, že s počítači jako takovými je to daleko jednodušší, než to ve skutečnosti bylo...)

ANT_39: Ah, vida! Jo, vicemene se zvysi uroven abstrakce o jedna (interrupt vector -> signaly -> signal-generated exceptiony), ale smysl to dava -- mam dojem, ze zrovna SIGINT python prevadi na KeyboardException. Problem co zminujes se signalem uprostred longjmp by asi sel resit tim, ze bys signaly na zacatku jumpu blokoval a na konci odblokoval.

XCHAOS: Tak ten hlavni problem s tim neni v tom ze by to bylo rozbitelny, ale v tom ze to nema co se rozbitelnosti synergii se zbytkem jazyka. Vetsina veci se v Ccku rozbiji.. nejak, a to tvoje se rozbiji jinak, coz lidi nebudou cekat a budou se to muset naucit. A pak holt nastava klasicka otazka, what price glory?

ANT_39: přesně tak jsem to měl na mysli: dát lidem možnost odchytit třeba ctrl+c pomocí try { } ... jenže zase bez varování je to relativně neintuitivní.

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.