ISTEVE: no jo no... Pascal :-) jako v Pascalu to bylo tak nějak mlhavé ... a používalo se to hlavně na spojové seznamy... třeba místo předávání odkazů na hodnoty funkci tam byly řešené jakési "vstupní a výstupní" parametry funkce (o kolik elegantnější je v Pythonu jednoduše možnost aby funkce vrátila více hodnot (stub) - a aby nalevo od příkazu přiřazení byl prostě stub s názvy referencí ! popravdě - je to právě elegance Pythonu, kvůli které se jakéhokoliv zabředání do C++ dost štítím...)

víceméně - já se snažím obejít celou záležitost se spojovými seznamy tím, že na ně bude poskytnutý nějaký framework. dnešní vyšší jazyky toto obvykle obchází, a tváří se, že si kontejnerové typy pořeší samy: Python i PHP přichází s dynamicky nafukovacími klasickými i asociativními polemi, a tváří se, že je implementují dostatečně dobře. Tedy: od žádného Python/PHP codera se v podstatě nečeká, že bude sám řešit nějaké dynamické spojové seznamy, jako se to očekávalo od programátorů v Pascalu.

můj přístup je kompromisní: chci lidem dodat hotová makra pro manipulaci s několika různými základními kontejnery, včetně spojového seznamu. v kombinaci s immutable stringy po vzoru Pythonu.

Python nemodifikovatelností stringu před "prostým uživatelem" tak trochu maskuje, že "všechno je je jen reference" - prostý uživatel na to překvapeně narazí až ve chvíli, kdy udělá referenci na kontejnerový typ, a zjistí, že se odkazuje pořád na tu stejnou kopii v paměti - ale po zralé úvaze, kdy mi to nejdřív dost zvedlo ze židle, se nyní domnívám, že právě toto je ten správný "lék", který by mohl učinit C přístupnější "masám" - víceméně: C s immutable stringy a s několika rozumnými makry na manageování předdefinovaných kontejnerových typů zabíjí více much několika ranami: jednou takovou mouchou je práce s utf-8 stringy (v takovém případě zapomeňte na indexování stringu integerem!), jinou mouchou je právě pointerová gymnastika, kterou je možné "decentně zakrýt".

víceméně - můj dialekt by mohl lidi dovést k tomu, aby používali C, aniž by mu rozumněli, což z něj právě dělá "kreolštinu" mezi programovacími jazyky. je to taková "turistická verze" Céčka :-) bude dobrá k tomu, abyste si na baru mohli objednat panáka a tak :-)

XCHAOS: Pockej, takze predpoklad je ze nekdo bude psat dobrej optimalizovanej Cckovej kod, a nebude vedet jak vypada CPU uvnitr? Ani na urovni "veci jsou na adrese" a proc se ma predavat odkazem a ne hodnotou? So ti myslim ze zadny mnozstvi abstrakce nezachrani, pokud tam vyslovene nebude compiler kterej dela "aha, tady chtel predavat odkazem, akorat o tom nevi, tak to udelam za nej".

Ad vyjimky v C++, chovaj se povetsinou hnusne, dost dojizdej na law of leaky abstraction a spousta lidi co znam ma vyjimky (a RTTI) vypnuty, protoze to zere vykon a neni spis to mate nez aby to pomahalo. (Premejslim co krom typeid na parenta a dynamic_cast vlastne umre na zakazany RTTI, nic dalsiho mne nenapada)

ISTEVE: technický dotaz - on vlastně může signál přijít UVNITŘ volání nějaké funkce z userspace knihovny, co ? no ty jo...

jinak v Pythonu se mi tedy stisknutí Ctrl+C interpretuje jako chyba ? potom ovšem už chápu, proč guruové kritizují používání obecného, nespecifického except ! to totiž může vést k ještě divnějším koncům, než by člověk čekal...

popravdě: o tom, jak se chovají vyjímky v C++ až tak moc nevím, a o Pythonu akorát chápu, že jsem ty vyjímky používal spíše špatně.

ale co s tím ? jaké chování by tedy očekával C programátor, u konstrukce try { } ? tedy, jaké chování by asi C programátor očekával u neodchycené vyjímky, aby to nebylo "proti synergii jazyka" ? (čisté C má ve zvyku chyby samo o sobě ignorovat - nicméně já bych měl tendenci nespecifickou vykímku aspoň zalogovat... zalogovat každé POSIX errno, resp. každý POSIX strerror, který nastane "pod kapotou" frameworku - v "čistém" C kódu by byla tendence tyto chyby ignorovat - zatímco já bych měl tendenci neodchycené vyjímky na konci programu vypsat (nebo je nechat programátora odchytávat z aběhu a logovat)

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.