Názory k článku
Úvahy o Borrow Checkeru pro C++

[KubaV]
Psal jste, ze je lepsi (levnejsi) nez testovani, kdyz chyby ve zprave pameti odhali uz prekladac. Je tvrdim, ze podle me je nejlepsi (a nejlevnejsi), kdyz se na zpravu pameti mysli uz od zacatku, behem celeho procesu vyvoje a rozhodne se nespoleha jen na techniky prekladace. Jinak receno, i kdyby byl nakrasne borrow checker v kompilatoru implementovan, rozhodne bych radne testovani uniku a chyb pameti nepodcenoval.

A co mi na tom vadi? Obecne - kdyz se na to ptate, vadi mi hned nekolik veci:

Jedna je, ze posledni dobou mi prijde, ze Rust fans se snazi vschno ohybat podle svych modelu a predstav a ty vsem potom vnucovat. Skoro to pripomina nabozensky tazeni: Stare svatyne rozvratit, vypalit, pozabijet kneze a upalit, ty kteri nehodlaji konvertovat. A na dobitem spalenisti pak postavit svuj vlastni kostel....

Druha vec - jak jsem psal vyse - nechci nekompatibilni zmeny ve standardech. Pracuji s C++ protoze ho mam rad takovy jaky je, a jsem velmi vdecny tvurcum C++ standardu, ze mysli na jejich plnou zpetnou kompatibilitu. A byl bych rad, aby to tak zustalo. Kdybych chtel neco jinyho, budu se venovat tomu.

Myslim, ze jsem toleratni v tom smyslu, ze necham na zvazeni kazdeho, co je pro nej a jeho projekt dobre. At laskave tohle pravo dopreji ostatni i dalsim, vcetne me a prestanou nam vnucovat co je "lepsi".

25. 9. 2021, 23:08 editováno autorem komentáře

[KubaV]
Klidne at se technologie vyvijeji, ale at se nestvou do kam je nikdo nezve. Nekteri lide, maji totiz neodbytny pocit, ze oni maji tu jedinou spravnou technologii a musi ji necpat kazdymu - at uz o to stoji ci ne.

A ano, samozrejme ze to beru hodne osobne. Vlastne zacinam byt na takove lidi dost alergicky a zacina mi byt z nich zle. A to neni jen Rust.

[KubaV]
Jiste, typicke. Pokus s Vami clovek nekejve jak osel, tak je zraly na cvokhaus. Proste sektari : krasne opisujete vzor ktery jsem popsal - ty co nemini konvertovat je potreba upalit. ;)

26. 9. 2021, 21:39 editováno autorem komentáře

[KubaV]
Ale ja nemam nic proti vyvoji IT. Kdyz uz jsi tak skvele cetl ten muj prispevek, divim se ze muzes takovou hloupost vypustit z klavesnice. Me vadi neustale vmesovani a vnucovani nejruznejsi techno-it nadsencu - zde zrovna rust fans - tam kde o to nikdo nestoji a jejich temer sektarsky postoj.

To se dá snadno ignorovat. Na druhou stranu není na škodu trochu se s novými jazyky (Swift, Go, Rust, ...) seznámit. Člověk nemusí hned měnit kariéru, jednoduše to rozšíří rozhled a někdy v (blízké) budoucnosti se to může hodit.

Mně takhle okolo roku 2000 vnucovali Javu. Dlouho jsem odolával, a pak jsem najednou musel psát něco pro Lotus Notes, kde byla na výběr Java a LotusScript (přejmenovaný Visual Basic). A už byla motivace.

[Calculon]
"Na druhou stranu není na škodu trochu se s novými jazyky (Swift, Go, Rust, ...) seznámit..."

Jo, proti tomu samozrejme nic nenamitam. Ja to mel podobne s C# .

26. 9. 2021, 23:11 editováno autorem komentáře

Jenže tady je právě zve. Jsou to vývojáři Chromu, co se zajímají o Rust, ne, že by se Rusťáci rozhodli se za každou cenu zmocnit Chromu.

[klokan]
Ano, to je pravda, nejak to v toku vzajemnych dojmu, uvach nazoru a protinazoru zaniklo. Ale zas na druhou stranu, ...

Na druhou stranu co? Jestli vám tolik sejde na tom, že prohlížeč musí být jedině v C++, tak si ho forkněte a dál si ho vyvíjejte podle svého. Máte na to právo. Upstream vývojářům připadá, že by chtěli se nemuset stále dokola zabývat jistými problémy a hledají na to řešení. Třeba se vám to nelíbí, třeba byste chtěl, aby dál ztráceli čas debugováním pádů a záplatováním zbytečných bezpečnostních děr, ale jenom vám pro radost to dělat nebudou.

Ten clanok sa ale zaobera tym ci by bolo mozne do C++ implementovat BC tak ako to ma rust. Mate nejaky odkaz kde sa pise ze cely projekt prepisu do rustu? Myslim ze ziadny fork nebude treba...

Pokud vím, přepisování Chromu do Rustu nikdo nechystá, ale když někomu vadí, že schopnosti statické analýzy se od 80. let poněkud posunuly a že to někdo chce nedej bože i používat, tak takový člověk bude asi nešťastný i z takovéhoto článku - a zřejmě taky je, soudě dle příspěvků.

Takze ako oznacit vas vyrok, citujem: Jestli vám tolik sejde na tom, že prohlížeč musí být jedině v C++, tak si ho forkněte a dál si ho vyvíjejte podle svého. Máte na to právo. Zavadzanie, nepochopenie, nepozornost? Aky checker zlyhal?

27. 9. 2021, 01:46 editováno autorem komentáře

Nemyslel jsem tím vás, ale jiné příspěvky výše.

Jj, ja si zvesa precitam aj prispevky vyssie aby som sa dostal do kontextu. Ono je to celkom dobrym zvykom sa spytat pri zapojeni do diskusie o com sa toci, alebo si moze jednoducho precitat komentare vyssie. Moze sa potom vyjadrit k veci.

Kontext vasej poznamky mi v suvislosti jak so spravickou, tak s diskusiou stale akosi unika...

[klokan]
Kde jsem presne napsal neco o tom, ze mam problem s tim ze prevedou ten zatracenej prolizet do jinyho jazyka? Umis doprcic cist? Celou dobu sakra pisu, ze by mi vadili pripadne zpetne nekomptibilni zmeny ve standardech jazyka C++. O tom co maji nebo nemaji delat vyvojari v Google se s svym projektem jsem ani nepiskl. V podstate me to ani nezajima.

A ta narazka "na duhou stranu" mela znamenat, ze to ze se tahle (a dalsi) diskuze takhle zvrtne si tak trochu muzou rust hateri sami. Trebaze v tom tentokrat byli aspon ze zacatku nevinne.

28. 9. 2021, 17:50 editováno autorem komentáře

Ono jde asi hlavně o zpětnou kompatibilitu. Nikdo skutečně nechce zažít situaci, že se aktualizuje překladač a najednou program nefunguje a musí se radikálně překopávat. Obětování zpětné kompatibility a nasazení nových konceptů do překladače před pár lety zkusili v Mozille, vydali to a nazvali to Rust :)

Mě naopak připadá, že C++ zkompiluje absolutně cokoli a pak to (většinou) dělá psí kusy při běhu.

Před lety jsem dělal v R&D v jisté velké, známé firmě, na statickém analyzátoru kódu pro C/C++ - něco jako Coverity, Fortify apod, ale byl to interní projekt určený pro vývojáře produktů té firmy. Doba strávená vývojem algoritmů na analyzování C++ programů mě naučila, že kód v C++ (psaný čistě, striktně v "moderním" C++ atd) může být podělaný způsobem, jaký bych si v živote vůbec nebyl dokázal představit. Zároveň mě to dovedlo k dojmu, že C++ je v podstatě nespasitelné - jakékoli vylepšení umožní se některým problémům lépe vyhýbat, ale ne je vyřešit. Nakonec totéž tvrdí i známý článek "Modern C++ Won't Save Us".

C je jiná story. Má sice řadu vlastností, které se zpětně ukázaly jako špatné (preprocesor, řetězce zakončené nulou...), ale je nutné si uvědomit, že jeho vznik byl podřízený dvěma cílům: aby bylo efektivní na architektuře PDP-11, a aby bylo snadné pro něj napsat překladač. Připadá mi, že dodnes má smysl, mj. protože je snadné vidět "zkrz" kód v C a představit si, co to generuje v assembleru. V některých případech je to důležité a nedocenitelné. V Rustu to alespoň já tak dobře nedokážu, je to přece jenom mnohem abstraktnější jazyk. Což je někdy obrovská výhoda a jindy zase nevýhoda.

C++ je skutečně občas zákeřné. Mně sice většinou stačí něco s GC, ale když jsou požadavky přísnější, tak taky radši upřednostním Rust, na C++ už nemám nervy.

V mnoha případech je GC jazyk správnou volbou, ale pak jsou situace, kde GC použít nelze (RT problémy, low-level systémové programování atd) a tam dostává slovo Rust.

[Calculon]
"GC to řeší. Jakmile se v tom někdo hrabe už v době návrhu, dopadne to jako původní MSIE blahé paměti."

Jako jo, uznavam, ze vzit se to da za spatny konec vzdycky, ale nedelal bych z toho uplne ... jak to rict ... pravidlo?

IMHO ve velké aplikaci správa paměti moc plánovat nejde, je to prostě chaos (byť deterministický). Pomůže buď kvalitní tracing GC, nebo překladač, který si to ohlídá (v C++ move a případně chytré pointry).

Přesně tak to funguje. Jen se vylévá automaticky.

ondra05: GC ale funguje jinak. GC nedělá to, že by paměť nechávalo unikat a pak se ji pokoušelo sbírat. GC automaticky sleduje paměť, která se přestává používat. Mimochodem, i s GC jde vyrobit únik paměti – kdyby to byl automaticky vylévaný kbelík, při vylití by se ten únik odstranil.

Každá metafora kulhá. Kolega nejspíš narážel na fakt, že v případě tracing GC zůstává v paměti spousta nedosažitelných objektů, které se jednou za čas odstraní a tím “zbytečně” zabranou paměť uvolní. To je to “vylití”. Dosažitelné objekty ve kbelíku nejsou.

Jednak jsou různé typy GC. Jednak ta metafora kulhá především v přirovnání k netěsnícímu potrubí. Netěsnící potrubí je závada, nevíte kde netěsní, situace se často v průběhu času zhoršuje. GC je naproti tomu řízený proces.

Jo, a taky kulhá tím, že ne všechny GC jsou tracing, třeba RC žádný kbelík nemá, odpad leje přímo do kanálu. Prostě kulhá na všechny nohy…

RC je GC přímo z definice, je to prostě jedna z variant. Má spoustu podvariant, klidně to může dělat překladač transparentně. Taky existuje distribuované RC (pro vzdálené objekty přes síť), představivosti se meze nekladou.

A pravidelne vylevani kybliku neni rizene ? :D

Me vsak fascinuje jina vec: Zrovna v C++ podpora GC se nezahrnuje v prubehu navrhu projektu? Chytre ukazatele take ne?

26. 9. 2021, 21:03 editováno autorem komentáře

Samozřejmě jsem myslel nezkompiluje

Jsem osobně všemi deseti pro ruční správu paměti, když překladač zajistí bezpečnost, ale zrovna Rust má ten problém, že jakmile jsou v aplikaci složité hierarchie objektů na haldě, je alokace pomalá a musí se ladit konfigurace (alokátor). Na to jsem narazil u všech netriviálních projektů a samotný překladač Rustu je taky “potuněný”.

Nicméně na proškolení namyšlených javistů je Rust ideální (kolega tomu říká “buzerace překladačem”).

[klokan]
" Nevím, co tím autor doopravdy myslel, pravděpodobně ono klišé "Rewrite It In Rust"."

Ja to pochopil uplne stejne.

Pokud o vtip byla i moje interpretace :) Co tak občas pozoruju, mnohé týmy následují heslo “rewrite it first in Go, then in Rust”…

Tak s tím jsem se ještě nesetkal, za to jsem už párkrát viděl Rewrite it in C++, then in C++, then in C++, then in Rust.

Taky dobrý :) Tu trajektorii Go->Rust zvolil například následník node.js, tuším se jmenuje Deno.

Zajímavý. Psát interpret v Go by mě teda nikdy nenapadlo.

To asi nebyl interpret, pro JS používají V8, ale celá ta síťová vrstva byla nejdříve v C (node.js) a pak ji přepsali do Go (beta verze Deno). Jenže někdo si pak všimnul, že najednou tam mají dva tracing GC (JS a Go), tak ten kód v Go přepsali do Rustu.

No jasně, že přepsat do Rustu. Dnes existuje dogma, že napsat znovu browser je nemožné, což mi přijde jako dost bídná situace. Každopádně, kdyby se něco podobného Google odvážil udělat, rozhodně mi přijde lepší napsat to přímo v Rustu, než dělat z C++ Rust. A fakt mě štve, jak se "oxidace" Firefoxu zadrhla, protože jsem doufal, že jim to postupně vyjde.

Napsat nový prohlížeč jistě není nemožné, ale přepsat již existující do jiného jazyka by byla obludná práce, navíc to není samostatný projekt ale integrace několika různých projektů (interpret JS, interpret WASM, vykreslovací jádro HTML, CSS engine, grafický engine, 3D engine, implementace síťových protokolů, podpora všemožných kodeků a formátů atd), kde mnohý z nich je sám o sobě nesmírně komplexní software. Takže přepisovat to nikdo nebude, jako nikdo nebude přepisovat celý kernel Linux.

Z C++ asi Rust neudělají, ale do Swiftu proniká jím inspirovaná statická analýza alokací a referencí na objekty na haldě.

To se naopak porovnává dost snadno, Java prostě provádí bounds checking za běhu úplně stejně, jako třeba std::vector v C++.

K tomu názoru na Javisty: předem se omouvám těm, kterých se to netýká, protože je to samozřejmě klišé, nicméně souhlasím, že Javisti většinou nejsou dobří vývojáři. Ovšem ne proto, že nedělají správu paměti ručně, ale proto, že to jsou patlalové kódu, kteří nerozumí základům počítačové vědy a myslí si, že problémy se instinktivně řeší napsáním dalších řádků namísto důkazu teorému. To mají společné s céčkaři c++kaři, co takzvaně "vědí, co dělají" a žádnou statickou analýzu nepotřebují.

No, vacsina interpetrov, vratane javy ma dynamicke polia. C ma alokovanu pamat a pointer do nej. Buffer overflow v C sa zvedsa prejavi chybou, je mozne zneuzitie. Ale ak pri implementacii bufru v jave programator pouzije dynamicke pole, tak nepretecie, len vam zacne swapovat...

“Buffer overflow v C sa zvedsa prejavi chybou”

Ta vsuvka, že se ti zved, nebyla úplně nutná. Jinak píšeš blbosti, dynamičnost pole nijak nesouvisí s tím, jestli je jazyk interpretovaný. Každé pole se musí, pokud přeroste, přealokovat.

Akurat to musis urobit explicitne, kdezto interpretre to zvedsa robia implicitne.

Nemusíš, v Pascalu, Adě, Rustu i v C++ (myslím tím vector) se pole přealokovávají transparentně tak, že se o to programátor nemusí starat. Samozřejmě že standardní knihovna musí mít rutinu na realokaci nebo ji kompilátor musí generovat, ale totéž platí pro interpretované jazyky, kde musí být součástí interpretu. Explicitně nebo implicitně je to v obou případech stejné.

Nemá smysl se s ním bavit, tenhle exot (dw) je Braindead walker vedle z fóra. Píše neskutečné nesmysly.

njn, o com parta patlalov v ruste rozhodne, cez to vlak nejde. Ako inak :D

No, a toto je presne to co vam ziadny prekladac neodhali, v buffri budu zvedsa binarne data ktore vo vecsine pripadov nebudu mat pevnu strukturu. Takze mate zhruba dve moznosti, bud pouzijete pointer alebo budete tie data z buffra prechadzat byte po byte. To suvisi aj so strukturou kodu, ak to chcete mat ten kod rozdeleny do funkcii tak aby z toho nevznikol spagetak tak budete musiet pouzit pointer na aktualnu poziciu v buffri. Ako vam staticka analyza odhali ze idete mimo buffer, ked staticka analyza pri preklade nemoze vediet, kde sa nachadza v buffri zaciatok struktury ktora funkcia spracovava, kedze tie binarne data nemoze mat k dispozicii. Toto moze osetrit len programator, ak na to mysli. A mysliet by na to mal, miesto toho ze sa bude spolihat na nejaku barlicku ktoru mu ponuka prekladac.

dw: Pro vaši informaci, pole v Javě jsou úplně stejná, jako v C – alokovaná paměť a ukazatel na ni.

A jak už psali ostatní, s interpretovaným nebo kompilovaným jazykem to vůbec nijak nesouvisí. Ostatně můžete mít i interpretované C, na druhou stranu Java se běžně za běhu kompiluje do nativního kódu a dnes už můžete Javu kompilovat do nativního kódu i předem. Takže vlastnosti jazyka nijak nezávisí na tom, zda je kompilovaný nebo interpretovaný – to totiž závisí jenom na tom, zda někdo napsal příslušný interpret nebo kompilátor.

Já jsem tedy za statickou analýzu a borrow checker rád, člověk se aspoň může soustředit na úlohu, aniž by se musel přehnaně věnovat možným bugům z nepozornosti.

Len tie jayky maju jednu spolocnu chybu, ak pouzivaju nejake volania kniznic systemu, tak neovplyvnia ako sa chovaju kniznice ktore boli napisane v C. Ze by koli tomu vsetci opustili C a zacali pisat v ruste? Trocha strasidelna predstava, ze by mal jadro pisat niekto kto si mysli ze chyby za neho odchyta prekladac.

Tak jsou veci ktere jsou tezce viditelne, to jo - treba v pocatcich vyvoje na AVR me kolidoval stack s heapem (asi nejake mensi mcu), protoze to chtelo nastavit heap max v dobe kompilace a malloc zacal nejspis zhora.

Takze jsem si napsal analyzer, kteremu das AVR binarku, udela to disasm, projde vsechna volani a posuvy stacku kvuli lokalnim promennym.. a vypise to worst-case call path a velikost na stacku (promenne + navratove adresy, taky worst case interrupt). Volani pres pointer je nutno specifikovat vyctem co se muze volat - a rekurze chce vedet kolikrat asi se to vnori prinejhorsim (vetsinou to byva zname cislo).

Tohle me krasne pomaha najit magicke cislo, kolik pameti se ma rezervovat pro stack pro dany projekt, a kolik zbejva na dynamicke chovani. Buhvi zda neco takoveho existuje verejne, a last modify na tom svem toolu mam 8.5.2012 ... no dokonalost sama :)

Po programatoroch v ruste alebo v go to nechcite. Po dizasemblovani je to neskutocny hnoj.

No vidíš, a v lepším jazyku by ty chyby odchytil hned kompilátor a měl bys garanci, že tam nejsou.

[klokan]
To je moc rychle generalizovane. Napr. Chyba v window manageru se neprojevovala, jen padem aplikace, ale napriklad spatnym navazovanim poradi oken na sebe. Tzn, ne vzdy doslo k cteni/zapisu do nealokovane pameti, a obavam se ze predikovat by to asi slo blbe - Stak oken byl implementovan jako zretezeny seznam. Jenze byl prasacky napsany.

27. 9. 2021, 00:11 editováno autorem komentáře

No ale vždyť právě o to jde. Je spousta chyb, které se projevují sporadicky, jsou špatně reprodukovatelné, těžko se diagnostikují, ale statická analýza je dokáže odhalit a zařve už při kompilaci tak, že nic prasácky napsaného se přes ni nedostane. Pro uživatele to znamená mnohem bezpečnější a kvalitnější software, pro vývojáře je to obrovská úspora času.

[klokan]

"Je spousta chyb, které se projevují sporadicky, jsou špatně reprodukovatelné, těžko se diagnostikují, ale statická analýza je dokáže odhalit a zařve už při kompilaci tak, že nic prasácky napsaného se přes ni nedostane."

Pritom nejednodusi resenim muze v dane situaci byt, proste na to jit jinak. Jako kdyz nekdo misto toho aby rodelil komplexni problem na nekolik mensich, pruhlednych, dobre testovatelnych jednotek, napise heper-molochoidni tridu, ktera navic jeste hraje poker, vari kafe a ve volnem case pere zaclony (coz byl presne ten hlavni problem vyse zminovaneho prikladu), tak holt to podle toho taky dopadne.

Takze vsechno o cem tu pises je super, ale ze spatneho programatora to zazrakem dobreho neudela, a stejne tak to neudela ze spatneho navrhu, dobry program.

P.S. Jestli by Rust dokazal odhalit chybu - kterou jsem popisoval - uz pri kompilaci, musel by mit v sobe implementovanou vesteckou kouli.

27. 9. 2021, 22:15 editováno autorem komentáře

A jak by to jako v praxi fungovalo? Že si člověk v náhlém momentu jasnozřivosti uvědomí, že tam jsou chyby, které se ještě neprojevily, a půjde na to jinak? Nebo když najednou po vydání stabilní verze začne dostávat hlášky o pádech a chybách, které na první pohled vypadají každá úplně jinak? Není rozumnější mít statickou analýzu, která špatně napsaný kód prostě nepustí dál, a člověka přinutí na to jít jinak hned od začátku?

Proste prekladac ma robit to co mu programator povie, nie to co uzna za vhodne. Ak mu to povedat nevie a ocakava ze to prekladac urobi sam, tak len zbytocne zaberal miesto na skole niekomu kto by nepotreboval barlicky aby jeho kod bol bezpecny.

Co sa tyka chyb, tak casto su pisane zamerne v testoch a tie testy chceme prelozit.

A co sa tyka nepovsimnutych chyb v kode. Ak si tie chyby nevsimente vy, tak to este neznamena ze si ich nebude vsimat niekto iny.

Aha. Až příště poletím letadlem, tak pevně doufám, že autopilot programoval skutečný profesionál a ne čtrnáctiletý patlal, co si musí dokazovat, že je "dobrý programátor" a nějaká formální verifikace je pod jeho důstojnost.

To sa bat nemusite, vedsina systemov v lietadle a hlavne tie kriticke su programovane v ADA. Ale ak aj tam nejake hovado zacne pchat rust, tak sa bude lietat uz len na zeppelinoch...

"Vy jste zkrátka machr, Hlaváčku" :)

Tak například fly-by-wire systém u Airbusu je ve SCADE, což je formální modelovací jazyk, který se pak automaticky kompiluje do podmnožiny C. Pro nějaké tzv. "dobré programátory" tam naštěstí není místo a od té doby, co vinou "dobrého programátora" radioterapeutický přístroj TERAC 25 zabil několik lidí a několik dalších doživotně zmrzačil by tihle rádoby borci měli mít absolutní zákaz programovat byť jenom příkaz "echo".

Mimochodem Rust provádí mnohem hlubší statickou analýzu, než Ada (ta ale naopak má některé runtime kontroly, které Rust neumí). Právě to je jeden z důvodů, proč je tradiční Ada na ústupu a místo ní se teď často používá SPARK, který se ke statické analýze hodí líp.

Rust se tam nepoužívá z jednoho velmi jednoduchého důvodu: neexistuje pro něj certifikovaný překladač. Třeba se časem taky objeví, uvidíme.

SPARK je rozsirenie ADA. Ked pisem o kritickych systemoch, tak tym myslim napr. riadiacu jednotku prudoveho motora. Liedadlo vo vzduchu udrzite ak ma aj hydraulicke riadenie, nemusi mat nutne elektronicke. Kdezto prudovy motor je bez riadiacej jednotky v chode udrzat dost problem.

No, ja som k vedomiu ze c++ je nahovno, nejaky rust nepotreboval(ktory je tiez na hovno, len v inych odtienoch hnedej). Pouzivam jazyk podla toho ktory sa k ulohe viac hodi. Bud C, Adu(ak je nutne tak pocukrovanu sparkom), plpgsql (podmnozina ady), python, nim (tiez je kompilovany cez C), PHP (ako html preprocesor je skvele) a pozeram ked mam cas na eiffel, ten v praxi este nepouzivam...

Kdezto ako citam vas tak rust je usecase na vsetko. Nezavana to tak trocha diletanstvom?

SPARK je částěčně rozšířená ADA ale zároveň částečné omezená, takže spíš je to jiná množina, ale samozřejmě s obrovským průnikem. A u toho letadla je to jak u kterého, Airbus bez elektroniky ve vzduchu neudržíte ani v Direct Law (Boeing jak který...)

Nevím, kde jste sebral, že podle mne je Rust na všechno. Takovou blbost jsem určitě nikde nenapsal, mj. už proto, že sám používám různé jazyky a pro Rust vidím užší nasazení, než mnozí lidé (např. moc nechápu proč programovat WASM aplikace v Rustu, ale přesto to hodně lidí dělá. Třeba k tomu mají nějaký dobrý důvod který já nevidím, to je možné). To, o čem je řeč, je představa, že statická analýza je na hovno protože jsem přece "dobrý programátor". Osobně vidím diletanství právě v tom.

Syntakticka analyza ma zmysel pri jazykoch kde je algoritmus dostatocne detailne deklarovany. Ak ste uz videl nejaky rozsiahlejsi kod v ade tak viete o com hovorim. Ale ani tak nie je zazracny, jedna z utilit gnat toolesetu je specialne pre kontrolu skompilovaneho programu ohladne jeho prace s pamatou.

Co sa tyka dobreho programatora, toho tvoria jeho navyky a predispozicie. Jednoducho nerobi spagety (nezkrizi niekoko algoritmov do jedneho) a zavislosti cez x algoritmov. Ked pracuje s buffrom tak ma mat ten kod napisany tak aby na prvy pohlad videl ci je mozne aby zapisoval mimo alokovanu pamat. Ak alokuje pamat tak ju nema dealokovat na 20 miestach napriec celou aplikaciou.

On ten problem chromu podla mna nebude v C++ ale v ludoch ktori ho programuju a nemaju dobre navyky + ludoch co tych programatorov tlacia k tomu aby kod vydali co najrychlejsie na ukor toho aby bola urobena dobra analyza zadania a aby bol kod dostatocne otestovany. Zmena jazyka by tam neznamenala riesenie priciny ale riesenie dosledku.

“Syntakticka analyza ma zmysel pri jazykoch kde je algoritmus dostatocne detailne deklarovany.”

Aha. Takže jinde syntaktická analýza není? Co tam je místo ní? Víš vůbec, co je syntax? A co na to Jan Tleskač?

28. 9. 2021, 10:34 editováno autorem komentáře

Á, pán je suvenýr...

Lepsie ako byt suteren...

Miesto syntakticka tam malo byt samozrejme staticka. Zamena z mojej nepozornosti. To tvoja genialita mohla odvodit z komentara na ktory som reagoval.

Jistě jste chtěl říct statická analýza, ne "syntaktická analýza" kterou provádí i cmd.exe. Problém je samozřejmě v lidech, resp. v tom, že v projektu o desítkách MLoC na kterém pracuje mnoho různých týmů (ani ne jednotlivců, ale rovnou týmů - V8, Blink atd...) je lidsky absolutně vyloučené neudělat chybu. Kde se sakra odalokovává objekt xyz? Kdo k němu má přístup v který moment? Atd...

Takže představa, že se to vyřeší "lepšími návyky" a lepším testováním je prostě naivní. Ono totiž programovat takový projekt není totéž, co programovat hobby program o 20 KLoC jenom trochu větší, je to kvalitativně i koncepčně naprosto odlišný problém. Kdybyste měl pravdu, tak by na to u toho Googlu, Microsoftu apod. byli přišli taky a ty "lepší návyky" jim mohly ušetřit 70% zranitelností.

Co naopak může pomoct je automatizace těch "lepších návyků" tak, aby se chybný kód přes ni prostě nedostal, a samozřejmě nejefektivnější to je, když je to součást samotné definice jazyka. On ten Hoare v Mozille taky nebyl žádný idiot a dobře věděl, proč začal vyvíjet Rust.

"Rust se tam nepoužívá z jednoho velmi jednoduchého důvodu: neexistuje pro něj certifikovaný překladač."

To je hudba budoucnosti, ale jednou k tomu snad dojde.

[klokan]
Ale ja nic takoveho sakra nepisu! Ty porad nechapes ze slo o jeden z prikladu z praxe, kdy dusledkem blbeho pristupu programtora doslo k chybnemu fungovani procesu, jehoz jednim z dusledku bylo, ze za urcite vicemene nahodne kombinace udalosti dochazelo k chybnym vystupum a mohl vest dokonce i k padu cele aplikace. A takovou behovou chybu ti zadna staticka analyza proste neodhali. A diky prave tomu pristupu meho predchudce bylo nejschudnejsim resenim pak cely ten zatraceny stack prepsat.

Jedine, co se snazim celou dobu rict je, ze bezpecne aplikace lze v psat i v C++. Nerikam nikde, ze existuji zazracne postupy jak se vyhnout chybam. Neexistuji a taky si uvedomuji, ze existuje vic druhu chyb, nez jen uniky pameti, nebo chybny pristup do pameti. Ale rikam, ze to, jak rychly a jak moc komplikovany bude cely proces jejich odhalovani, zalezi na pristupu k navrhu a implementaci, bez ohledu na pouzity jazyk. Kdyz pustis kompilator spatne navrzenou aplikaci a prasacky implementovany kod je uz davno pozde! To uz davno neni - jak pises 'od zacatku'...

28. 9. 2021, 10:47 editováno autorem komentáře

Oni v svojom stadovitom chovani nechapu ze mi dvaja nie sme z jedneho stada a akosi sa im nase komentare evidentne zlievaju do kopy...

[dw]
Myslim, ze je soudis moc rychle. Ac s nimi nesouhlasim, tak je na druhou stranu i chapu.

Určité situace s chybnými výstupy vlivem chyb v kódu statická analýza odhalí, na př. v tom Rustu (když už je o něm řeč) jsou vyloučené velmi běžné typy race condition. Ano, bezpečný kód lze psát i v C++, stejně jako ho lze psát i v assembleru. Problém je, že u netriviálních projektů z toho vyplývají exponenciální komplikace a náklady, nemluvně o tom, že čím větší projekt, tím větší jistota, že kód v C++ bezpečný prostě nebude. Proto je cíl nasazovat automatickou analýzu a jazyky, které ji mají přímo v definici. Cílem totiž zůstává mít kvalitnější software, ne svět přizpůsobit tak, aby se fanboyové C++ necítili dotčeni.

To je ideál. Tak schválně, kdo se mu nejvíc přiblíží.

Proč schválně? Není třeba čekat, fakta jsou k dispozici už dávno. Mezi reálně použitelnými a používanými jazyky to je nejspíš Haskell a v mainstreamu Rust.

To je současná situace. V horizontu řekněme deseti let může dojít ke změnám.

Určitě k nim dojde, to je podstata technologického pokroku. Stoprocentně jisté je jenom to, že l33t r34L pr0gr4mm3rZ v C/C++ to "to umí" za pravdu nedostanou.

Je to i jazykem.

Kdyz jazyk neumozni pad, tak se pad neudeje. Nekdo psal, ze std::vector je bezpecny a s tim se da souhlasit.
Kdyby se pro pole prestali uzivat raw pointery, tak nemame zneuzitelny buffer overflow.

Kdyby jazyk znemoznil jine sdileni dat mezi vlakny krome future/promise, tak by razem temer zmizli race conditions.

Pak je otazka, jestli to ma dostatecnou expresivni silu a bezi to dost rychle. Kdyz ne, tak treba zustat u starych problemu.

Cim viac obmedzeni, tym nizsia flexibilita. Naviac obmedzenia pri preklade ktore nemozu mat vplyv na uz prelozene linkovane kniznice je k nicomu.

Ale hadam sa potvrdi myslienkovy experiment pana Borela. Posadime ku klavesnice opicu ktora ked bude do klavesnice busit dostatocne dlhu dobu tak napise umelecke dielo a aby sme to urychlili tak tam dame filtre...

No vida, to s tím suckless jsem nevěděl. Musím mrknout.

Jenomže tohle mi vždycky připadalo jako neskutečná hovadina. Worse je prostě worse.Vyvíjet kvalitní software je samozřejmě složitější a náročnější, než vyvíjet blbé software a pak tvrdit, že blbé je ale vlastně dobré.

Komplexnost a chyby rostou exponenciálně, takže 57x větší kód je prostě astronomický rozdíl. Na jpeg-LS a spol samozřejmě existují knihovny taky.

Knihovny vam jsou k nicemu, kdyz bude casem plan to posunout na GPU nebo FPGA - seznamit se s problemem je potreba tak jako tak.

A zrovna to lossless je otazka na par radku: prediktor + huffman. Neni nad to, si implementovat standard z pocatku devadesatek... tech par dekad tomu hodne pomaha a ve svete dnesnich kodeku to je zcela primitivni :)

Btw me jde o Lossless JPEG profil z ITU T.81 (puvodni JPEG standard, 1993) .. nekdy oznacovan jako LJ92 a neni to to same jako JPEG-LS (ITU T.87) - ktery se prakticky neuchytil/nepouziva (na ktery jste zrejme odkazoval/nasel vy).

Špatně není operátor [], špatně je, že po move je proměnná v stále přístupná a lze s ní operovat. V rustu by se stejný kód nezkompiloval (natož aby prostě padal).

A "vo tom to je". unique_ptr v C++ vůbec nemusí být jediný, resp. neexistuje způsob, jak to zajistit. Jakýkoli objekt se může zničit, když na něj ještě jsou reference (&), které pak vyvolají segfault. U vectoru je nutné ručně vybírat mezi morem a cholerou ([] nebo .at()), protože překladač nedokáže sám odvodit, kdy je bounds check nutný a kdy ne. Sémantika move constructoru je naprosto neuvěřitelná. Tzv. koncepty z C++20 nezaručují prostě vůbec nic (není nejmenší problém v šabloně volat metodu, která v konceptu není deklarovaná). Atakdále. Zkrátka tyhle "bezpečné" featury z C++ post-11 jsou jen o málo lepši, než si tam dát prostě komentář

// od teďka na v nesahat

Z hlediska statické prokazatelnosti je to zhruba na té samé úrovni.

No v Rustu máte například explicitní move - teda sorry, nemáte, záleží na atributech objektu, které se přesouvají, jiné se kopírují. Z kódu lokálně jasně není vidět, co nastane. Takže jsem radši za std::move.

To že po std::move se proměnná neoznačí jako nepřístupnou jsem psal.

Překladač nemůže odvodit zda je nebo není bound checking, pokud nemá k dispozici celý kód například pokud voláte knihovnu. Pokud ručně kontrolujete rozsahy a kód je přístupný a následně se během optimalizace zjistí, že se podmínky vždy vyhodnotí false, tak pak tu kontrolu rozsahu se z toho odebere a není tam.

Proč operator[] nemá kontrolu rozsahů netuším, je to nějaké designové rozhodnutí. Protože stejně jako na tom chrome, i na tom C++ pracuje mnoho tvůrců a každý má jiný pohled na svět. Takových divných designerských rozhodnutí najdete i v Rustu, například rozhodutí nepoužívat výjimky a následně zavést operátor? Ale určitě se do roztrhání těla budete být za svojí víru. Prostě to berte jako fakt. Lze si napsat vlastní verktor, který tam tu kontrolu má (nebo ho podědit) a jste safe

Koncepty v C++20 - bod pro vás, že jste to studoval. Opět si myslím, že je to designerské rozhodnutí, volba mezi komplikovaným překladem a deklarací ve které když něco deklaruju a pak to nedodržím, tak je to samozřejmě můj problém.

O žádnou víru se nejedná, kdysi jsem se taky bil do roztrhání těla za "svůj" jazyk, dneska si troufám říct, že jsem zmoudřel. Mezi výjimkami a operátorem ? v Rustu je zásadní rozdíl a osobně v tom vidím výhody i nevýhody, nepatřím k těm, kteří výjimky apriori zatracují (i když zrovna ty v C++...)

Problém je v tom, že když něco nedodržíte, tak to není váš problém. Jakmile se dostanete do řádu desítek MLoC tak zaprvé je absolutně nemožné si to pamatovat, především ale to pak není váš problém, ale problém toho, kdo se bude snažit o několik let později implementovat nějakou úplně jinou featuru a od vašeho modulu bude mít k dispozici v nejlepším případě dokumentaci API. Ten pak bude mlátit hlavou o zeď, proč něco segfaultuje. Jistěže si můžete implementovat vlastní vector (ale on bude mít zase svůj vlastní vector, který bude stejně zabugovaný, jako ten váš, jenom jinak). Nebo si klidně můžete implementovat vlastní programovací jazyk. Na problému se tím nic nemění.

A víte jak se pozná dobrý a špatný programátor

Dobrý programátor má pravidla, jak má vypada dobře napsaný program. Špatný programátor spoléhá na překladač, že mu ukáže chyby.

CO je nějaký segfault proti tomu, že mne robot zlikvidoval na burze pozici, protože jsem v jeho kódu sčítal nějakou proměnnou dvakrát a ne jednou. Sakra, že mne na to překladač neupozornil....?

Ano, celé poselství je v tom, že když si něco deklaruju a pak to nedodržuju, mohu se těšit na budoucí problémy. Pokud to ale dodržuju, problémům se vyhnu. Je to tak těžky to dodržovat? Ušetříte práci nejen sobě, ale budoucím generacím.

Já to vidím spíš tak, že dobrý programátor je schopen provést důkaz. Špatný programátor tvrdí, že je dobrý programátor a důkaz nepotřebuje. O tom, že problémům se s tímhle nevyhnete svědčí mj. i ta zmiňovaná data od Googlu.

Nějak se ta diskuse zvrtla. Jen k tomu unique_ptr, o konzistenci C++ svědčí už jen fakt, že jej sice zavedli do C+11, ale zapomněli na make_unique. To dopsali až pro C++14. To jen tak pro ilustraci. S každou verzí je C++ větší bordel. Doufám, že Rust nikdy nezmolochovatí.

V rustu nezavedli výjimky

A když zjistili, že se strašně blbě pracuje s chybama, zavedli operátor ?. který je syntaktickou zkratkou na to vyhodit chybu z fukce pokud volaná funkce vyhodila chybu.

Což je zhruba úplně totéž, co dělají výjimky.

Takže už je na dobré cestě.

jen tak mimochodem std::make_unique vlastně není potřeba. Stačí napsat do konstruktoru std::unique_ptr obyčejné new. Ale jo, není to hezké, právě třeba pro automatické code review. Máš v programu new? No buď máš k tomu nějaký fakt dobrý důvod, nebo tam nemá co dělat...

27. 9. 2021, 10:20 editováno autorem komentáře

Zajímavý názor, že vrácení chyby přes ? je ekvivalentní výjimkám. Dobrý argument pro nekonečné diskuse o vracení/házení chyb/výjimek.

"Zajímavý názor" je v tomto případě zajímavý eufemismus.

Náhodou má do určité míry pravdu, že ? v Rustu v podstatě emuluje stack unwinding. Akorát návratový typ je explicitně Result (což je IMHO lepší, nekomplikuje to syntax jako try-catch). Go mělo podobnou konstrukci, ale návrh neprošel schvalováním (místo ? na konci psali try na začátku, jinak to bylo na chlup stejné).

Ono to teda není ekvivalentní vůbec, ale budiž ;)

Ekvivalence je silné slovo, ale oboje umožňuje probublání chyby po zásobníku napříč funkcemi, dokud ji někdo neošetří. Že se liší implementace je uživatelům celkem jedno.

Jenže v C++ lze výjimku odchytávat kdekoli, nejen na hranici funkce, kde byla vyhozena. Kromě toho (pokud se něco nezměnilo, co mi uniklo), nemá C++ checked exceptions. Výjimka v C++ je neřízená střela, kterou někdo někde vypálí a když vše dobře dopadne, někdo další ji zachytí na tom správném místě.

Result v Rustu je normální výraz, který musí programátor v každém bodě zpracovat a to, že existují zkratky typu ? a unwrap(), na této situaci nic nemění. I to ? pořád zachovává nutnost deklarovat typ Resultu a při další propagaci s ním řádně zacházet.

Odchycení výjimky "kdekoliv" je v Rustu kontrola chybové hodnoty místo použití ?, na tom není nic divného.

Unwrap je fuj :) Otazník je naopak fajn. Result je taky fajn, je to lepší než psát explicitní "throws" a podobné divnosti, které činí syntax složitější (Java v tomto exceluje).

Ano, odchytit výjimku "kdekoli" v rámci funkce lze zpracováním větve Err, ale nelze pomocí ? prostřelit ten Err skrze několik návratů funkce najednou. Ta zkratka je prostě IMO hodně nepřesná.

Jasně, unwrap() je fuj, ale je to explicitní a jasně definované fuj, které se snadno dohledá a kdykoli vyřeší.

Jedno to není ani náhodou. Výjimka je stack unwind, ? je normální návrat z funkce ovšem se speciální hodnotou. V praxi to má dost dalekosáhlé důsledky.

Výhoda výjimek:

Chyby se propagují vlastní cestou mimo normální control flow. Po návratu z funkce ? vyžaduje další podmíněný skok, což v extrémním případě může mít dopad na výkon. Naopak výjimky zase vyžadují náročnější správu zásobníku, co je horší záleží na okolnostech.

Výhoda Result/?:

Výsledek (ať už skutečný, nebo chyba) je hodnota, jako každá jiná, a jako s takovou se s ní dá pracovat. Například můžete paralelně spustit N operací, z nichž každá vrací Result přes ?, výsledky dávat do pole a pak vidět, které uspěly a které ne. Můžete vracet chyby a odchytávat je v jiném vlákně (výjimky napříč vlákny je přímo kapitola...). Samotné chyby jsou pod kontrolou typového systému a borrow checkeru.

Výhoda výjimek:

Ne všechny chyby se dají doopravdy napravit, zvlášť ne lokálně v kódu, Někdy je prostě nutné jenom konstatovat, že nastal průs...r, případně něco uzavřít nebo ukončit a hotovo, a to se děje někde na úrovni N+M v call stacku. S výjimkami je to podstatně snažší, navíc možná méně svádějí ke zneužití. U Result a ? je riziko, že někdo bude chtít psát "chytrý" kód, např. jsem už viděl, že někdo Result "chytře" propagoval směrem dolů jako argumenty volaných funkcí....

Výhoda Result/?:

Když nějaká rutina nebo metoda v nově verzi začne vracet nové chyby, které dřív nebyly, automaticky se to stane součástí její API a kompiler nedovolí je ignorovat.

27. 9. 2021, 11:36 editováno autorem komentáře

Třetí možnost je setjmp/longjmp :) (zdraví původní Objective-C)

Nedám na to ruku do ohně, ale mám pocit, že setjmp/longjmp mělo i staré C K&R, dávno před Objective-C. Ale něco velmi podobného má dokonce i Rust (panic!/catch_un­wind).

Jasně, to je z Céčka, ale v ObjC to použili k implementaci výjimek (přes makra).

Jo, kdysi jsem si pomocí setjmp a longjmp taky ubastlil #define TRY..., #define CATCH.... a #define THROW.... Dokonce to i více méně fungovalo.

V ObjC to fungovalo někdy méně :)

Tak to mě samozřejmě taky, teprve po delší době mi došlo, že u rekurzivních funkcí se mi s tím děly zajímavé věci... :D

V ObjC bylo NS_DURING/NS_HAN­DLER (try/catch) a problém by s returnem z "try" bloku (tj. mezi těmito dvěma makry). Proto zavedli další makra pro návraty (např. NS_VALUERETURN). Žádná krása, ale co by člověk chtěl od starého C s OO preprocesorem...

Tohle se intenzivně používá v Postgresu.

https://github.com/postgres/postgres/blob/master/src/include/utils/elog.h

Ono to je vůbec poměrně rozšířené, v holém C to ani jinak nejde.

Když nějaká rutina nebo metoda v nově verzi začne vracet nové chyby, které dřív nebyly, automaticky se to stane součástí její API a kompiler nedovolí je ignorovat.

Než někdo použije anyhow::Result nebo něco podobného.

klokan:

Jste krásně popsal výjimky jak jsou implementované TEĎ. Ale pletete si implementaci s jazykovou konstrukcí.

Například kdybych psal C++ wrapper do Rustu, budu na základní úrovni výjmky odchytávat a vracet je jako chybový result. A obráceně, pokud bych psal C++ wrapper na Rust, budu chybové resulty vyhazovat jako výjimku.

Nevím jestli je v normě psáno explicitně, že zpracování výjimky má jít jinou cestou. Hmm, podle mě nemusí, ale to je jedno. Každopádně to vaše fuj stack unwind je úplně na stejné úrovní jako

if (chyba) return chyba

uprostřed funkce. I tady se musí zahodit vše, co funkce doposud vytvořila a uložila na zásobník.

Samozřejmě, když TOMU ČLOVĚK NEROZUMÍ, tak se do toho zamotá, protože výjimky často chodí přes operační systém. I když by nemusely, tak chodí. Nevím proč, možná pro lepší kontrolu, nebo možnost odchytávat výjimky i z kódu, který není C++ kompatibilní, nebo když vyhodím výjimku v C++ a neodchytne ji nikdo až nějaká ne C++ funkce, která původně C++ funkci volala. Asi nějaký takový důvod to má. Bez operačního systému by šlo implementovat výjimky stejně jako v Rust, akorát by to bylo transparentní a programátor by nic nepoznal.

Takových wrapperů na výjimky je třeba v knihovnách Microsoftu plno. Že by to byla nějaká nádhera se říct nedá.

make_unique je treba.

Najdete bugy v nasledujicim kodu
do_something(std::u­nique_ptr(new A()), std::unique_ptr(new B()));