Bude Cairo součástí ISO C++?

Výbor pro standardizaci jazyka C++ v rámci ISO se zabývá zařazením API pro 2D kreslení do ISO C++. Svým návrhem se jim zamlouvá API Cairo, i když by bylo nutné doplnit obalení pro C++, jelikož Cairo je v čistém C.

3.1.2014 12:55 | Luboš Doležel (Doli) | Zajímavý článek

Komentáře

[gsnak]

Čo na to Petr Kobalíček? :)

[dumblob]

Take by me to zajimalo.

[Sten]

Cairo by bylo super, obzlášť se všemi těmi backendy, které podporuje

[potato]

Backendy jsou právě z hlediska standardizace největší problém. V podstatě cokoli, co můžeš udělat, bude špatně.

[belisarivs]

Sice GNOME 3 moc nemusim, ale to, ze je Cairo tak povedene me prijemne prekvapilo.

[Jardík]

Cairo zas tak povedené není. Renderer v Qt je např. rychlejší, obzvláště znatelné u WebKitu, pokud porovnám rychlost renderování qupzilly a třeba midory či epiphany, tak qupzilla renderuje hodně rychle, např. tady na ábíčku, když dám diskusi a přejíždím myší nad odkazy, při renderování :hover efektu gtkwebkit znatelně zaostává za kurzorem myši, qtwebkit ne. Obzvláště znatelné, pokud procesor tiká na snížené frekvenci.

[chrono]

Prehliadač Midori nainštalovaný momentálne nemám, ale napr. v Liferea rozdiel medzi GtkWebKit a QtWebKit v rendrovaní hover efektu ani pri spomalenom CPU nevidím.

[sid]

Povedal by som, ze ide o navrh api a nie konkretnu implementaciu backendu.

[Jardík]

Ze standardní C++ knihovny se pomalu stává blob nepoužitelných věcí. V c++11 přidali spoustu nedomyšlených věcí, co nejdou do ničeho pořádně integrovat a teď chcou přidat cairo? A tím nám utvoří závislost standardní knihovny na glib, xkách a jánevímčeho? Rovnou můžou přidat nějakou pořádnou gui knihovnu, dnešní jsou všechny víceméně nepoužitelné s kýblem zbytečných závislostí. A taky by mohli přidat nějakou použitelnou io knihovnu, nejlépe s podporou asynchroního io. Aktuální streamy jsou strašně špatně navržená pomalá věc a tak každej toolkit, každá knihovna, musí vynalézat kolo a vytvářet si vlastní. Taky by se hodil nějaký immutable string a nový 'immutable' k 'const'. Protože to, že dostanete const referenci vám nezaručí to, že se hodnota nezmění, jen to, že jí nemůžete změnit vy. Jednoho času jsem experimentoval s D, to je dnes ale taky strašně přeplácané, nedomyšlené věci, dodnes neumí weak-reference, což je s GC snad nutnost, bez které se v každém rozsáhlejším projektu nedá obejít, standardní knihovna nedomyšlená, 'array slices' nedomyšlený (aneb pokud utvoříte pole s miliónem prvků a utvoříte slice s deseti, tak celý pole bude žít, dokud žije vaše slice, obzvláště špatné to je, pokud je to pole objektů, kdy by prakticky mohl GC sesbírat všechny objekty kromě těch 10, bohužel si to nemůže dovolit). GC v D je pomalý, není generační, ...

[řOUPř]

+1

Klášter z tebe bude mít radost, takový odborník

[----]

souhlas...

třeba bude Rust lepší aspoň zatím teda žádnými z těchto neduhů netrpí...

[Karel]

Kecy, nechtějí přidat Cairo, ale jeho API... to je dost rozdíl.

[kralyk z abclinuxu]

Kecy, nechtějí přidat Cairo, ale jeho API... to je dost rozdíl.

To sice jo, ale je otázka, jak by se k tomu pak případně postavily implementace. Je dost možný, že by prostě akorát přidaly cairo.

[Sten]

Zpočátku nejspíš ano. Ale jestli to bude standardní součást ISO C++, asi se brzy dočkáme i nativních implementací třeba pro Qt nebo Win32.

[kralyk z abclinuxu]

No mně nevadí to cairo jako takový (ani ho moc neznám), jako spíš to, že jde o externí knihovnu. Jak se vyřeší závislost? Doufám, že se nechystají mít GUI knihovnu (ať už kteroukoli) napevno jako závislost libstdc++.

[Sten]

Ne, součástí ISO C++ bude pouze API. Jeho konkrétní implementace bude ponechaná na implementátorech stejně jako u zbytku STL.

[kralyk z abclinuxu]

Jasný, to jo, ale myslel jsem to jinak: Pokud bude tohle API v C++ standardu a pokud ho bude chtít gcc implementovat, jak to udělat, aby GUI knihovna nebyla pevnou závislostí celé standardní knihovny? V zásadě by to asi znamenalo rozdělit standardní C++ knihovnu do více .so a v důsledku v distribucích i do více balíčků, nebo ne?

[Sten]

ISO C++ tohle neřeší, ale jde to řešit třeba pomocí dynamického načtení externí knihovny v nějakém konstruktoru

[Miloslav Ponkrác]

Mám dojem, že co se týká C++11, že se spíše drželi hodně u země. Čekal jsem větší revoluci a rozsáhlejší knihovnu.

Na rozdíl od Jardíka si myslím, že C++11 knihovna nepřidala špatné věci. Byť toto je věcí subjektivního názoru.

Navíc si zřejmě pletete účel standardních knihoven jazyka. Standardní knihovna jazyka navíc musí být striktně portabilní ve svém API, což je důvodem, proč je sem tam (nejen v C++) nemastná neslaná v některých případech. Držení se u země je na místě, protože co je součástí jazyka, musí jazyk podporovat na věky věků. Je lépe se držet pozadu, než zařadit nedomyšlené věci.

To, že neumíte používat featury jazyka (jakéhokoli jazyka) k tomu, abyste docílil co chcete – třeba v případě C++ klíčového slova const – je spíše vinou Vaší nedostatečné schopnosti, než chyba jazyka (jakéhokoli).

Osobně bych si přál, aby v C++ standardní knihovně žádné grafické API nikdy nebylo. Nemyslím si, že toto by měly klasické jazyky řešit v rámci jazyka.

Co se týká jazyka D, před lety jsem se s ním poprvé seznámil – a pochopil jsem, že toto není to, v čem bych chtěl programovat. Na druhé straně bych některé věci z D rád viděl v C++.

Pragmaticky si myslím, že C+11 je poslední norma C++, která je pro mě významná. Možná, že ani do mé smrti nebude možné ještě ignorovat kompilátory umějící jenom C++89/C++03 normu. A že skutečné 100% rozšíření C++11 na všech platformách bude až po mé smrti. Tudíž nějaké další normy, jako je zprznění C++ stadardní library nějakým grafickým API už se mě netýká ani v nejmenším.

[:::]

Pragmaticky si myslím, že C+11 je poslední norma C++, která je pro mě významná.

C++14 pridava vicemene drobnosti (ktery ale usnadni psani), a podpora je myslim skoro stejna jako C++11

[Miloslav Ponkrác]

Prakticky ovšem nelze u kompilátorů počítat ani s plnou podporou C++11, a to ještě minimálně 10 let.

Ostatně i gcc, která se snaží to mít první, stále deklaruje, že jeho podpora C++11 je pouze experimentální, často založená na dřívějších draftech a nikoli na skutečně schválené normě C++11.

Jinak řečeno, zatím stále je, a ještě velmi velmi dlouho bude jediná jistota na kompilátorech stará norma C++89/C++03.

[kralyk z abclinuxu]

Afaik Clang byl první. Jak Clang tak GCC mají podporu C++11 takřka kompletní. Afaik není v praxi problém s tou experimentálností, nebo jo? Co máme dál, ICC nemá podporu kompletní, ale imhovšechny důležitý věci má.

No a co se týče MSVC, ten z těch důležitých fíčur nemá constexpr a unicode literals, co vím, ale jinak snad ostatní důležitý věci taky má. V každým případě bych se neomezoval nedostatky MSVC. Přinejhorším máme feature-test macros.

[Miloslav Ponkrác]

Upřímně řečeno, doby, kdy mě bavilo dělat betatestera kompilátoru jsou už dávno pryč a bohatě jsem si to vynahradil před cca 20 lety na borlandských kompilátorech.

Já nikomu nebráním stavět programy na nestabilních featurách.

Chápu, že je dnes módní, když programátor se nemůže betonově spolehnout ani na kompilátor/interpretr. Natolik módní, že například Python, Perl, Ruby se rozhodli to dotáhnout o level výše, a měnit dokonce i základní syntaxi jazyka. Pro mě to by signál, že Python, Perl, Ruby a další nejsou seriózními jazyky a co nejrychleji jsem je opustil.

Jsou některé věci, kde požaduji naprostou stabilitu, nikoli „takřka kompletní“ a podobné věci. Například u kompilátorů, nebo správců verzí mám velmi vysoké nároky. Stabilita a odladěnost je pro mě prioritou číslo jedna. A jsem ochoten se za to uskromnit.

Po zkušenostech s mnoha správci verzí, včetně subversionu, monotone, bazaaru, monotone, mercurialu a gitu jsem se rozhodl, že všechny mají tak nízký standard toho co poskytují – ať už z hlediska možností, vlastností, tak někdy (zejména u gitu) z hlediska prasácké implementace, že jsem si napsal pro své potřeby vlastní systém správce verzí, a jsem konečně plně spokojen.

To ovšem těžko udělám u kompilátoru.

Navzdory nadšení, implementace C++11 není u žádného kompilátoru odladěná. A bude ještě roky trvat, než bude možné tvrdit, že je to použitelné na 100 %.

V době vydání normy C++89 trvalo mnoho let, než se kompilátory přizpůsobily, než našly optimální reprezentace vnitřních struktur, aby featury byly implementované efektivně. Stejně tak to bude s normou C++11.

Já nepíši, že C++11 je špatná, jenom to, že je třeba tomu pár roků dát čas, než bude možné se na kompilátory spolehnout. Zatím ten čas nepřišel.

[sid]

To by som chcel to vase genialne riesenie vydiet. Jednu vec vie lepsie a dalsich 1000 vobec. Ved sa nim pochvalte podla mna kazdy rad prejde na nieco stabilne, super vlastnosti atd. Alebo je to nieco podobne ako cesky hlodac ci ako sa ta blbost volala?

[sid]

Vidiet samozrejme... Zda sa, ze aj moja gramatika je nejaka nestabilna, ale tak za 10 rokov tu normu slovenskeho jazyka implementujem spravne

[Miloslav Ponkrác]

„To by som chcel to vase genialne riesenie vydiet. Jednu vec vie lepsie a dalsich 1000 vobec.“

Dnešní vcs (version control system) toho moc neumějí. Tudíž není žádný problém je překonat. Ostatně je to vidět i z toho, že Linus něco napytlíkoval za 14 dní a byl další vcs na světě.

A tudíž není ani žádný velký problém překonat ani git, ani většinu dalších.

Já jsem měsíc času trávil jen tím, že jsem navrhoval grafy, stavy, a psal jsem analýzu. Nenapsal jsem ani čárku kódu, jen jsem analyzoval včetně krajních stavů.

Teprve až poté jsem vytvořil repository, a to jako databázi v mysql.

A nakonec jsem psal obslužné programy.

Díky pečlivé analýze to bylo snadné, a není nic, co by chybělo.

Pochopil jsem, že jediný rozdíl mezi distrubuovaným vcs a centralizovaným je přítomnost či nepřítomnost synchronizace dvou repository mezi sebou. Takže s touto funkcí se z centralizovaného stane decentralizovaný.

Nemám problém divoce forkovat ani mergovat, jako to umí monotone, nebo v menší míře ne tak dobře git. Nemám problém s přejmenováváním souborů či adresářů jako má problém občas subversion. Soubory se stejným obsahem (byť z různých verzí nebo s jinými jmény) jsou ukládány v repository jen jednou, aniž bych se o to musel prosit jako třeba halasně vytrubuje subversion.

Jednoduše jsem poslední 3 roky hledal vcs, který budu používat a pokaždé jsem se musel strašně nutit. Nakonec jsem pochopil, že bude lepší, když si napíšu svůj, pořádný, prakticky zaměřený, který budu chtít používat.

Po téměř 30 letech zkušeností už to snad není takový problém.

---

Vystrčit něco ven a pochlubit se znamená napsat manuál a dokumentaci a trochu to uhladit. Napsat nějaký instalační skript, atd. Plus vytvořit web a propagovat to.

Vyzkoušel jsem si to na Complex Web Serveru a dalších projektech.

[sid]

To je naozaj cool riesenie mat backend mysql. Uz sa ani moc necudujem, ze va nic nevyhovuje. Inac nespochybnujem, ze vam to moze vyhovovat som si ale naprosto isty, ze pri inom workflow aky pouzivate by sa ukazali aj slabiny.

[Miloslav Ponkrác]

Co je špatného na mysql jako repository? Nehledě na to, že úložiště jde relativně snadno změnit.

Jedna z věcí, kterou jsem pochopil je, že mnoho vcs bylo zničeno snahou něco montovat na soubory. Třeba jako git se snahou Linuse uvažovat ve extfs.

Monotone má za sebou sqlite.

Ovšem druh repository nebylo to, co mi nevyhovovalo.

[sid]

Medzi sqlite a mysql je sakra rozdiel. Ale ked si chcete na vrabca zobrat kanon je to nakoniec vasa vec. Chcel by som kazdopadne vidiet ale napr vykon vaseho riesenia na linuxovom kernele napr. Mozno by ste prisli na to, ze backend v podobe mysql asi nebude to prave.

[kralyk z abclinuxu]

Ostatně je to vidět i z toho, že Linus něco napytlíkoval za 14 dní a byl další vcs na světě.

Git rozhodně nebyl na světě za 14 dní. To byla jen nějaká úplně prvotní verze, navíc iirc to byly jen skripty.

[dumblob]

Je k dispozici nekde zdrojak k vasemu VCS? Ve zdejsi komunite byva dobrym zvykem po kratkem vnadicim uvodu ukazat kod. Na vasich strankach se mi to nepodarilo nalezt (ani wget -r -l 20 -k ponkrac.net; grep -irE '(vcs|version|control|system)' . nedava zadne relevantni vysledky).

[Miloslav Ponkrác]

„Je k dispozici nekde zdrojak k vasemu VCS?“

Není. A dokonce si myslím, že zdroják není podstatný.

Podstatný je celý způsob uložení dat, způsob řešení operací nad repository a operace s grafem. To je to, co dělá vcs takovou či onakou.

Vcs jsem dokončil o svátcích, a po novém roce do něho naimportoval své projekty.

---

Na web dávám projekty se značným zpožděním. Jak už jsem psal, upravit věci pro obecné použití není jednoduché. Je třeba napsat minimálně manuál. Udělat z toho obecný balíček se vším všudy.

Už několikrát jsem se vsadil, že překonám existující.

Jednou jsem se vsadil, že napíši knihu pro začátečníky v PHP, protože žádná dobrá v češtině neexistuje (a vynikající kniha pana Koska už je poněkud zastaralá). Napsal jsem (http://knihy.cpress.cz/php-a-mysql-bez-predchozich-znalosti.html).

Pak jsem se jednou vsadil, že udělám WAMP server, který bude směšně jednoduchý na instalaci a laik ho nainstaluje do minuty. A napsal jsem (http://ponkrac.net/complex-web-server/cs).

Kvalita většiny věcí je taková, že je nasazena velmi nízká laťka. A málokde je laťka tak nízko, jako je v systémech správy verzí. Před započetím rozhodnutí, že si raději udělám svůj vlastní jsem projel vše co se dalo sehnat. Můj soukromý názor je, že principálně je to všechno velmi nízká kvalita s výjimkou monotone. Monotone je velmi inspirativní, ale spíše teoretický, tedy spíše jako ideové východisko.

Chcete-li se bavit, máte velké pole software s nízkou kvalitou.

Nicméně původně jsme chtěl sdělit, že kompilátor jazyka a jazyk a správce verzí jsou věci, kde čekám vysokou spolehlivost.

Kompilátor je dílo, které si těžko napíši sám, protože je to časově náročné. Na druhé straně kvalitní kompilátory existují. Ovšem správce verzí si snadno napíšete sami. Tak jako se naštval Linus, že všechny vcs za nic nestojí. Podle mého za mnoho nestojí ani Linusův výsledek, především po stránce implementační, a navíc je to šito na kernel a unix a extfs.

[dumblob]

Není. A dokonce si myslím, že zdroják není podstatný.

Vzhledem k tomu, ze VCS neni na divani a teoretizovani, nybrz na pouzivani, nedava smysl se tim zabyvat dokud obe strany (tedy vy a my ostatni) nebudou mit moznost ziskat stejnou znalostni bazi o teto problematice.

[sid]

inac to mate nejake popletene. Vyvoj git zacal ako nasledok problemov s BitKeeper-om. Ohanat sa dokumentaciou je naozaj smiesne. Ak je vas projekt tak dobry ako tvrdite tak urcite sa nejde niekto kto tu dokumentaciu urobi (cez wiki napr.). Ale skor to vidim na to, ze mate nejaky nastrel ktory sice funguje vam ale kopec veci je tam nedorobenych, neiplementovanych atd. Nieco na sposob prototypu ktore sa nakodi za mesiac. A v momente ked to zacnete rozsirovat tak pride chvila trpkej pravdy, ze predsa len vyvojari ostatnych dvcs nie su az taky luzri ako to naznacujete.

[mich]

Ohanat sa dokumentaciou je naozaj smiesne. Ak je vas projekt tak dobry ako tvrdite tak urcite sa nejde niekto kto tu dokumentaciu urobi (cez wiki napr.).

Nechci nijak obhajovat systém, který jsem nikdy neviděl, ale pokud sám autor nenapíše ani čárku dokumentace, tak ten systém asi těžko někdo začne používat (obecně). Ten magický uživatel, co by měl napsat tu wiki stránku by měl docela problém pochopit k čemu ten systém je a jak by ho měl používat. Dokumentace by se mu pak psala docela blbě.

Ani bych neřekl, že se Miloslav Ponkrác dokumentací ohání. Prostě jen zmínil co by rád udělal než nějakou svou práci zvěřejní.

[Karel]

Vy jste ale komediant . Na jednu stranu tu dramaticky prohlašujete, jak potřebujete 100% stabilní řešení a nechcete dělat betatestera projektům a o pár příspěvků dále tu napíšete, jak jste si přes svátky udělal verzovací systém a okamžitě na něj převedl svoje projekty. Dobrej fór .

[...]

mozna se tim da nakonec vysvetlit i ta absence zdrojovych kodu.

[Sten]

Určitě jste si sám divoce forkoval a mergoval víc, než dělá komunita kolem Linuxu nebo Androidu, že můžete prohlásit, že to máte lepší než git

Je taky zajímavý, že do srovnání vezmete vždy jeden verzovací systém a vlastnost, kterou on zrovna neumí, ale ti ostatní ano. Třeba git nemá problémy s přejmenováním souborů (navíc jej umí i sám detekovat) a deduplikaci umí, a to nejen u obsahu souborů, ale i celých adresářových stromů.

Zásadní úraz všech verzovacích systémů není merge bez konfliktů, ale merge bez false possitives. Ze zkušenosti ani git v tom není dokonalý, ale nevěřím, že za člověkoměsíc napíšete a otestujete podobně spolehlivý systém. Taky by mě zajímalo, jak dobře mergujete cherry-picky (umí je vůbec váš verzovací systém?), protože to je pro automatický merge velký problém.

Autoři gitu mají dohromady přes tisíc let zkušeností

[Martin Mareš]

Teprve až poté jsem vytvořil repository, a to jako databázi v mysql.

Pro zajímavost: jak dlouho trvá porovnání dvou vzdálených verzí na projektu velikosti linuxového jádra?

Vystrčit něco ven a pochlubit se znamená napsat manuál a dokumentaci a trochu to uhladit. Napsat nějaký instalační skript, atd. Plus vytvořit web a propagovat to.

Úplně by stačilo stručně popsat formát repozitáře a logiku operací, pokud jsou tak převratné.

[Jardík]

clang má do verze 3.4 problémy s destrukcí std::initializer_list. Někde na stackoverflow se o tom píše.

[Bedňa]

Ale však premakaný GC má U++, ale to sa tu už trápne opakujem. GC sa nad C++ nedá postaviť, pointrová matematika a past vedle pasti. Neviem ako je to s ostatnými vecami čo si tu spomínal, páč práca a CNCfrézka mi zožerie všetok čas, teraz akurát tak naklepem pár riadkov v PHP, JS,

[Miloslav Ponkrác]

U++ je prasečina nad prasečinu. Styděl bych se takto psát a ještě to veřejně ukazovat.

GC se dá samozřejmě postavit nad čímkoli, co splňuje určitá omezující kritéria. Pokud si v C++ postavíte skupinu hodnot s určitými malými omezeními, pak postavíte i GC zcela bez problémů.

Pointerová aritmetika není zásadní problém ani překážka pro GC.

Na druhé straně GC není všelék a má i svá negativa. Proto není vhodný jako univerzální řešení. Jednak takové GC náhodně zastavuje běh procesu a threadů, takže tam, kde je třeba rychlá odezva to není pravé ořechové. A druhak, aby GC mělo rozumný výkon, často zkonzumuje násobek paměti oproti situaci bez GC.

Kromě toho GC neřeší uvolňování zdrojů, ale pouze paměti, takže problém často zůstává na programátorovi. Viz různé pokusy typu finalize(), dispose(), a jiné v řadě jazyků.

Jinak řečeno, vždy je něco za něco. C++ jako univerzální jazyk si nemůže dovolit svázat se omezeními GC ve všech aspektech.

Na druhé straně bez GC můžete řadu alokací vyřešit šikovněji. V různých situacích můžete hromadně alokovat/dealokovat jedním příkazem. Můžete vyřešit alokaci pro mnoho threadů v multithreadovém programu lépe a na míru, atd.

Kromě toho si už nepamatuji, že bych kdy za posledních 10 let použil v C++ jakoukoli alokoaci/dealokaci typu malloc(), free(), new, delete, protože C++ má daleko šikovnější prostředky pro správu životnosti objektů. Pokud zapomenete C a budete v C++ programovat C++ stylem, nemusíte ruční alokaci a dealokaci řešit vůbec. Napovím: RAII koncept, std::shared_ptr, std::auto_ptr a mnohé další.

Jednoduše jsem zjistil, že v C++ GC vůbec není třeba. Navíc výše zmíněné koncepty řeší nejenom automatické uvolnění paměti, ale také zabraných zdrojů (otevřených souborů, grafických objektů, čehokoli, …), což GC obvykle neřeší a programátor to musí řešit obvykle ručně, nechce-li se divit.

Vůbec mám problém, že řada programátorů přemýšlí jako ženské. „Já chci a chci a chci GC!“ nebo „Já chci a chci a chci immutable objekty!“ Aniž by pochopili, že daný programovací jazyk jim nabízí často dokonalejší a propracovanější koncepty šité na míru tomu, pro co je jazyk určen. Skutečně dobrých programátorů je málo, zato je mnoho žensky přemýšlejících programátorů, které svou neshcopnost hází tu na jazyk, tu na operační systém, tu na IDE.

[kralyk z abclinuxu]

Ale však premakaný GC má U++, ale to sa tu už trápne opakujem.

Tak to budu muset trapně zopakovat, že U++ žádný GC nemá

Teda pokud stack-based memory managementu neříkáš GC...

[Jardík]

Dneska jsem zjistil, že vlastně ani ani neumím C++. Dodnes jsem žil v přesvědčení, že když někde vyhodím výjimku, dojte ke "stack unwindu" a zavolají se mi hezky destruktory a v nich si uvolním prostředky, třeba sdílenou paměť atp. Dnes jsem zjistil, že to platí jen tehdy, pokud je ta výjimka toho typu někde zachycována, pokud ne, vaše destruktory se nezavolají a jsem v prdeli, program chcípne na nezachycenou výjimku a máte neuvolněnou sdílenou paměť (třeba). No a pak jsem přišel na to, že tu věc stejně píšu zbytečně a smazal jsem to, jako vždy.

[frr]

Čtu správně mezi řádky smajlíka, mžouracíjího jedním okem?

Když program umře na nezachycenou výjimku, uklidí po něm znuděný operační systém = shrábne všechny paměťové stránky zabrané daným procesem lopatou na kompost. Vlastně je operačnímu systému úplně jedno, v čem jste ten program napsal a na co umřel - OS neví nic o C++, destruktorech a výjimkách. Prostě to hrubou silou vyčistí. Vlastně jenom sfoukne bublinu chráněného paměťového prostoru daného procesu a uvolněné stránky převede jeho VMM z kolonky "A" do kolonky "B". Život jde dál jakoby nic, přestože někteří máme pocit, že kdesi umřelo štěňátko... Takto bezcitně se chovají slušné operační systémy. Odhaduji, že třeba v DOSu by to případně mohlo skončit důstojným hrobečkem Maximum executable program size = 50 kB apod.

[Ivan]

OS ale neuvolni shared ram(IPC shm) ani neflushne buffery.

[frr]

Díky za tuto podrobnost. Osobně jsem viděl potenciální riziko spíš ve specifickém hardwaru, se kterým se program může exkluzivně bavit (a nechat ho v "neukončeném" stavu).

[Sten]

Pokud program spadne, tak neflushnutí bufferů vás zrovna netrápí.

SHM objekty můžete řešit pomocí std::set_terminate. Ono to C++ není tak hloupé, jak vypadá

[...]

je to o prioritach. kdyz vas nezajima konzistence uzivatelskych dat, tak ale uzivatele asi nebude zajimat vase padajici aplikace.

jinak je to samozrejme kardinalni kravina, protoze padat se da na ruznych mistech z ruznych pricin a pak kdyz se padne s fflush() tak i laik na prvni pohled bez debuggeru zjisti co se stihlo udelat a co uz ne.

[kralyk z abclinuxu]

Pokud ti z nějakého neznámého důvodu padá aplikace, tak stejně konzistenci uživatelských dat spolehlivě nezajistíš. Takže v první řadě je potřeba odstranit to padání.

Jinak tenhle útočnej tón fakt nechápu, předřečník ti zavraždil babičku nebo co?

[Sten]

Pokud aplikace spadne, tak ta data moc konzistentní nebudou tak jako tak, ne? Pokud si vytváříte někde bokem zálohy á la LibreOffice, tak ty po vytvoření samozřejmě flushnete. Ale vy si nejspíš pletete padání a ukončení s chybou, což jsou dvě různé věci a ve druhém případě se samozřejmě flush bufferů udělá, protože to je synchronizované.

[:::]

Dnes jsem zjistil, že to platí jen tehdy, pokud je ta výjimka toho typu někde zachycována, pokud ne, vaše destruktory se nezavolají

Tak jsem to zkousel a v gcc to tak je, v clangu ne. To je teda utra-prasarna co dela gcc... A navic me prijde ze implementovat to taklhe musi byt slozitejsi nez je volat vzdicky...

[little.owl]

To je teda utra-prasarna co dela gcc.

To co dela clang neni o nic lepsi, tohle v podstate nejde rozumne v C++ resit. Pokud mate neosetrenou vyjimku, nemate jistotu ze muzete vubec destruktory bezpecne zavolat, navic to neresi multithreaded programy, kde muzou vzniknout kaskady vyjimek ci casovani unrollingu, ktere muze byt zpozdene.

to taklhe musi byt slozitejsi nez je volat vzdicky...

Je to spise naopak.

[:::]

To co dela clang neni o nic lepsi

clang destruktory vola, tak jak "neni o nic lepsi"?

tohle v podstate nejde rozumne v C++ resit

rozumny reseni: zavolam destruktory, ukoncim program

to taklhe musi byt slozitejsi nez je volat vzdicky...

Je to spise naopak.

funguje to takhle:

1. dojde k vyjimce
2. v tabulce se najde adresa obsluzneho kodu pro aktualni hodnotu PC
3. kod se spusti
4. najde se adresa odkud probehlo volani funkce
5. goto 2

delat nekou vyjimku v bode 3 povazujes za jednoduzsi?

[little.owl]

clang destruktory vola, tak jak "neni o nic lepsi"?

Vam stale nedochazi, ze je to hovadina, ze?

Z hlediska designu mate dva typy chyb: recoverable a irrecoverable. Vyjimka, ktera ma exception handler je povazovana za recoverable a pak ma smysl provest unwinding stacku a destrukci vsech objektu, jedna se o situaci do znacne miry stale pod kontrolu. Pokud tam ale neni zadny handler, fakticky nevime co to je, je volani destruktoru kravina, nebot posledni vec kterou chci je aby se mi to nekde kouslo v nejakem destruktoru; neexistuje zadna garance ze volani destruktoru je u nezname chyby bezpecne.

V takovem pripade je pristup gcc jednoznace lepsi: vyjimka bez handleru -> okamzity jump s minimalnim zpozdenim do std::terminate(); to je totiz jedine co muzete bezpecne udelat. Defaultni handler u terminate je std:abort(), ktery neprovadi zadny cleaning a volani destruktoru, a pokud se vam to nelibi, muzete implementovat svuj handler a nastavit pres std::set_terminate(), nebo v nejhorsim nastavit std:exit().

Nastesti tohle doslo i tvurcum standardu C++ a umoznili takove chovani.

[:::]

uz tady v diskuzi padly priklady kdy je to volani destruktoru uzitecne, mohl bys uvest priklad kdy je to nebezpecne?

Neznam duvody proc je to ve standardu, ale tipoval bych to na "moznost optimalizace". Ale to ze se pri padu programu usetri 0.000001s nepovazuju za dobrou optimalizaci...

[little.owl]

mohl bys uvest priklad kdy je to nebezpecne?

Na hloupu otazku hloupa odpoved: Kdykoliv, kdy to neni jiste bezpecne.

Uvedemujete si vyjimky mohou byt generovany mapovanim HW vyjimek na nekterych platformach?

Staci aby vam selhal zapis do EEPROM, vygnerovalo to vyjimku a mit objekt, ktery v destruktoru ceka na dokonceni zapisu ci destruktor ktery pristupuje k protected resource, ktery neni k dispozici, i kdyby to mel byt reference counter.

ale tipoval bych to na "moznost optimalizace".

Tipujete blbe.

[:::]

Pokud volani destruktoru pri vyjimce muze neco zpusobit tak je v nem chyba a je potreba tu tridu navrhnout jinak, protoze ke stejnymu problemu dojde pokud ta vyjimka je obslouzena, ale az po zavolani destruktoru.

[little.owl]

Pokud volani destruktoru pri vyjimce muze neco zpusobit tak je v nem chyba

Vyjimky se obvykle generuji kdyz dojde k nejake chybe a zpracovani musi limitovat moznost dalsiho selhani.

protoze ke stejnymu problemu dojde pokud ta vyjimka je obslouzena, ale az po zavolani destruktoru.

Nemusi, znamou vyjimku jsem schopen osetrit; znovu: znama vyjimka je recoverable error, neznama irrecoverable error a od toho se vse odviji.

[:::]

Kdyz treba vezmu v uvahu ten tvuj priklad s EEPROM:

#include <iostream>

class EEPROM_error: public std::exception {};

class EEPROM {
public:
        ~EEPROM() {
                std::cout << "causing trouble\n";
        }
};

int main() {
        try {
                EEPROM eeprom;
                // ...
                throw EEPROM_error();
                // ...
        } catch (EEPROM_error &e) {
                std::cout << "recovering\n";
        }
}

vystup bude:

causing trouble
recovering

takze i kdyz vyjimku osetrim, tak ten destruktor me zpusobi problem. A proto je potreba ho opravit.

Kdyz ho opravim tak to ze se zavola pri neosetreni vyjimky me nevadi.

[little.owl]

Tak ted jste me rozesmal. Napsat tenhle stupidni priklad se znamou vyjimkou na zaklade informace, kterou jsem vam poskytl je skutecne komicke.

Stale mam pocit, ze vam nedochazi o co vlastne jde.

Znovu a naposledy.

Pokud vyjimka nema handler, jedna se neznamou irrecoverable chybu a jedine co jde da delat, je to rychle ukoncit, protoze to muze byt cokoliv.

Nema smysl se vubec pokouset neco delat, volat destruktory, cokoliv a doufat ze to neco zachrani, jde to primo proti jedinemu cili - ukonceni programu. Destruktory jsou pripraveny pouze na vyjimky, ktere programator predjimal.

U vetsiny kompilatoru je to tak skutecne implementovano - exception handler se hleda tak, ze se prochazi stack nahoru a vubec nic se nevola dokud handler neni nalezen. Pokud handler neni nalezen, zavola se terminate() a je na programatorovi tam osetrit to, co neudela OS, pripadne treba udelat log ci core dump; zpatky se uz stack kvuli destructorum neprochazi.

Pokud se handler najde, zavolaji se destruktory objektu na stacku, exception handler a jede se dal.

Ohledne EEPROM, byl to jeden z pripadu, se kterym jsem se setkal. Zapis a cteni seriove pameti se delalo ve vlastnim low priority threadu, kteremu ostatni thready posilaly data. Thread vytvoril object transaction, ktery v konstruktoru inicializovala spojeni, pak se poslaly data a v destruktoru cekalo na dokonceni transakce a uvolneni bufferu. Problem byl v tom, ze behem zapisu dochazelo nahodne v zavislosti na datech diky chybe v i2c prenosu k unaligned access, ktery pres souvisejici interrupt handler generoval vyjimku se kterou nikdo nepocital. Pokud by se volal destructor u teto neosetrene vyjimky, vlakno bude zablokovano, nebot EEPROM thread transakci nikdy nedokonci, a system by nahodne krachnul nekde jinde.

Nastesti C++ vyjimky nejsou u standardu, kde zalezi alespon trochu na bezpecnosti povoleny.

[:::]

Tak ted jste me rozesmal. Napsat tenhle stupidni priklad se znamou vyjimkou na zaklade informace, kterou jsem vam poskytl je skutecne komicke.

Ten priklad mel demonstrovat ze pri psani destruktoru musis pocitat ze muze byt zavolany pri jakykoli chybe. Pokud s tim nepocitas tak v nem mas chybu! Protoze pri psani destruktoru nemuzes predvidat jestli dana vyjimka je nekde ve vyssi vrstve znama nebo neznama (osetrena/neosetrena).

Pokud vyjimka nema handler, jedna se neznamou irrecoverable chybu a jedine co jde da delat, je to rychle ukoncit, protoze to muze byt cokoliv.

Porad jsem nedostal priklad ktery by tohle odvazny tvrzeni potvrdil. To s tou EEPROM jsem svym ukazkovym kodem vyvratil.

Neopak tady v diskuzi byly priklady kdy jsou destruktory uzitecny i pri neosetreny vyjimce.

[Radek Miček]

priklad mel demonstrovat ze pri psani destruktoru musis pocitat ze muze byt zavolany pri jakykoli chybe

Jak jsou tedy destruktory v C++ připraveny na situace, kdy došla paměť?

[:::]

myslim ze pokud v nem nic nealokujes tak by nemel byt problem. Problem bude spis jak to zase rozbehnout po zachyceni vyjimky. Tam ti asi stejne nezbyde nic jinyho nez to ukoncit.

[Radek Miček]

myslim ze pokud v nem nic nealokujes tak by nemel byt problem

Pokud něco volám, tak alokuji na zásobníku, ne?

[Jardík]

Imho pokud vám dojde místo na zásobníku, tak prostě dostanete SIGSEGV (tedy alespoň v linuxu), když budete mít štěstí. Když ne, tak přepíšete náhodné věci . Je tam však být nějaký ten "gap", aby jste dostali SIGSEGV, můžete ho však i překročit.

Na Windows dostanete SEH výjimku od kernelu, kterou můžete zachytit. Pak však záleží na tom, jak moc se uvolní stack unwindem.

std::bad_alloc se vyhazuje když selže alokace na heapu a ten objekt už je předvytvořený, nevytváří se při vyhození výjimky. Při unwindu pak může dojít k nějaké té dealokaci, takže se z toho lze i zachránit. Bohužel dnešní systémy vám většinou nevrátí chybu při alokaci, ale vrátí vám pointer a paměť alokují až když k ní přistoupíte. Když se to nepovede, SIGSEGV. V dnešní době nemá smysl kontrolovat návratové hodnoty z malloc(). Mám zkušenost s mmap(), který vrací chybu pouze pokud chcete alokovat hodně paměti a ví, že nemůže být dostupná, a taky vrací chybu, když si ji necháte předem "zfaultovat" a není, tím můžete předejít nečekanému SIGSEGVu, doporučuji použít když víte, že tam budete stejně hned zapisovat, takže čas neztratíte.

[little.owl]

Linux a Windows jsou luxus, u RTOS se treba pouziva MMU ci stacky maji na konci pattern, ktery se kontroluje pri task switch. Pokud tam neni, generuje to exception, jenze v te dobe to mohlo udelat jiz buhvi co a program se musi ukoncit/restartovat.

[Sten]

SIGSEGV dostanete, jen pokud používáte stack alokovaný linkerem nebo pthready a trefíte se do ochranné stránky. Pokud použijete setcontext, tak tam žádná ochranná stránka není.

Pokud není dostupná paměť, kterou jste libovolně namapoval, tak dostanete SIGBUS. Tedy jak kdy. Pokud je to heap na Linuxu, tak ten spustí OOM killer a posílá rovnou SIGKILL.

[Radek Miček]

IMO běhové prostředí by mělo při konstrukci objektu rezervovat prostor pro běh destruktoru.

[:::]

ja myslim ze neni jak protoze dopredu se obecne neda spocitat kolik pameti bude potreba.

Pokud jde o stack tak je to jak rika Jardik. Za behu se nekontroluje jestli je tam dost mista, protoze by to zpomalovalo a to je proti filozofii c++. Kdyz potom dojde ke stack overflow tak se zacne zapisovat do nenamapovany pameti a kernel aplikaci ochotne posle SIGSEGV. Potom myslim ze se ani nepokousi nic spoustet a hned to ukonci.

Urcite to neni idealni reseni, ale je to jeden z kompromisu ktery C i C++ museli udelat.

[kralyk z abclinuxu]

ja myslim ze neni jak protoze dopredu se obecne neda spocitat kolik pameti bude potreba.

Ale kolik bude destruktor potřebovat místa na stacku se určit přece dá ne?

Alokovat něco v destruktoru na heapu je prasárna, to by se nemělo dělat tak jako tak.

[little.owl]

Dobra technika to neni, ale vyloucit se to neda. Navic tam nejde jen o to, co alokuje samotny kod destruktoru, ale i funkce ktere jsou z nej volany a to vam kompilator vetsinou dohromady neda ani u alokace na stacku.

[:::]

ten destruktor muze volat dalsi funkce (pripadne dalsi destruktory), ktere navic muzou byt kompilovane oddelene.

I kdyz by nebyly kompilovane oddelene tak tam muze byt rekurze (nekdo treba nevhodne naprogramuje uvolnovani spojovyho seznamu), atd.

Takze v urcitych pripadech by to slo, ale obecne je to problem.

[Radek Miček]

Takze v urcitych pripadech by to slo, ale obecne je to problem.

Souhlas.

Například to lze udělat tak, že zakážeme dynamickou alokaci paměti, rekurzi, volání virtuálních metod a volání funkcí, jenž nesplňují tyto podmínky.

ten destruktor muze volat dalsi funkce (pripadne dalsi destruktory)

Volání dalších destruktorů by nemělo vadit – před spuštěním konstruktoru zajistím, že budu mít i místo pro volání destruktoru. Tj. držím dostatek místa, abych mohl najednou zavolat destruktory všech objektů, jenž byly zkonstruovány.

[little.owl]

std::bad_alloc se da osetrit, horsi je kdyz vam treba EMIF controller nahlasi HW chybu SDRAM ci pretece stack.

[little.owl]

ze pri psani destruktoru musis pocitat ze muze byt zavolany pri jakykoli chybe. Pokud s tim nepocitas tak v nem mas chybu!

Za prve, nikdy nemuzete pocitat se vsim. Za druhe, vyjimky jsou prave mechanismus pro osetreni nekterych chybovych stavu, at jiz v HW ci SW, pokud by tomu tak nebylo, tak je nepotrebujete - pokud nepatrite k tem silencum, kteri v C++ pouzivaji vyjimky ke control flow. Za treti, jsou vyjimky kde recovery je z principu nemozne.

To s tou EEPROM jsem svym ukazkovym kodem vyvratil.

Co jste tedy svym skolnim prikladem s vyjimkou majici handler vyvratil?

Ted jsem zkousel clang 3.3 a u neosetrenych vyjimek se destruktory take nevolaji, chovani je vicemene identicke s gcc.

[:::]

Za prve, nikdy nemuzete pocitat se vsim.

To jestli je mozne udelat bezchybny program je na jinou diskuzi. Kazdopadne pokud se program zacykli protoze nepocital s nejkou chybou, tak je v nem chyba

Co jste tedy svym skolnim prikladem s vyjimkou majici handler vyvratil?

Vyvratil jsem, ze toto:

Staci aby vam selhal zapis do EEPROM, vygnerovalo to vyjimku a mit objekt, ktery v destruktoru ceka na dokonceni zapisu ci destruktor ktery pristupuje k protected resource, ktery neni k dispozici, i kdyby to mel byt reference counter.

je validni design

[little.owl]

Vyvratil jsem, ze toto:

Staci aby vam selhal zapis do EEPROM, vygnerovalo to vyjimku a mit objekt, ktery v destruktoru ceka na dokonceni zapisu ci destruktor ktery pristupuje k protected resource, ktery neni k dispozici, i kdyby to mel byt reference counter.

je validni design

Ne. Vas priklad je jen komicka ucelova interpretace me citace, vytrzena z kontextu.

Mluvili jsme o destruktorech, ktere nemusi byt v kontextu neosetrenych neznamych vyjimek bezpecne.

V takovem pripade je uklid stacku zbytecnost, ktera naopak muze v okamziku, kdy unwinding jednoho z destruktoru selze, udelat situaci horsi.

Jedna z moznosti, jak zablokovat unwinding destruktoru objektu na stacku, je u vice vlaknovych aplikaci situace, kdy se v desktruktoru ceka na asynchronni IO, treba na ukonceni asynchronniho zapisu do EEPROM, ktery nikdy neprijde, ci cekani na uvolneni chraneneho resource, ktere nikdy nenastane, ale problem muze byt i treba s memory allocatorem/heapem; coz je presne to co jsem chtel rici.

Programator je schopen v praxi zajistit bezpecny unwinding stacku u osetrenych vyjimek (pokud ne, at jde past kozy), ale nikoliv u neznamych neosetrenych, to je duvod proc standard takove chovani pripousti, a proc jak gcc tak, clang implementuje.

[:::]

ok, jeste jednou:

Ty rikas: To ze se konstruktory nespousti je super, protoze u tohodle designu a tyhle neocekavany chyby to zamrzne

Ja rikam: Ten design je celej spatne protoze kdyz se nekde ve vyssi vrstve rozhodnes tu vyjimku zachytit (tak jak jsem to udelal ja v tom kodu), tak se ten konstruktor najednou spusti a zamrzne to

[little.owl]

Ne. Ja jsem jasne rikal, ze u osetrenych vyjimek musi byt unwinding stacku bezpecny a u neosetrenych neznamych vyjimek je to zbytecne a v praxi muze byt riskantni.

[:::]

A ja jsem jasne rikal ze pri psani destruktoru nemas co predpokladat jestli je vyjimka ve vyssi vrstve osetrena nebo ne.

[little.owl]

Jiste by bylo idealni mit destruktory schopne se poprat se vsemy moznymi vyjimkami a vsemi moznymi chybovymi stavy, ale to je jednak v praxi nerealne a jednak nekdy i nemozne, a pak je zvoleny pristup tvurcu standardu a kompilatoru spravny.

[kralyk z abclinuxu]

Ohledne EEPROM, byl to jeden z pripadu, se kterym jsem se setkal. Zapis a cteni seriove pameti se delalo ve vlastnim low priority threadu, kteremu ostatni thready posilaly data. Thread vytvoril object transaction, ktery v konstruktoru inicializovala spojeni, pak se poslaly data a v destruktoru cekalo na dokonceni transakce a uvolneni bufferu. Problem byl v tom, ze behem zapisu dochazelo nahodne v zavislosti na datech diky chybe v i2c prenosu k unaligned access, ktery pres souvisejici interrupt handler generoval vyjimku se kterou nikdo nepocital. Pokud by se volal destructor u teto neosetrene vyjimky, vlakno bude zablokovano, nebot EEPROM thread transakci nikdy nedokonci, a system by nahodne krachnul nekde jinde.

Vidím problém zejména v tom, že se v destruktoru čekalo na dokončení transakce. Destruktor nemá na nic čekat, má uklidit po objektu a vypadnout...

[little.owl]

Vidím problém zejména v tom, že se v destruktoru čekalo na dokončení transakce. Destruktor nemá na nic čekat, má uklidit po objektu a vypadnout...

Souhlas, jenze u velkych projektu s plnem ruznych lidi to neuhlidate. A i u RAII vam to muze jit dohaje, kdyz dealokujete sdilene resources, staci abyste nedostal lock, coz u nestabilniho systemu s kritickou neosetrenou chybou je mozne.

[Sten]

No, pokud kritická chyba způsobí, že se neuvolní zámek, pak je celkem jedno, jestli to zatuhne v destruktoru nebo někde jinde.

[little.owl]

Tam jde hlavne o to, aby to pozastavilo cinnost ASAP, kdyz dojde k nejake neopravitelne chybe, drive nez to udela nejakou paseku. Ono to pak pri takovehle chybe nemusi padnout vubec, a pokud tam neni nejaky watchdog, to muze zustat v nejakem zombifikovanem stavu. Rychly terminate() a std::abort() a je to.

[Sten]

Tohle přesně se dělá u výjimek, které nemají handler, tj. jsou neopravitelné

[little.owl]

Presne, a ted si predstavte ze jsou tu zpatecnici, kteri by stale volali nejake destruktory .

[Sten]

Vidím problém zejména v tom, že destruktor na něco čekal, i když std::uncaught_exception vracelo true. Kdyby víc programátorů vědělo o téhle funkci, programy v C++ by fungovaly výrazně lépe.

[little.owl]

Bohuzel moc ne, viz Sutter zde.

3. Is there any other good use for uncaught_exception? Discuss and draw conclusions.

Unfortunately, I do not know of any good and safe use for std::uncaught_exception. My advice: Don't use it.

Navic v kontextu multithreaded programu je to fakticky "implementation defined" a dela to psi kusy.

[Sten]

Sutter se zde dopouští argumentu šikmé plochy. Je sice špatné za mnoha okolností vyhazovat výjimky z destruktorů, ale to neznamená, že je vždy špatné vyhazovat výjimky z destruktoru (ono to mimochodem dospělo tak daleko, že v C++11 jsou destruktory ve výchozím stavu noexcept). To, že uncaught_exception neříká správně, jestli je bezpečné výjimky vyhazovat, nemá na tuhle logiku moc vliv. Pokud se nepovede flush bufferu a někde výš je další výjimka, je úplně jedno, jestli výjimku o neflushnutí bufferu vyhodím nebo ne — někdo ji stejně bude muset někde výš chytit a zamlčet, jinak dostane terminate. U toho EEPROMu je to podobné, pokud je někde výš výjimka, tak nemá smysl na něj čekat, i kdyby samotný destruktor EEPROMu byl volán ve vnořeném try-catch; ta vnější výjimka stejně celý proces přerušila.

Pozor také na to, o co zde Sutterovi jde: Sutter zde hlavně argumentuje tím, že destruktor nemá dělat nějakou logiku. S tím souhlasím, destruktor by neměl rozhodovat, jestli udělá commit nebo rollback, případně vůbec zakládat nějaké transakce; buď někdo udělá commit explicitně nebo destruktor automaticky provede rollback (když jsem psal transakce, tak to většinou bylo s runtime_exception, že se volající nerozhodl). Jenže třeba u případu selhání flushnutí bufferu je špatný nápad výjimku nevyhodit, pokud uncaught_exception vrátí false, protože program vesele pokračuje dál, i když se vlastně něco důležitého nepovedlo. A dělat flush jen speciální funkcí zase narušuje RAII.

Implementace, které nemají uncaught_exception thread-safe, nemají thread-safe ani vyhazování výjimek.

[little.owl]

Implementace, které nemají uncaught_exception thread-safe, nemají thread-safe ani vyhazování výjimek.

Jak to chcete udelat rozumne thread safe, kdy to vrati true teprve az pote, co to udela kompletni stack unwinding vcetne destrukce vsech objektu?

[little.owl]

Uff, takhle nepsat pozde vecer .... vraci to true dote az to spusti handler vyjimky, std::terminate() ci std::unexpected(). Proste nevim, jak jste dosel k tomu, ze unsafe std::uncaught_exception() znamena unsafe vyhozeni vyjimky. U prveho musite zajistit pocitani objektu vyjimek [per thread], u druheho ulozeni objektu [per thread], standard navic rika, ze vyjimka nemuze propagovat do jineho threadu a v podstate si vynucuje thread safeness. Sutterovu pripominku bych videl jinde - pouzitim std::uncaught_exception() tam vnasite zavislost chovani na skryte [globalni] promenne, coz v kontextu toho, ze se destruktory volaji automaticky i v destruktorech samotnych muze vest k necekanym vysledkum, coz ostatne ukazuje.

Jenže třeba u případu selhání flushnutí bufferu je špatný nápad výjimku nevyhodit, pokud uncaught_exception vrátí false, protože program vesele pokračuje dál, i když se vlastně něco důležitého nepovedlo.

A podle vas je vyhozeni vyjimky jedina cesta jak zmenit beh programu?

A dělat flush jen speciální funkcí zase narušuje RAII.

Za prve RAII neni modla, za druhe flushnuti neni inicializace/deinicializace resource.

U toho EEPROMu je to podobné, pokud je někde výš výjimka, tak nemá smysl na něj čekat, i kdyby samotný destruktor EEPROMu byl volán ve vnořeném try-catch; ta vnější výjimka stejně celý proces přerušila.

Na nic se u selhani nikdy necekalo, jednalo se chybovy stav a tak to slo hned do std::terminate().

[Sten]

Uff, takhle nepsat pozde vecer .... vraci to true dote az to spusti handler vyjimky, std::terminate() ci std::unexpected(). Proste nevim, jak jste dosel k tomu, ze unsafe std::uncaught_exception() znamena unsafe vyhozeni vyjimky. U prveho musite zajistit pocitani objektu vyjimek [per thread], u druheho ulozeni objektu [per thread], standard navic rika, ze vyjimka nemuze propagovat do jineho threadu a v podstate si vynucuje thread safeness.

Reagoval jsem na Navic v kontextu multithreaded programu je to fakticky "implementation defined" a dela to psi kusy. Některé C++ knihovny (vzpomínám si na AIX) mají skutečně thread-unsafe výjimky včetně uncaught_exception. Že je jejich thread-safeness spojená, je jednoduché: uncaught_exception vrací true, pokud existuje nejméně jeden objekt nezachycené výjimky. A ten je buď uložen per thread v TLS, tj. v jiném threadu funguje uncaught_exception správně, nebo globálně, což evidentně není thread-safe ani pro vyhazování výjimek.

A podle vas je vyhozeni vyjimky jedina cesta jak zmenit beh programu?

To by mě zajímalo, jak destruktor může dát programu vědět, že se něco nepovedlo, jinak než výjimkou. Ne, změna globálních stavů á la errno do C++ nepatří.

Za prve RAII neni modla, za druhe flushnuti neni inicializace/deinicializace resource.

Za prvé RAII je základní kámen bezpečné práce s výjimkami (C++ nemá finally) a za druhé je flushnutí bufferu součást deinicializace zdroje, jak ostatně uvidíte třeba v iostream, které volá fclose (The fclose() function flushes the stream pointed to by fp (writing any buffered output data using fflush(3)) and closes the underlying file descriptor).

Na nic se u selhani nikdy necekalo, jednalo se chybovy stav a tak to slo hned do std::terminate().

Pouze v případě, že tu výjimku nikdo neodchytil.

[little.owl]

Reagoval jsem na Navic v kontextu multithreaded programu je to fakticky "implementation defined" a dela to psi kusy.

To neznamena, ze std::unexpected() je thread unsafe. Nevim jak u AIX, ale u nekterych implementaci se skutecne pocital pocet objektu vyjimek globalne a u pre-C++11 je to korektni reseni. To ma pak nevyhodu, ze to vyzaduje thread safeness destruktoru, i kdyz counter vyjimek je atomicky a std::unexpected() thread safe.

Ne, změna globálních stavů á la errno do C++ nepatří.

Jakakoliv implementace std::uncaught_exception() zavadi fakticky globalni stav, navic skryty, implementacne zavisly, tezko pouzitelny bez netransparentnich side efektu. Proti tomu je jasne specifikovana global/thread local promenna lepsi reseni. Tady souhlasim se Sutterem.

(The fclose() function flushes the stream pointed to by fp (writing any buffered output data using fflush(3)) and closes the underlying file descriptor).

Tam je podstatny ze se vraci file descriptor, flushnuti je jen tresnicka na dorte.

Pouze v případě, že tu výjimku nikdo neodchytil.

Jak jsem psal, u zpracovavanych vyjimek se musi zajistil bezpecny unwinding destruktoru, pak by se to muselo predelat.

[Sten]

Nevim jak u AIX, ale u nekterych implementaci se skutecne pocital pocet objektu vyjimek globalne a u pre-C++11 je to korektni reseni

Mě to jako korektní řešení teda nepřijde, buď to thread-safe je nebo není. Udělat něco mezi je strašná prasárna. Ale asi to bude splňovat doslovný text C++03, protože ten thready moc neřešil.

Jakakoliv implementace std::uncaught_exception() zavadi fakticky globalni stav, navic skryty, implementacne zavisly, tezko pouzitelny bez netransparentnich side efektu. Proti tomu je jasne specifikovana global/thread local promenna lepsi reseni. Tady souhlasim se Sutterem.

Ani ne, je zde totiž zásadní rozdíl v zodpovědnosti za ten stav. U std::uncaught_exception se ptáte jen ve chvíli, kdy ten globální stav využijete, a nic se nestane (nepřijdete o žádnou informaci), pokud se nebudete ptát jindy. U globálního chybového stavu se ale musíte ptát pořád, jinak hrozí, že vám něco unikne a následující operace ten stav opět přepíše; proto C má u všech funkcí, které mohou selhat, návratové hodnoty. Jenže to nejde udělat u destruktoru. Někoho napadlo to implementovat tak, že každá metoda, která by ten stav mohla změnit, jej napřed zkontroluje a vyhodí výjimku, pokud tam je uložena chyba. Tam ale nevidím žádný rozdíl mezi tím a vyhozením výjimky rovnou z destruktoru, navíc to zavádí dost zásadní problém jak řešit situaci, kdy ta druhá metoda měnící ten stav je opět destruktor. A co teprve když je to poslední destruktor při ukončení programu? Program skončí úspěšně a přitom se něco nepovedlo. A aby tohle nebylo málo, tak globální proměnné nefungují správně pro statické inicializace, protože pořadí inicializace mezi jednotlivými kompilačními jednotkami není nijak zaručeno (i když u primitivních typů je zaručeno, že jsou při spuštění programu vynulované).

Sutter by s vámi nesouhlasil: „it is always poor design to allow an operation to report the same error in two different ways“. On totiž takovýhle případ vůbec neřeší a tiše ignoruje.

Tam je podstatny ze se vraci file descriptor, flushnuti je jen tresnicka na dorte.

Ano, to je samozřejmě i u destruktoru. Ale když se do té manuálové stránky podíváte, tak uvidíte, že u fclose se chyba flushnutí bufferu neignoruje, ale ta funkce vrátí chybu.

[little.owl]

Mě to jako korektní řešení teda nepřijde, buď to thread-safe je nebo není. Udělat něco mezi je strašná prasárna. Ale asi to bude splňovat doslovný text C++03, protože ten thready moc neřešil.

Jedna vec thread safe funkce, druha je to pouzit thread safe zpusobem, neni problem sprasit predavani vyjimek mezi thready i v C++11.

Ani ne, je zde totiž zásadní rozdíl v zodpovědnosti za ten stav. U std::uncaught_exception se ptáte jen ve chvíli, kdy ten globální stav využijete,

Pokud neco nepotrebuji, tak se neptam.

U globálního chybového stavu se ale musíte ptát pořád, jinak hrozí, že vám něco unikne a následující operace ten stav opět přepíše; proto C má u všech funkcí, které mohou selhat, návratové hodnoty.

Pokud neco potrebuji, tak se ptam.

Vymezoval jste se vuci uziti globalnich promennych v C++, tohle s tim nesouvisi.

A aby tohle nebylo málo, tak globální proměnné nefungují správně pro statické inicializace, protože pořadí inicializace mezi jednotlivými kompilačními jednotkami není nijak zaručeno (i když u primitivních typů je zaručeno, že jsou při spuštění programu vynulované).

A vy si neumite poradit s faktem, ze behove prostredi/system se musi inicializovat? Je podle vas problem implementovat a pouzit staticke objekty tak, aby nezarucene poradi inicializace nebyl problem? Psal jste nekdy SW pro bare-metal?

[Sten]

Jedna vec thread safe funkce, druha je to pouzit thread safe zpusobem, neni problem sprasit predavani vyjimek mezi thready i v C++11.

V C++11 jde předávat výjimky mezi thready, na to slouží std::exception_ptr

Pokud neco potrebuji, tak se ptam.

Chyby potřebujete hlídat pořád, ne?

Vymezoval jste se vuci uziti globalnich promennych v C++, tohle s tim nesouvisi.

No a já psal o změně globálních stavů á la errno sloužící pro předávání chyb, ne o globálních proměnných obecně.

A vy si neumite poradit s faktem, ze behove prostredi/system se musi inicializovat? Je podle vas problem implementovat a pouzit staticke objekty tak, aby nezarucene poradi inicializace nebyl problem? Psal jste nekdy SW pro bare-metal?

Samozřejmě, existují věci jako nifty counter. No jo, proč to dělat jednoduše, když to jde složitě

[Jardík]

Pokud zakomentuju ten define GIMME_TRY_CATCH, tak clang 3.3 ani GCC 4.8.2 ten dtor nezavolají, protože vůbec nedojde ke stack-unwindu. K tomu nedojde ani pokud tam třeba budu zachytávat pointer, protože výjimka typu int nebude zachytávána, tak taky nedojde ke stack-unwindu

%:include <iostream>

%:define GIMME_TRY_CATCH

struct bla
<%
    char const *msg_;
    
    bla(char const *msg): msg_(msg) <%  %>
    ~bla() <% std::cout << msg_ << std::endl;    %>
%>;

int main()
%:if defined(GIMME_TRY_CATCH)
try
%:endif
<%
    bla b("blabla");
    throw 5;
%>
%:if defined(GIMME_TRY_CATCH)
catch(...)
<% throw; %>
%:endif

[Jardík]

Jinak já na to nenadávám, jen jsem na to upozornil, že je to vlastnost, o které jsem do nedávna neměl ani páru, vždy jsem měl za to, že se můžu na mé dtory spolehnout při vyhození výjimky. Pokud tedy opravdu nutně potřebuju, aby byly zavolaný, vím, že musím to obalit v try-catch.

[:::]

Pokud zakomentuju ten define GIMME_TRY_CATCH, tak clang 3.3 ani GCC 4.8.2 ten dtor nezavolají, protože vůbec nedojde ke stack-unwindu.

A on si nekde sleduje ktery vyjimky jsou zrovna osetreny aby vedel jestli udelat stack unwind? Myslel jsem ze ta soucasna implementace vyjimek nema runtime overhead pokud k vyjimce nedojde?

Jinak já na to nenadávám, jen jsem na to upozornil

ja na to nadavam...

[little.owl]

A on si nekde sleduje ktery vyjimky jsou zrovna osetreny aby vedel jestli udelat stack unwind?

Je to soucasti C++ ABI pro danou HW platformu.

[Jardík]

Myslel jsem ze ta soucasna implementace vyjimek nema runtime overhead pokud k vyjimce nedojde?

Tuším, že se tam generují při kompilaci nějaký "tabulky" pro zachytávání výjimek pro stack unwind, které ukazují do "části" té fce, kde je catch blok

[:::]

to jsem si prave myslel taky. Jak ale muze vedet ze se vyjimka nezachytava aniz by ty tabulky vsechny prosel? (nebo jinejma slovama - aniz by provedl stack unwind?)

Jedina moznost co me napada je ze provede stack unwind, ale nevola destruktory. A ve chvili kdy najde obsluhu tak provede stack unwind jeste jednou ale tentokrat ty destruktory zavola...

[Jardík]

#include <iostream>

struct bla
{
    char const *msg_;
    bla(char const* msg): msg_(msg) {}
    ~bla() { std::cout << msg_ << std::endl; }
};

int maybeThrow()
{
    int a;
    std::cin >> a;
    if (a != 0)
        throw a;
    return 0;
}

int main()
{
    bla bla("blabla");
    maybeThrow();
    return 0;
}

0000000000400abd <_Z10maybeThrowv>:
  400abd:       55                      push   rbp
  400abe:       48 89 e5                mov    rbp,rsp
  400ac1:       48 83 ec 10             sub    rsp,0x10
;   rax = &a
  400ac5:       48 8d 45 fc             lea    rax,[rbp-0x4]
;   rsi = fastcall conv, druhý arg, &a
  400ac9:       48 89 c6                mov    rsi,rax
;   rdi = fastcall conv, první arg, &cin
  400acc:       bf e0 12 60 00          mov    edi,0x6012e0
;   cin.operator>>(a)
  400ad1:       e8 9a fe ff ff          call   400970 <_ZNSirsERi@plt>
;   eax = a
  400ad6:       8b 45 fc                mov    eax,DWORD PTR [rbp-0x4]
;   if ( (eax - eax)
  400ad9:       85 c0                   test   eax,eax
;         == 0 ) {
;     goto .__return_zero
;   }
  400adb:       74 21                   je     400afe <_Z10maybeThrowv+0x41>
;   edi = fastcall conv, první arg, sizeof(int)
  400add:       bf 04 00 00 00          mov    edi,0x4
;   rax = exception_ptr = allocate_exception(sizeof(int))
  400ae2:       e8 79 fe ff ff          call   400960 <__cxa_allocate_exception@plt>
;   edx = a
  400ae7:       8b 55 fc                mov    edx,DWORD PTR [rbp-0x4]
;   *(int*)exception_ptr = edx = a
  400aea:       89 10                   mov    DWORD PTR [rax],edx
;   rdx = fastcall conv, třetí arg, 0
  400aec:       ba 00 00 00 00          mov    edx,0x0
;   rsi = fastcall conv, druhý arg, typeid(int)
  400af1:       be 20 15 60 00          mov    esi,0x601520
;   rdi = fastcall conv, první arg, exception_ptr
  400af6:       48 89 c7                mov    rdi,rax
;   throw(exception_ptr, typeid(int), 0)
  400af9:       e8 82 fe ff ff          call   400980 <__cxa_throw@plt>
; .__return_zero:
;    return_value = 0
  400afe:       b8 00 00 00 00          mov    eax,0x0
;    goto .__return
  400b03:       eb 08                   jmp    400b0d <_Z10maybeThrowv+0x50>
; .__unwind_handler:
; .__unwind_resume:
;    rdi = fastcall conv, první arg = exception_ptr
  400b05:       48 89 c7                mov    rdi,rax
;    unwind_resume(exception_ptr)
  400b08:       e8 b3 fe ff ff          call   4009c0 <_Unwind_Resume@plt>
; .__return:
  400b0d:       c9                      leave  
  400b0e:       c3                      ret    

0000000000400b0f <main>:
  400b0f:       55                      push   rbp
  400b10:       48 89 e5                mov    rbp,rsp
  400b13:       53                      push   rbx
  400b14:       48 83 ec 18             sub    rsp,0x18
;   rax = &bla
  400b18:       48 8d 45 e0             lea    rax,[rbp-0x20]
;   rsi = fastcall conv, druhý arg, "blabla"
  400b1c:       be 94 0c 40 00          mov    esi,0x400c94
;   rdi = fastcall conv, první arg, rax = &bla
  400b21:       48 89 c7                mov    rdi,rax
;   new(&bla) bla("blabla")
  400b24:       e8 8f 00 00 00          call   400bb8 <_ZN3blaC1EPKc>
;   maybeThrow()
  400b29:       e8 8f ff ff ff          call   400abd <_Z10maybeThrowv>
;    ebx = return_value = 0
  400b2e:       bb 00 00 00 00          mov    ebx,0x0
;    rax = &bla
  400b33:       48 8d 45 e0             lea    rax,[rbp-0x20]
;    rdi = fastcall conv, první arg, rax = &bla
  400b37:       48 89 c7                mov    rdi,rax
;    bla.~bla();
  400b3a:       e8 93 00 00 00          call   400bd2 <_ZN3blaD1Ev>
;    eax = ebx = return_value
  400b3f:       89 d8                   mov    eax,ebx
;    goto .__return
  400b41:       eb 1c                   jmp    400b5f <main+0x50>
; .__unwind_handler
     rbx = exception_ptr
  400b43:       48 89 c3                mov    rbx,rax
;    rax = &bla
  400b46:       48 8d 45 e0             lea    rax,[rbp-0x20]
;    rdi = fastcall conv, první arg, rax = &bla
  400b4a:       48 89 c7                mov    rdi,rax
;    bla.~bla()
  400b4d:       e8 80 00 00 00          call   400bd2 <_ZN3blaD1Ev>
;    rax = rbx = exception_ptr
  400b52:       48 89 d8                mov    rax,rbx
;    goto __unwind_resume
  400b55:       eb 00                   jmp    400b57 <main+0x48>
; .__unwind_resume:
;    rdi = fastcall conv, první arg = exception_ptr
  400b57:       48 89 c7                mov    rdi,rax
;    unwind_resume()
  400b5a:       e8 61 fe ff ff          call   4009c0 <_Unwind_Resume@plt>
; .__return:
  400b5f:       48 83 c4 18             add    rsp,0x18
  400b63:       5b                      pop    rbx
  400b64:       5d                      pop    rbp
  400b65:       c3                      ret

Zdá se, že vygeneruje uklízející kód v každé fci (mnou označený jako label .__unwind_handler). Pak bude mít nějakou globální tabulku míst, kde se zachytávají výjimky (tj. neprolejzá asi jednotlivý "stack-framy"), když nic podle toho typeid nenajde, tak se na stack-unwind vykašle a chcípne. Pokud v globlální tabulce najde, tak se zavolají jednotlivé .__unwind_handlery až do místa, kde je catch blok pro danou výjimku a předá se řízení tam.

[Jardík]

BTW ten asm, to je neoptimalizovaný kód. Overhead tam je (přeskakuje se .__unwind_resume a 2x se generuje volání těch destruktorů, tj. overhead jak volání, tak velikosti kódu). Při optimalizaci to ale uspořádá lépe a ten jump tam není a .__unwind_resume to hrcne nakonec fce za ret. Overhead tedy není, jen je samozřejmě trochu delší kód fcí, kvůli kódu pro unwind. Podle mě tedy není důvod se výjimkám v C++ vyhýbat.

[Jardík]

optimalizovaný:

0000000000400cb0 <_Z10maybeThrowv>:
  400cb0:       48 83 ec 18             sub    rsp,0x18
  400cb4:       bf 00 13 60 00          mov    edi,0x601300
  400cb9:       48 8d 74 24 0c          lea    rsi,[rsp+0xc]
  400cbe:       e8 3d fe ff ff          call   400b00 <_ZNSirsERi@plt>
  400cc3:       8b 44 24 0c             mov    eax,DWORD PTR [rsp+0xc]
  400cc7:       85 c0                   test   eax,eax
  400cc9:       75 07                   jne    400cd2 <_Z10maybeThrowv+0x22>
  400ccb:       31 c0                   xor    eax,eax
  400ccd:       48 83 c4 18             add    rsp,0x18
  400cd1:       c3                      ret    
  400cd2:       bf 04 00 00 00          mov    edi,0x4
  400cd7:       e8 14 fe ff ff          call   400af0 <__cxa_allocate_exception@plt>
  400cdc:       8b 54 24 0c             mov    edx,DWORD PTR [rsp+0xc]
  400ce0:       be 40 15 60 00          mov    esi,0x601540
  400ce5:       48 89 c7                mov    rdi,rax
  400ce8:       89 10                   mov    DWORD PTR [rax],edx
  400cea:       31 d2                   xor    edx,edx
  400cec:       e8 2f fe ff ff          call   400b20 <__cxa_throw@plt>

0000000000400b60 <main>:
  400b60:       53                      push   rbx
  400b61:       48 83 ec 10             sub    rsp,0x10
  400b65:       48 c7 04 24 34 0e 40    mov    QWORD PTR [rsp],0x400e34
  400b6c:       00 
  400b6d:       e8 3e 01 00 00          call   400cb0 <_Z10maybeThrowv>
  400b72:       48 89 e7                mov    rdi,rsp
  400b75:       e8 86 01 00 00          call   400d00 <_ZN3blaD1Ev>
  400b7a:       48 83 c4 10             add    rsp,0x10
  400b7e:       31 c0                   xor    eax,eax
  400b80:       5b                      pop    rbx
  400b81:       c3                      ret    
  400b82:       48 89 c3                mov    rbx,rax
  400b85:       48 89 e7                mov    rdi,rsp
  400b88:       e8 73 01 00 00          call   400d00 <_ZN3blaD1Ev>
  400b8d:       48 89 df                mov    rdi,rbx
  400b90:       e8 ab ff ff ff          call   400b40 <_Unwind_Resume@plt>

[kralyk z abclinuxu]

To sem řešil v blogu před časem, mam tam diff asm kódu s a bez výjimek...

[little.owl]

To neni smerodatne, problemy jsou hlavne s optimalizaci. To ze se pouzivalo throw() u funkci melo smysl, i kdyz to v praxi neuspelo; navic zalezi zdali ma CPU hw podporu pro vyjimky, pokud ne, muze to byt drahe.

[Sten]

C++11 přidalo noexcept, což je ekvivalent prázdného throw(). Vysokou režii mělo hlavně specifikování výčtu výjimek u throw(), protože se nehledaly jen handlery, ale musela se typově kontrolovat i celá cesta k nim.

[little.owl]

A take ten seznam vyjimek byl na cestne pionyrske, protoze kompilator to nebyl schopen vynutit/zkontrolovat.

[Sten]

GCC i Clang to kontrolují a vyvolávají std::unexpected

[little.owl]

Jde o to, ze to nikdy nejeaky benefit lepsiho kodu neprineslo, stejne se to muselo dynamicky kontrolovat, std::unexpected mi prijde k nicemu. Go tam chcete delat, kdyz je to globalni funkce? Zavolat terminate()?

[Sten]

Ve výchozím stavu std::unexpected volá std::terminate, ale můžete tam zkusit něco jiného, třeba nahradit tu výjimkou jinou ve stylu Javy (std::bad_exception) Výčet výjimek má teoreticky tu výhodu, že programátor ví, jaké výjimky může očekávat, ale prakticky je to příliš komplikované a pomalé, že se místo toho preferuje uvádět ten výčet do dokumentace.

[little.owl]

Ve výchozím stavu std::unexpected volá std::terminate, ale můžete tam zkusit něco jiného, třeba nahradit tu výjimkou jinou ve stylu Javy (std::bad_exception)

Problem je v tom, ze vy v std::unexpected nevite kde vam to v programu vzniklo, tak tam s tim temer nemuzete nic rozumneho delat.

[frr]

Pro mě osobně hodně výživné čtení - jak v této dnešní debatě, tak na odkazech o 2-3 patra dál. Hoši děkuju

[:::]

projit jednotlivy stack-framy musi. V tomhle jednoduchym pripade by to nebylo potreba, ale kdyz tam bude vic funkci ktery se navzajem prevolavaj, navic nektery se muzou kompilovat oddelene, tak neni obecne mozny dopredu vygenerovat statickou tabulku. Jedina moznost je projit zasobnik a podivat se co tam je...

[little.owl]

Jedna z cest, jak osetrit pripadny leak resources pri nedchycene vyjimce je registrovat svoji terminate funkci (std::terminate(), std::set_terminate()) a v ni vsechno co neumi uklidit automaticky OS osetrit; ale nepomuze vam to u knihoven.

Pokud zabalite kod do try {} catch(...) {} v main() bude stack unwound.

Celkove je to cele na <>, a u relativne low level veci je lepsi se vyvarovat jednak vyjimek a jednak C++.

[pavlix]

Celkove je to cele na <>, a u relativne low level veci je lepsi se vyvarovat jednak vyjimek a jednak C++.

Taky mám ten dojem. A u relativně highlevel věcí se C++ taky vyhýbám.

[little.owl]

Taky mám ten dojem. A u relativně highlevel věcí se C++ taky vyhýbám.

Mne spise vadi, ze v rukou [pod]prumernych programatoru (vetsina) je C++ zbran hromadneho niceni, z rady uhlu pohledu turing tarpit.
Lepsi, kde to jde, je kombinace C (knihovna, backend) a nejaky highlevel language s GC.

[----]

I přes všechny neduhy je C++ v rukou slušného programátora celkem užitečný nástroj - chce si to uvědomit, kdy co použít a kdy co ne a NEPOVAŽOVAT C++ za high level OOP jazyk, ale spíš jen za sadu rozšíření pro C, kde si člověk může vybrat, co použije a co ne.

Ti (pod)průměrní programátoři často poslouchají všechny ty divné "C++ best practices" a používají knihovny jako Boost a nakonec se z jejich kódu stane bordel, který naprosto nejde udržovat (nebo jde, ale jen s velkým vývojářským týmem).

Bohužel C++ standards commitee se zdá být C++ směřovat právě k těm (pod)průměrným programátorům...

Osobně úspěšně používám C++ (v relativně low level formě, kde ty C++ featury využiju ku prospěchu a v čistém C by mi třeba chyběly, nebo by byl zápis takového kódu o dost míň elegantní) v kombinaci s tím high level GC jazykem (většinou LuaJIT) a funguje to. Používám i čisté C. Ale rád bych viděl nějaký pořádný systems programming jazyk... zatím Rust je IMHO nejblíž, ale ukáže se až časem.

[deda.jabko]

Souhlas, IMHO jedine pouzitelne C++ je Qt.

[little.owl]

Stejny problem. Dejte do rukou v projektu nekterym lidem Qt a budete je muset hlidat, aby vam z toho neudelali nove KDE; cpou Qt i tam kde by si vystacili i se standardni knihovnou.

[mirec]

Čo je zlé na Boost? Teda nie že by som boost používal, naposledy som sa hral pred pár rokmi so serializáciou, ale zdala sa mi to krásna celkom premyslená sada knižníc (alebo skôr šablón?). Zopár programov stavaných na booste použávam (vrátane balíčkovacieho systému) a ani na jeden sa nemôžem v podstate sťažovať.

[:::]

souhlas, v boostu jsou nektery docela dobry veci.

Obcas se to muze zdat prehnane komplikovany, ale tam bych videl problem spis v samotnym C++ - ten sablonovej podjazyk je hodne omezenej a to obcas vede na explozi v mnozstvi kodu...

[----]

Je to plné hacků, zpomaluje kompilaci (výrazně), error hlášky dělá nepoužitelnými, je skoro nemožné to vykopat ven, a jako celek je to prostě moc velký balík a bloat (existuje nástroj, který boost omezí jen na věci, které používáš, ale i tak to tam natahá spoustu věcí a takový nástroj by přitom vůbec neměl existovat)... pak taky Boost knihovny, které se sestavují (pár jich je, třeba boost::python) se oficiálně dají sestavit jen přes bjam, a jakékoliv vlastní řešení je nepodporované...

[mirec]

Je to plné hacků

Nepopieram. Presne v duchu štandardnej knižnice.

zpomaluje kompilaci (výrazně)

Používa šablóny (masívne) a tie sú v GCC pomalé. Nie je to problémom boostu.

error hlášky dělá nepoužitelnými

Videl som ich zopár keď som skúšal. Katastrofa spôsobená kompilátorom / jazykom. Trochu zmierniť to mali koncepty, ale nakoniec sa do štandardu neprijali. Nepovažujem to ale za chybu knižnice.

jako celek je to prostě moc velký balík a bloat

Mnoho knižníc sú len šablóny (tj. vôbec sa nemusí linkovať .so, ale kompilácia trvá dlhšie). Boost je rozsekaný na malé časti, ale je pravda, že ako celok je dosť veľký.

pak taky Boost knihovny, které se sestavují (pár jich je, třeba boost::python) se oficiálně dají sestavit jen přes bjam

Teraz si nie som istý ako je to myslené. Zostavoval som už programy používajúce boost::python pomocou cmake a fungovalo to. Ak ide o zostavenie samotného boost::python nepovažoval by som to v zásade za problém, mnoho knižníc nejde zostaviť bez autotools čo považujem za omnoho väčšie zlo.

[Radek Miček]

rád bych viděl nějaký pořádný systems programming jazyk... zatím Rust je IMHO nejblíž

Proč myslíte? Co se vám tam tak líbí?

Typový systém Rustu je momentálně dost slabý na to, aby bezpečně popsal řadu užitečných konstrukcí (například paralelní algoritmy typu rozděl a panuj). V podstatě lze mít jen stromové struktury. Je tam sice počítání referencí a jednoduchý GC, ale to už je snad lepší použít jazyk s plně automatickou správou paměti pomocí pokročilého GC.

Další nevýhoda Rustu je množství druhů ukazatelů, což zřejmě povede k duplikaci kódu.

[----]

Automatická správa paměti v Rustu se časem přesune do knihovny, idiomatický kód používá unique ownership (popř. se to dá na stack). Type system je oproti třeba C/C++ dost pokročilý (má např. algebraické datové typy s pattern matchingem), nemá sice globální inferenci, ale u takového jazyka to ani není moc potřeba (pokud chci opravdu pokročilý typesystem, použiju třeba ATS, OCaml, nebo Haskell). Několik typů pointerů má své nesporné výhody - když chci manipulovat s low-level věcma, použiju unsafe pointery se všemi svými nebezpečími; v normálním kódu použiju unique pointery a borrowed reference, kde nehrozí chyby způsobené NULL nebo dangling pointery.

Na Rustu se mi líbí to, že dokázali dostat do jazyka spoustu featur známých ze spíš "výzkumných" jazyků jako *ML (ADTs, pattern matching, type classes...) bez toho, aby moc narostlo runtime a bez celkové komplikace jazyka.

Kromě toho se mi ještě líbí jeho concurrency model. Je dobře integrovaný do jazyka a dělá psaní výkonného paralelního kódu o dost pohodlnější, než v mnoha jiných jazycích. Exchange heap funguje dobře a task-based model se schedulerem taky není k zahození.

Traits přímo v jazyce je taky zajímavý přístup a funguje dobře.

Najít dobrý střed mezi relativně jednoduchým jazykem použitelným pro systémové programování (Rust je mimo jiné schopný běžet skoro bez žádného runtime a už jsem viděl i jednoduchý kernel v něm psaný) a high level featurami a bezpečností není jednoduché, Rust je IMHO zatím na dobré cestě.

[Sten]

Mě by zajímalo, jak dělají borrow reference, které nemohou skončit dangling. Teda pokud to nejsou jen weak pointery (které C++ umí).

[Radek Miček]

Životnost reference je vázána na původní objekt (pochopitelně může být i menší) – viz Borrowed Pointers Tutorial/Named lifetimes.

[Radek Miček]

Představte si situaci, kdy máte jednu velkou strukturu a její části mají různou životnost. Dále chcete mít vektor ukazatelů na části té velké struktury. Problém je, že všechny ty ukazatele ve vektoru musí mít stejnou životnost.

Nebo si představte spojový seznam, kde liché prvky chcete měnit v jednom vlákně a sudé ve druhém.

Pro oba případy je typový systém Rustu nedostatečný.

[Sten]

Takže pokud je ten objekt na haldě a já jej zdestruuji, zatímco stále existuje ta reference, tak mám dangling referenci?

[Radek Miček]

Destruktory se volají automaticky. Navíc typový systém garantuje následující (cituji z Tutorial/Destructors):

Objects are never accessible after their destructor has been called, so there are no dynamic failures from accessing freed resources. When a task fails, the destructors of all objects in the task are called.

[Sten]

Destruktory volá automaticky i C++

Takže to používá garbage collector (tj. dokud existuje reference, objekt existuje) nebo ty reference jsou weak pointery (tj. když objekt zanikne, ty reference se zneplatní a vyhazují výjimku při přístupu)?

[Radek Miček]

Takže to používá garbage collector (tj. dokud existuje reference, objekt existuje) nebo ty reference jsou weak pointery (tj. když objekt zanikne, ty reference se zneplatní a vyhazují výjimku při přístupu)?

Ani jedno. Součástí typu vypůjčených referencí je životnost a staticky se kontroluje, že je menší než životnost referencovaného objektu – když kompilátor tohle nevidí, tak program nepřeloží. Například si vypůjčenou referenci nemůžete uložit do jiného objektu, který by mohl přežít referencovaný objekt.

[Sten]

Aha. Zajímavý přístup Bohužel v C++ by tenhle contract nešel prakticky bezpečně ověřit.

[Radek Miček]

Podobnou míru bezpečnosti dokáže zaručit třeba jazyk ParaSail - viz článek ParaSail: Less is more with multicore. Na rozdíl od Rustu podporuje ParaSail složitější invarianty v kódu, tudíž půjde bezpečně zapsat více programů. Obávám se, že v Rustu bezpečně nenapíšete ani paralelní QuickSort.

Pokud jde o bezpečné paralelní programování, může být zajímavý i jazyk Mezzo. Na rozdíl od výše jmenovaných má GC, takže netrpí problémy s modularitou. Jednoduché situace v něm lze vyjádřit staticky, složitější pomocí kontrol za běhu. Do budoucna autoři plánují možnost popsat i složitější situace staticky.

[kralyk z abclinuxu]

Tak jsem na ten Rust koukl (tutoriál) a překvapilo mě to - vypadá to opravdu pěkně (Až na nějaké drobné podivnosti v syntaxi, ale to vem čert...).

Zejména RAII a move semantics integrované přímo do jazyka a celkově přístup k správě paměti se mi líbí. Zatím jsem se nevrtal v detailech, ale vypadá to, že Rust je jeden z mála jazyků, kde používají garbage collection rozumným způsobem. Narozdíl od jazyků typu Lisp, Java, C# apod., kde se GC pokoušejí použít jako všelék na všechny problémy se správou paměti.

Tasky vypadají zajímavě, ale nějak na první pohled nevidím způsob, jak předávat větší množství dat mezi tasky. Dejme tomu, že budu mít větší kus dat, která potřebují nějak transformovat (něco vypočítat apod.) a budu chtít tu práci rozdělit na vhodný počet kusů, z nichž každý se spočítá v samostatném threadu (ie. každý thread potřebuje zápis do své části). Dá se tohle nějak rozumně udělat v Rustu?

Error-handling vypadá celkem dobře, očividně je dost flexibilní.

Crates & modules taky hezký nápad, pokud to bude dobře fungovat v praxi. (O linkování, ABI et al. se tam moc nepíše.)

Ten pattern matching mi připadá spíš jako drobnost, z velké části mi to přijde jako syntaktický cukr...

Zbývá už snad jen to, aby měl tenhle jazyk dostatečnou popularitu

[----]

U C++ je lepší se vyhýbat exceptions kdykoliv - stojí to za h*vno... třeba parametr -fno-exceptions gcc/clangu s tímto pomůže.

[little.owl]

+1

[:::]

-1

priklad: mam nekolik funkci

A() vola B(), vola C(), ...

V nejhlubsi funkci zjistim fatalni chybu a potrebuju se vratit do A(). S vyjimkama me staci dat do A() jeden catch. Bez vyjimek musim zaneradit vsechny funkce po ceste kodem na obsluhu a propagaci chyby...

[little.owl]

Bez vyjimek musim zaneradit vsechny funkce po ceste kodem na obsluhu a propagaci chyby...

Nemusite: setjmp() a longjmp(), pripadne POSIX context control vam umozni v rade pripadu bezpecnejsi handling chyb.

[:::]

long jump se taky propaguje stack unwindem. Navic se mu musi predat ukazatel na kontext.

Takze ziskam stejnou funkcionalitu jako u vyjimek, jenom to cely bude slozitejsi...

[little.owl]

Opet vedle, setjmp/longjmp neprovadi stack unwinding a ani se jim nepropaguje, a implementace je casto velmi jednoducha a snadno debugovatelna.

[:::]

V C asi ne, ale v C++ ho provadet musi. Jinak by nebylo zajisteny ze se spravne zavolaji destruktory.

[little.owl]

Destruktory se nevolaji. V podstate to ulozi calling environment do bufferu a z neho pozdeji obnovy, nic vic, zbytek je na programatorovi a zadne uklizeci akce se automaticky nedelaji.

[little.owl]

V C++ sice muze (may) byt proveden uklid netrivialnich destruktoru, u ostatnich je to "undefined behaviour"; v praxi na to nejde spolehat.

[little.owl]

errr ... pisi a pracuji .... uklid trivialnich destruktoru .... coz uz neni treba smart pointer ci cokoliv co nema imlicitne definovany destruktor

[:::]

Jo mas pravdu, to je teda nechutnost...

If any automatic objects would be destroyed by a thrown exception transferring control to another (destination) point in the program, then a call to longjmp(jbuf, val) at the throw point that transfers control to the same (destination) point has undefined behavior.

[kralyk z abclinuxu]

Opet vedle, setjmp/longjmp neprovadi stack unwinding

Tohle jsem původně v diskusi přehlédl. longjmp může provádět stack unwinding, pokud to tak je na dané platformě implementováno. Což např. na x64 je ("forced unwinding").

[kralyk z abclinuxu]

Nemusite: setjmp() a longjmp()

setjmp/longjmp je pěkná prasárna. Je to v podstatě jako goto, ale ještě horší

[little.owl]

Neni, v podstate se uklada calling context, a v pripade potreby obnovy. Muzete implementovat mechanizmus podobny vyjimkam, s tim ze to mate pod vetsi kontrolou bez te tuny implementacne zavisleho a nespecifikovaneho chovani.

[Sten]

Máte dvě možnosti: buďto ukládáte data jen na stack a nepoužíváte resources a pak je úplně jedno, jestli to řešíte výjimkou nebo uděláte longjmp, nebo ne, a potom bude longjmp nádherně leakovat

[little.owl]

Vubec ne. Pouziti longjmp mi zajisti potrebnou funkcionalitu a pritom umozni disablovat vyjimky a RTTI.

[Sten]

A jak pomocí longjmp dealokujete data na haldě?

[little.owl]

V casti stacku, ktery muze byt stracen, proste zadnou dynamickou alokaci nedelam.

[Sten]

Aha, takže máte systém, který neumí to hlavní, proč se výjimky používají, ale je určitě lepší

[little.owl]

Jiste, je. Za prve, dynamickou alokaci v cele rade pripadu vubec nepouzivame. Za druhe, hlavni vyhodou setjmp/longjmp je transparentnost, presne vim, kam to skoci, jaka cast stacku se ztrati, jsme to schopni i staticky verifikovat. V pripade vyjimek je to diky dynamickemu hledani handleru o poznani slozitejsi, zejmena pokud pouzivate plno third party kodu. Za treti, samotna implementace setjmp/longjmp je o jednoduzsi, s presneji definovanym chovanim, implementovana v knihovne; byl jsem schopen treba zajistit, ze behem setjmp/longjmp nedojde k task switch. Zajistit u vyjimek, aby po jejim vzniku nedoslo k task switchi, pred jejim zpracovanim a unwindingem, a dalsim vyjimkam, v jinych threadech, bez souvisejiciho zpozdeni, je casto nemozne, navic implementacne zavisle.

[Sten]

Samozřejmě, pokud nepoužíváte dynamické alokace (a vůbec alokace zdrojů), tak výjimky asi nepotřebujete, protože ani nemáte RAII, které je na nich závislé.

Nechápu tu část s task switchem. Task switch přeci řeší jádro, ne? longjmp pouze posune ukazatel stacku a nastaví signal mask (oboje v user space), klidně se může stát, že během toho dojde k tiku hodin a jádro udělá task switch.

[Sten]

Teda signal mask samozřejmě nastavuje jádro, ale longjmp volá z user space sigsetmask

[little.owl]

pokud nepoužíváte dynamické alokace

Pouzivame, a nejen alokace SW zdroju, ale i HW zdroju.

tak výjimky asi nepotřebujete, protože ani nemáte RAII,

Vyjimky jsou jen dalsi asynchronni event, stejne jako interrupty, takze bezpecnou alokaci resources v asynchronnim prostredi musime resit.

Task switch přeci řeší jádro, ne?

Ano. U cele rady OS mohu task switch kontrolovane disablovat, stejne jako treba interrupty.

longjmp pouze posune ukazatel stacku a nastaví signal mask (oboje v user space),

setjmp/longjmp obnovuje calling environment, funguje i ve freestanding systemu a ukazatel stacku je jen jeden z parametru prostredi.

setjmp/longjmp je soucasti knihovny, nikoliv implementacne zavisla soucast jazyka a tak ma uzivatel celkem slusnou kontrolu.

[Sten]

Vyjimky jsou jen dalsi asynchronni event, stejne jako interrupty, takze bezpecnou alokaci resources v asynchronnim prostredi musime resit.

V tom případě opět nechápu, jakou má výhodu setjmp/longjmp oproti výjimkám, obzvlášť když longjmp na rozdíl od výjimek nedokáže řešit dealokace.

Ano. U cele rady OS mohu task switch kontrolovane disablovat, stejne jako treba interrupty.

Tak to můžete udělat i u výjimek, stačí v konstruktoru výjimky task switch zakázat a v destruktoru (a std::terminate, pokud se to nepovolí automaticky při pádu programu) opět povolit.

setjmp/longjmp je soucasti knihovny, nikoliv implementacne zavisla soucast jazyka a tak ma uzivatel celkem slusnou kontrolu

setjmp a longjmp je podobně implementačně závislé jako vyhazování výjimek, na různých systémech a implementacích to ukládá a obnovuje různé věci. POSIX jenom velmi vágně specifikuje, co se vlastně ukládá a obnovuje. Pokud nahradíte if (setjmp(buf) == 0) { ... } else { ... } za try { ... } catch (...) { ... }, longjmp za throw a vlastní úpravy v longjmp a setjmp přesunete do konstruktoru a destruktoru výjimky, máte to samé a navíc získáte funkční RAII.

[little.owl]

V tom případě opět nechápu, jakou má výhodu setjmp/longjmp oproti výjimkám, obzvlášť když longjmp na rozdíl od výjimek nedokáže řešit dealokace.

Duvody jsem vam jiz psal.

Tak to můžete udělat i u výjimek, stačí v konstruktoru výjimky task switch zakázat a v destruktoru (a std::terminate, pokud se to nepovolí automaticky při pádu programu) opět povolit.

Posledni co bych delal je nahrazoval trivialni a rychle volani funkce citajici maximalne par desitek instrukci vyjimkami. Co se deje mezi zavolanim throw a predanim vyjimky do handleru, pokud existuje, je jedna velka implementacni neznama, od alokace pameti a mozneho vytvareni kopii vyjimky, pres hledani handleru a zpracovani typove informace, stejne jako doba trvani tohoto procesu.

setjmp a longjmp je podobně implementačně závislé jako vyhazování výjimek,

Tyto funkce jsou vetsinou velmi primitivni, ukladaji par systemovych registru a provadi par cache operaci, jejich implementace je vesmes nezajimava a chovani celkem jasne specifikovane. Pokud nejsem spokojen s implementaci, mohu tyto funkce nahradit vlastni verzi; u vyjimek komplexni kod generovany kompilatorem proste nezmenite.

[Sten]

Co se deje mezi zavolanim throw a predanim vyjimky do handleru, pokud existuje, je jedna velka implementacni neznama, od alokace pameti a mozneho vytvareni kopii vyjimky, pres hledani handleru a zpracovani typove informace, stejne jako doba trvani tohoto procesu.

Co se tam děje, není žádná černá magie, ale je to dobře zdokumentované. Samozřejmě existují implementace, které nepoužívají Itanium ABI, ale ty většinou neumí ani pořádně C++, a tak na nich stejně budete psát prakticky jen v Céčku.

Dobu trvání, než dojde k zachycení výjimky, určitě dokážete statickou analýzou spočítat o dost snáze než dobu trvání řetězu longjmpů (předpokládám, že tedy tak řešíte ty dynamické dealokace).

Tyto funkce jsou vetsinou velmi primitivni, ukladaji par systemovych registru a provadi par cache operaci, jejich implementace je vesmes nezajimava a chovani celkem jasne specifikovane. Pokud nejsem spokojen s implementaci, mohu tyto funkce nahradit vlastni verzi; u vyjimek komplexni kod generovany kompilatorem proste nezmenite.

Kompilátor toho moc negeneruje. Získá prostor pro výjimku pomocí __cxa_allocate_exception (klidně můžete vrátit statický per-thread buffer, který teď používáte pro longjmp), na získaném místě spustí její konstruktor a nakonec zavolá __cxa_throw, který si podle té dokumentace celkem snadno můžete napsat vlastní; catch na konci potom zavolá __cxa_free_exception, což by u vás byl nejspíš noop. Pokud budete používat výjimky jen jednoho typu (= velmi podobné tomu, co máte teď s longjmp), tak to bude taky za pár desítek procesorových taktů.

[little.owl]

Pitomosti.

Co se tam děje, není žádná černá magie, ale je to dobře zdokumentované. Samozřejmě existují implementace, které nepoužívají Itanium ABI, ale ty většinou neumí ani pořádně C++, a tak na nich stejně budete psát prakticky jen v Céčku.

Za prve, nepisi, ze je to cerna magie, ale implementacni neznama.

Za druhe, o tom co je "poradne C++" rozhoduje konformita s ISO C++ standardem a ta tuhle zalezitost neresi; a rule of thumb je stavet na standardizovanych vecech.

Za treti, kazda platforma ma sve specificke prvky C++ ABI - a Itanium je jedna z nich, byt jejich C++ model je ramcove zaklad i pro ostatni. Uvedomte si co to je - binary interface. Mam k tady dispozici tri C++ kompilatory postavene na stejnem EABI (ARM spec) a linkovat je stejne nemuzete, protoze je tam stale vysoky stupen volnosti (kazdy si navic interpretuje standard po svem). Iterface neni implementace, vlastni implemetace se i u stejneho C++ ABI se lisi - a hraje tam roli i OS na kterem to bezi - kapitolou samu pro sebe jsou HW exceptions mapovane jako foreign exceptions - muzete mluvit o stesti pokud za vas resi prave OS - a pokud mozno ne v C++.

které nepoužívají Itanium ABI, ale ty většinou neumí ani pořádně C++

Jako treba naprosto zanedbatelny Microsoft C++, kde se prave exception model da [nekompatibilne] zmenit nekolika flagy, a ABI se meni snad kazdou major verzi?

Kompilátor toho moc negeneruje.

Generuje toho dosti, casto specificka metadata (minimalne subset RTTI), vcetne jejich parsovani, hledani hlandleru etc. Alokace pameti a kopie vyjimky muze byt provadena, az kdyz je znam handler, a k tomu je dlouha cesta, pokud to primo nezkonci v terminate().

Dobu trvání, než dojde k zachycení výjimky, určitě dokážete statickou analýzou spočítat o dost snáze než dobu trvání řetězu longjmpů (předpokládám, že tedy tak řešíte ty dynamické dealokace).

Tak tohle uz je tuplovana kravina. Psal jsem, ze zadnou dynamickou alokaci zdroju ve ztracene casti stacku nemame. Longjump mame jen jeden je ve sve podstate stale jen jump out-of-scope na nejakou predchozi pozici v case a vetsinou se jedna o rychlou, nearly-constant-time operaci. Muzete mi nastinit, jak bychom meli podle vas statickou analyzou spocitat dobu zachyceni asynchronni vyjimky?

Kdyz nekdo zacne pouzivat pojem standardni ABI v kontextu s C++, zacina se mi delat nevolno od zaludku.

[Sten]

Za prve, nepisi, ze je to cerna magie, ale implementacni neznama.

Za druhe, o tom co je "poradne C++" rozhoduje konformita s ISO C++ standardem a ta tuhle zalezitost neresi; a rule of thumb je stavet na standardizovanych vecech.

Za treti, kazda platforma ma sve specificke prvky C++ ABI - a Itanium je jedna z nich, byt jejich C++ model je ramcove zaklad i pro ostatni. Uvedomte si co to je - binary interface. Mam k tady dispozici tri C++ kompilatory postavene na stejnem EABI (ARM spec) a linkovat je stejne nemuzete, protoze je tam stale vysoky stupen volnosti (kazdy si navic interpretuje standard po svem). Iterface neni implementace, vlastni implemetace se i u stejneho C++ ABI se lisi - a hraje tam roli i OS na kterem to bezi - kapitolou samu pro sebe jsou HW exceptions mapovane jako foreign exceptions - muzete mluvit o stesti pokud za vas resi prave OS - a pokud mozno ne v C++.

Všechny tři věci se týkají i setjmp/longjmp. Navíc to Itanium ABI se na ostatních platformách liší minimálně (na které při psaní __cxa_throw pravděpodobně nenarazíte), na rozdíl od implementace setjmp/longjmp.

Jako treba naprosto zanedbatelny Microsoft C++, kde se prave exception model da [nekompatibilne] zmenit nekolika flagy, a ABI se meni snad kazdou major verzi?

Microsoft C++ používá jiný systém, ale také plně dokumentovaný. AFAIK se těmi flagy nijak nemění ABI vyhazování výjimek, které také řeší to DLLko. Nakonec ve Windows je také jiná implementace setjmp/longjmp než na UNIXech.

Generuje toho dosti, casto specificka metadata (minimalne subset RTTI), vcetne jejich parsovani, hledani hlandleru etc. Alokace pameti a kopie vyjimky muze byt provadena, az kdyz je znam handler, a k tomu je dlouha cesta, pokud to primo nezkonci v terminate().

RTTI nemusíte používat, pokud budete používat jen jeden typ výjimek (tedy jako rychlou náhradu setjmp/longjmp s RAII). Hledání handleru i volání terminate() řeší __cxa_throw, kompilátor nic takového negeneruje. Výjimka je ještě před voláním terminate() vytvořena (konstruktor se volá, ta zkratka při terminate akorát přeskakuje volání destruktorů), takže v terminate můžete použít current_exception a vrátí vám to tu výjimku.

Psal jsem, ze zadnou dynamickou alokaci zdroju ve ztracene casti stacku nemame. Longjump mame jen jeden je ve sve podstate stale jen jump out-of-scope na nejakou predchozi pozici v case a vetsinou se jedna o rychlou, nearly-constant-time operaci.

Tak už se rozhodněte, jestli používáte nebo ne. Na tohle jsem totiž napsal Samozřejmě, pokud nepoužíváte dynamické alokace (a vůbec alokace zdrojů), tak výjimky asi nepotřebujete, protože ani nemáte RAII, které je na nich závislé, na což se mi dostalo odpovědi Pouzivame, a nejen alokace SW zdroju, ale i HW zdroju.

[little.owl]

Všechny tři věci se týkají i setjmp/longjmp. Navíc to Itanium ABI se na ostatních platformách liší minimálně (na které při psaní __cxa_throw pravděpodobně nenarazíte), na rozdíl od implementace setjmp/longjmp.

Ne. Chovani setjmp/longjmp je dano C/C++ standardem. Implementace je v danem kontextu nezajimava a vesmes velmi primitivni (ukladaji/obnovuji se v podstate jen systemove registry ve spravnem poradi) a verejne knihovni funkce, narozdil od internich, lze vetsinou reimplementovat bez vetsich rizik.

Microsoft C++ používá jiný systém, ale také plně dokumentovaný.

Bullshit. Na WinCE/SH4 jsme museli podepsat NDA, abychom ji dostali a lide od Trolltech/Qt ji tehdy nedostali vubec. Pokud je to oficialne verejne dostupne, sem s tim.

RTTI nemusíte používat, pokud budete používat jen jeden typ výjimek

A jak jako presvedcim genericky kompilator (a) pouzivat jeden typ vyjimek (b) negenerovat pro ne nejakou obdobu RTTI?

Hledání handleru i volání terminate() řeší __cxa_throw, kompilátor nic takového negeneruje. Výjimka je ještě před voláním terminate() vytvořena (konstruktor se volá, ta zkratka při terminate akorát přeskakuje volání destruktorů), takže v terminate můžete použít current_exception a vrátí vám to tu výjimku.

Zacinate pouzivat pristup, kdy reagojete na neco co jsem bud nerikal, nerozporoval nebo neresil. Kompilator muze generovat jednak kod a jednak specificke informace; kod MS VC pouziva oboji - compiler-generated unwind funclety a specialni datove struktury, a i dalsi kompilatory pouzivaji minimalne specialni data pro unwind personality funkce.

Tak už se rozhodněte, jestli používáte nebo ne. Na tohle jsem totiž napsal Samozřejmě, pokud nepoužíváte dynamické alokace (a vůbec alokace zdrojů), tak výjimky asi nepotřebujete, protože ani nemáte RAII, které je na nich závislé, na což se mi dostalo odpovědi Pouzivame, a nejen alokace SW zdroju, ale i HW zdroju.

Psal jsem "zadnou dynamickou alokaci zdroju ve ztracene casti stacku nemame". I kdybychom meli, muze to byt irelevantni, pokud bychom meli jiny mechanismus jak trackovat dynamicky alokovane zdroje (e.g. resource manager).

Vase snaha obhajit pouziti vyjimek i za cenu zabihani do z hlediska C++ nestandardnich implementacnich detailu, internich funkcich zacinajicich "__" - prectete si co to v C/C++ znamena - je uz usmevna, zejmena v kontextu toho ze i treba v coding standardu samotneho Clang/LLVM je pouziti exception a RTTI zakazano - asi jsou take pitomci a nic nevi o C/C++; stejne jako ve vetsine standardu pro bezpecny SW.

[biolog]

Chování výjimek je taky definováno standardem. Není definováno zda se zavolají destruktory před tím, než program umře při neodchycené výjimce, a možná pár okrajových situací (a ty asi jde dohledat). Implementace je nezajímavá.

Bullshit. Na WinCE/SH4 jsme museli podepsat NDA, ...

Fajn, někde je implementace nedokumentovaná. Ale chování C++ výjimek je stejné, podle specifikace jazyka.

Jako treba naprosto zanedbatelny Microsoft C++, kde se prave exception model da [nekompatibilne] zmenit nekolika flagy, a ABI se meni snad kazdou major verzi?

Chování C++ výjimek a ABI je stejné, mění se jen chování Windowsích SEH výjimek. Nové verze Visual C++ přichází s dodělanější podporou C++ (v tom MS laguje), což může změnit ABI někde, ne nutně u výjimek nebo někde kde by to vadilo. Naposledy C++ do std::list<> přidalo .size() v O(1), což změnilo layout té struktury, to technicky vzato mění ABI.

A jak jako presvedcim genericky kompilator (a) pouzivat jeden typ vyjimek (b) negenerovat pro ne nejakou obdobu RTTI?

Generuje pár desítek bajtů pro každý házený typ, tak málo skoro nikdy nevadí, asi ani na embedded systémech.

Vase snaha obhajit pouziti vyjimek i za cenu zabihani do z hlediska C++ nestandardnich implementacnich detailu, internich funkcich zacinajicich "__" - ...

Uživatel Sten by jména funkcí nemusel zmiňovat, jsou dobrá akorát pro dohledatelnost a porozumění.

Mam k tady dispozici tri C++ kompilatory postavene na stejnem EABI (ARM spec) a linkovat je stejne nemuzete, protoze je tam stale vysoky stupen volnosti (kazdy si navic interpretuje standard po svem).

Fajn, autoři překladačů se neshodli na dostatečně definovaném ABI. Ale to není problém jazyka. Každý jazyk (i ručně dělaná knihovna C++ výjimky, i knihovna na setjmp/longjmp), který zajišťuje volání destruktorů a hlášení detailů chyby jinými typy než int-em bude řešit stejné problémy. Když nepoužijete destruktory, přesunete složitost/práci na jiné místo a na jinou formu, např na nějaké resource managery, clan-up stack jako v Symbianu. Když odeberete hlášení detailů z místa selhání, můžete dávat uživateli akorát hlášky typu "operace, které nerozumíte, selhala, protože neexistuje soubor s (nyní) neznámým jménem".

... kapitolou samu pro sebe jsou HW exceptions mapovane jako foreign exceptions ...

HW trapy jsou tzv. asynchronní výjimky, mohou nastat (z pohledu překladače) u každé instrukce a C++ s nimi proto nepočítá. Je stejně těžké je řešit i v C.

Jestli dobře rozumím Vaší situaci, tak volání destruktorů ani házení více typů nepoužíváte, a bojíte se i malého množství překladačova cleanup kódu (tipuji 8 bajtů na funkci nemající cleanup) a divokého kódu v destruktorech které by někdo mohl napsat. V takovém případě překladání v C nebo s vypnutými výjimkami zajistí, že se to nestane - jinak dodržování vašeho specifika závisí na disciplíně nebo lint-like nástrojích. To musí jít velice embedded systém; tipuji správně 16bit?

Ale to není problém C++ výjimek ve většinovém případě. Ve většinovém případě vadí jen to, že programátoři neoznačují funkce, které mohou selhat.

[little.owl]

Haha, tak jsem si nasel zduvodneni, proc vlastne v Clang/LLVM nepouzivaji RTTI/vyjimky:

In an effort to reduce code and executable size, LLVM does not use RTTI (e.g. dynamic_cast<>;) or exceptions. These two language features violate the general C++ principle of “you only pay for what you use”, causing executable bloat even if exceptions are never used in the code base, or if RTTI is never used for a class. Because of this, we turn them off globally in the code.

A to maji stesti, ze jejich SW beha na plnohodnotnym OS, omeznem poctu kompilatoru a nejedna se systemove programovani, potom by meli horsi problemy velikost kodu a binarek.

[little.owl]

Navic bystem mi mohl vysvetlit, proc jim to zpusobuje "executable bloat" kdyz podle vas kompilator v podstate nic navic negeneruje.

[kralyk z abclinuxu]

Hned v dalším odstavci píší, že si to implementovali po svém.

[kralyk z abclinuxu]

<ošklivá poznámka>Hmm, chci vidět, jak tohle uhlídáš, když neuhlídáš, aby se nečekalo v dtorech.</ošklivá poznámka>

Přijde mi to, jako dost zásadní omezení, ten stack totiž může být dost rozsáhlej. A další nepříjemnost s longjmp je, že musíš mít někde schovanej jeden nebo několik jmp_bufů a seš omezen na jedinej typ 'výjimky' - int.

Mimochodem, RTTI na výjimky nepotřebuješ, může klidně vypnout RTTI a přitom používat výjimky.

[little.owl]

Hmm, chci vidět, jak tohle uhlídáš, když neuhlídáš, aby se nečekalo v dtorech.

Fair enough. To ze to neni dobre reseni jsme vedeli, ale kod fungoval, nebyl to nikdy problem, navic to byla cast dodana zakaznikem. Za techto podminek nema delat refaktoring smysl, naklady a riziko rozbiti funkcniho kodu pak neobhajim. Pokud je to nutnost, uhlidame to.

Mimochodem, RTTI na výjimky nepotřebuješ, může klidně vypnout RTTI a přitom používat výjimky.

Vyjimky potrebuji urcity subset RTTI ci nejakou introspeci a je na implementaci, zdali vam to dovoli ci ne. Starsi ARM kompilatory to potrebovaly a navic tam bylo plno limitu (staticke linkovani, zaviselo na pouzite std lib etc.); vse je to implementacne zavisle.

[kralyk z abclinuxu]

Tak je to na implementaci, to každopádně, nicméně afaik většinou implementace tyhle dvě nesvazují. Takhle k tomu přistupuje GCC:

-fno-rtti

Disable generation of information about every class with virtual functions for use by the C++ run-time type identification features (dynamic_cast and typeid). If you don't use those parts of the language, you can save some space by using this flag. Note that exception handling uses the same information, but G++ generates it as needed. The dynamic_cast operator can still be used for casts that do not require run-time type information, i.e. casts to "void *" or to unambiguous base classes.

Nevim jak je to u Clangu/LLVM, ale ti mají celý nějaký vlastní rtti systém (prý efektivnější)...

MSVC zase používá jakousi windowsí systémovou implementaci exceptions určenou pro všechny možný jazyky, takže počítám, že na C++ rtti to taky nebude závislé.

Imho tuhle závislost budou mít jen staré/obskurní implementace... imho.

[:::]

Tu podtrzenou cast chapu tak ze tam to RTTI stejne da, ale jenom pro tridy ktery to potrebujou.

Uplne se tomu asi nevyhnes, protoze pro zjisteni jestli catch block zachytava vyjimku v podstate potrebujes udelat dynamic_cast.

[----]

takové hluboké error struktury by vůbec neměly existovat... celkem mi to připomíná cargo cult programming.

[:::]

takové hluboké error struktury by vůbec neměly existovat...

- neobhajitelny dogma

abysme se nebavili jenom abstraktne, tak dam konkretni priklad. Pises recursive-descend parser. Jak to udelas bez nekolika vnorenych volani?

A predesilam ze reseni kde je 3x vic kodu a celkove 10x vyssi komplexita nepovazuju za dobry reseni...

[----]

pár recursive-descent parserů jsem psal (v Cčku a pak v higher level jazycích, kde už ale mám k dispozici pořádný error handling) a použiju setjmp/longjmp, C++ exceptions na to nepotřebuju (a natahat si s tím do knihovny spoustu runtime bloatu).

[:::]

je pravda ze vyjimky ti pridaji bloat do binarky.

Jiny zpusoby obsluhy chyb ti ale zase pridaji bloat do zdrojaku.

Ja osobne jsem radsi kdyz to zustane v binarce a zdrojak je co nejcistsi...

a pak v higher level jazycích, kde už ale mám k dispozici pořádný error handling

Co je timhle mysleno? Docela by me zajimalo jestli existujou dalsi zpusoby pro error handling krome error kodu a exceptions. Ted me zadny nenapadaj...

[----]

myslím tím pořádnou podporu pro exceptions, resp. nějaký ekvivalent (try-catch bloky mi nevyhovují, daleko lepší mi přijdou třeba protected function calls v Lua, protože místo zbytečné syntaxe využívají pořádně closures) ... v C++ je to peklo kvůli interakci s exception-unsafe knihovnami a pak taky věcem popsaným třeba tady: http://yosefk.com/c++fqa/exceptions.html

a jiné způsoby error handlingu samozřejmě existují - třeba jazyky s podporou pro option types a pattern matchingem.

[:::]

je to peklo kvůli interakci s exception-unsafe knihovnami

tohle vadi jenom pokud ta knihovna vola nejaky tvuj callback.

a pak taky věcem popsaným třeba tady: http://yosefk.com/c++fqa/exceptions.html

To ze bys nemel volat vyjimky z konstruktoru/destruktoru povazuju jenom za drobnost na kterou je potreba si dat pozor. Asi bych to nenazval peklo

třeba jazyky s podporou pro option types a pattern matchingem

to jsou v podstate variace na error kody ne?

[kralyk z abclinuxu]

Proč bys neměl házet výjimky z konstruktoru? To klidně můžeš.

[:::]

muzes, jenom je potreba pri tom byt trochu opatrnej, protoze po vyvolani vyjimky z konstruktoru uz se nezavola destruktor.

[kralyk z abclinuxu]

To se sice nezavola, ale deinicializace memberů by imho proběhnout měla, takže když si třeba držíš paměť v nějakých memeber smart pointerech apod., tak ta by se imho měla uvolnit bez problému i při throw z konstruktoru.

[little.owl]

v nějakých memeber smart pointerech

Plna konstrukce memberu neni garantovana, nemuze.

[:::]

tak se zavolaji destruktory jenom pro ty membery ktery se stihly uplne zkonstuhovat

[little.owl]

A jen pokud to ma exception handler.

[Sten]

Pokud to nemá exception handler, tak se zavolá std::terminate, kam si můžete pověsit svůj handler, pokud potřebujete uklízet nějaké sdílené zdroje (všechny nesdílené zdroje uklidí operační systém)

[kralyk z abclinuxu]

Plna konstrukce memberu neni garantovana, nemuze.

Kde? V těle konstruktoru jo.

[Sten]

Zavolají se destruktory všem členům a předkům, kteří byli inicializováni. Neinicializovaní členové a předci destruováni nejsou, ale ti nemohli zabrat žádné zdroje, protože ještě nebyl volán jejich konstruktor.

[Jardík]

U konstructoru pomůže function-level try block, nebo jak se tomu nadává:

class bla
{
  bla()
  try:
    member1(...), member2(...), member3(...)
  {
    // ...
  }
  catch (...)
  {
    // ...
  }
};

[Sten]

Interakce s exception-unsafe knihovnami je chyba těch knihoven (resp. jeho autorů), ne jazyka.

Ten link obsahuje spoustu zavádějících informací, které sepsali nezkušení programátoři, jenž svou neschopnost svádějí na jazyk, a které jen matou začátečníky (vím to, protože jsem byl jedním z nich). Není nic špatného na vyhazování výjimek z konstruktorů (streamy to nedělají, protože byly implementované velmi narychlo, což je i důvod, proč na mnoha místech používají const char* místo std::string a mají naprosto šílený buffering, Boost s tím třeba problémy nemá) a ani z destruktorů, pokud víte, jak na to.

[Martin Mareš]

Co je timhle mysleno? Docela by me zajimalo jestli existujou dalsi zpusoby pro error handling krome error kodu a exceptions. Ted me zadny nenapadaj...

Dá se vymyslet ledacos, dokonce i nad obyčejným Céčkem. Docela zajímavá je třeba transakční sémantika: modifikace globálního stavu se logují a v případě chyby se může podle logu provést rollback. Na používání je to velmi příjemné a při šikovné implementaci to může mít minimální režii: například pokud alokujete paměť primárně z memory poolů, stačí zalogovat počáteční stav poolu.

Před časem jsem si s tím trochu hrál, nabízím (zatím mírně pokusnou) implementaci v LibUCW.

[kralyk z abclinuxu]

U C++ je lepší se vyhýbat exceptions kdykoliv - stojí to za h*vno... třeba parametr -fno-exceptions gcc/clangu s tímto pomůže.

To je možné, ale bez výjimek to imho kolikrát stojí z h***o ještě víc...

[----]

no, aspoň si dovnitř nenataháš spoustu runtime navíc a při interakci s exception-unsafe knihovnami to neleakuje resources...

[kralyk z abclinuxu]

Runtime mě obvykle opravdu netankuje. Ale interakce s knihovanami může být problém, záleží na té které knihovně. Programovat s výjimkama se ale dá spravně (osobně jsem příznivcem RAII) a někdy dokonce i ten boost nemusí být tak strašný zlo Ačkoli naštěstí díky C++11 se většinou obejdu bez něj... Imho to odsuzuješ moc rychle...

[biolog]

Jaký runtime bloat?

Když lokální proměnné potřebují uklízecí kód, programátor v C přidá if() podmínku na návratový kód nebo přidá setjmp a uklidí a zavolá longjmp dál. V C++ to uklízení generuje překladač. Pokud proměnná nemá destruktor, tak jej negeneruje. Kde je kód navíc?

Pokud programátor nepotřebuje hlásit detaily chyby, tak mu stačí int na chybové kódy (vrácené z funkce nebo předané do longjmp) či jediná generická výjimka. A jen pro tu se vygeneruje tipuji 32 bajtů RTTI. (RTTI se generuje i pro třídy s virtuálními funkcemi, ale to je jiná věc). Kde je něco navíc?

Samotný kód pro fungování výjimek je uvnitř C knihovny, která je v paměti tak jako tak.

> při interakci s exception-unsafe knihovnami to neleakuje resources...

To je problém jen když ta knihovna volá váš kód, který hází výjimky. A když volá váš kód, musí říct zda ta vaše funkce funkce smí selhat a jak to ohlásit pokud může. Pokud selháváte a ona na to není naprogramovaná, případně ji selhání hlásíte jinak, tak to pochopitelně bude zlobit, ale to bude u všech způsobů error handlingu.

[----]

Jsou to idioti, kdyby radši mysleli na to, co je důležité...

[Lol Phirae]

Rum?

[----]

třeba!

[frr]

Myslíte tenhle?

[little.owl]

Vidim, ze neblbnu sam.

To potesi.