Rust vzniknul přesně ze stejného důvodu, protože v mozille došly k podobným závěrům. Testování by to mohlo vyřešit, ale není obecně lepší a hlavně levnější problém zjistit co nejdříve? Místo testování ho poznat už při překladu? Ale souhlas, že roubovat tohle do C++ je nesmysl. Zpětná kompatibilita je u jakékoliv technologie zásadní věc. Věřím, že pokud to bude výhodné, tak nové projekty prostě vzniknou v Rustu a staré dožijí v C nebo C++.
[KubaV]
Ja se domnivam, ze jeste lepsi je, myslet na zpravu pameti uz pri navrhu, protoze muzete mit napsanou aplikaci v cem chcete, pokud toto zanedbate (obvzlast pri molochovitych projektech, jakym rendrovaci jadro webbrowseru dneska bezpochyby je), driv ci pozdeji Vas to dohoni a bude to delat potize a stat nejake naklady navic tak jako tak. A testovani by melo byt posledni instanci, ktera to zachyti pred finalnim vydanim, a melo by se jim v kazdem pripade projit - neverim tomu, ze kompilator bude schopen zachytit vsechno.
Pokud si v Google (nebo kdokoliv jiny) vsak mysli, ze to vyresi zmena jazyka z C++ na Rust, Go, C#, ci kterykoliv jiny, nebudu jim to v zadnem pripade vyvracet.
Jedine o co mi jde, at nechaji na pokoji standardy C++. Nechci se dozit toho, ze budu vyvijet v C++ a pak najednou zjistim, ze v podstate delam v Rustu. To je v podstate vse.
25. 9. 2021, 21:04 editováno autorem komentáře
Nevidím rozpor v dobré práci programátora a lepších kontrolách kompilátoru. Nikdo přece netvrdí, že rust vyřeší všechny problémy. Nebo jak konkrétně vadí borrow checker vývojářům, kromě toho, že se musí učit nové věci? Naopak mě přijde, že přemýšlení o práci s pamětí spíš vynucuje.
[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]
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.
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.
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.
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”).
Není to spíš problém diskutérů na rootu nebo jinde? Tohle je poměrně snadno ověřitelná věc. Můžeme tady napadat způsob jakým k výsledku došli, ale pokud je v pořádku, tak není racionální důvod nesouhlasit s výsledky, tohle není politika. Bohužel ale diskuze na celém internetu prakticky o čemkoliv dávno podléhá hlavně dojmům a názorům.
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.
Google v loňském roce zveřejnil dnes již velmi známou statistiku, že cca. 70% bezpečnostních chyb v prohlížeči Chrome/Chromium je způsobeno špatnou správou paměti.
Tak to nevim zda bych se verejne chlubil tim, ze mam takto spatne programatory, jeste horsi vedeni projektu, a zcela chybejici QA procesy? :-)
Je tedy logické, že jeho vývojáři hledají způsob, jak tuto situaci zlepšit.
Vyhazet indy a vsechny kteri se na pozici dostali kvuli kvotam, a najmout skutecne programatory.
A ne, C ani C++ nemuze za to, ze nekdo neumi psat dobrej kod, pripadne ze nekdo nechava zakladni pametove alokace/dealokace na libovuli anarchisticke smecky tvorici jakysi produkt.
Tak to je mýtus a zrejme aj nafúkanosť/neznalosť poniektorých programátorov.
Prečítajte si štatistiku:
https://alexgaynor.net/2020/may/27/science-on-memory-unsafety-and-security/
Google, Apple, Ubuntu, Firefox reportujú, že veľká čast bezpečnostných chýb je
spôsobená jazykmi C a C++. Žiaľ, nič na tom nemení aj používanie smart pointerov v C++.
Ak si tieto veľké firmy (údajne) nevedia nájsť schopných programátorov, tak potom kto to dokáže?
Ako, keď následkom pamäťových chýb spadne aplikácie, čert to ber. Ale tu ide o životy a majetok ľudí. Osobne by som si rozhodne nechcel brať toto na svoje svedomie. Preto pre kritické aplikácie je potrebné použiť technológie, ktoré tieto kritické chyby eliminujú.
No, v korporatoch okrem programatorov treba uzivit aj suitu okolo programatorov. Projektakov, analytikov, kamosov/kamosky, rodinu, potom to vyda na niekolko seniorov, viacero juniorov ktori sedia lokalne a mrte indov remote... seniori napokon nestihaju programovat, pretoze vysvetluju indom ze nie vsade na svete ma mena 6 desatinnych miest, mentoruju juniorov a ked vyda cas tak robia code review a merguju vetvy v gite... a tuto idylku im sem tam narusi particka produktakov po intenzivnom brainstormingu, to musia este seniori filtrovat relativne dobre myslienky od dusevnych zvratkov...
[Calculon]
Coz je na jednu stranu sice dobre, ale na druhou stranu si tak mozna delaji medvedi sluzbu. Kdyz hodi odpovednost z vyvojare na jazyk, neverim tomu ze potom budou mit lepsi produkty....
A je taky otazka jak moc to funguje. Vem si ze za pomerne kratkou dobu tech jazyku docela pribylo. Z tech nejznamejsich jen Rust, Go, Vala....
Nevim, ja jsem v tomhle hodne skepticky.
26. 9. 2021, 22:49 editováno autorem komentáře
Nechci posuzovat, jestli to povede k lepším produktům nebo jak moc to funguje. Nicméně tak trochu jsem ve vleku událostí, protože mnoho projektů, ke kterým se dostanu, je teď buď v Go, nebo v Rustu. Nejlepší jsou ty, kde je kus starého C++, nad tím vrstva Go, do které se ono C++ postupně přepisuje, a zároveň už se z druhého konce portuje kód v Go do Rustu.
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í.
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é.
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.
@klokan
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í.
Obdobu toho přístupu najdete všude ... a to nejen v programování. To je kombinace sklonu k lajdáctví a přebujelého ega - to je totiž to hlavní co výsledek takové analýzy zboří, řádky kódu se příší daleko snadněji ...
27. 9. 2021, 10:24 editováno autorem komentáře
Kvůli tomu vzniklo údajně i Go. Má GC, kontroluje indexy, dělá escape analýzu, aby dalo potřebné objekty na haldu atd. Ono totiž i špičkový vývojář s magistrem z astrofyziky a PhD z CERNu naseká v kódu bugy. Může perfektně zvládnout koncept a návrh, ukázkově celou architekturu, ale jakmile se začne psát kód, dochází prostě k chybám. Proto se používá silná typová kontrola, testy, statická analýza a podobné vymoženosti.
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.
Ty už to raději zabal. Co slovo to lež. Hned na začátku se omlouvám že reaguji, ale občas mi to prostě nedá.
Podle mne mohu ovlivnit jak se knihovno chová poměrně snadno. Například tím, že ji použiji jak se má a jak bylo zamýšleno.
Pokud se knihovna podle toho nezachová tak je to její problém a ne můj a ani jazyka.
Co se tvých představ týče, tak to asi nechám na tobě, ale řeknu ti že se na jádru (nevím o jakém se přesně bavíš, já budu zmiňovat jádro linuxu) podílí poměrně velká skupina lidí. A pevně věřím že je mezi nimi i velká část lidí co věří, že je od chyb oddělí jazyk či překladač (případně jim pomůže se jim vyhnout).
A to mluvím i sám za sebe. Jelikož jsem měl tu čest se s pár vývojáři bavit a i sám poslat vlastní patch do jádra , který byl začleněn.
Jo a to mimochodem patřím mezi lidi co Rust a Go moc nemají v oblibě (pravda stále je miluji s porovnání s Javou). Ale i tak jim přeji úspěch a pokud se jim bude dařit tak je rád budu podporovat.
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 :)
To jsi napsal hezky. Ono PhD z CERNu je prostě ukázka člověka co vlastně nemusí vůbec umět programovat. Tím jen chci podotknout že to vůbec není o titulech a místech. Každopádně souhlasím s tím, že k chybám dochází všude. Na všech úrovních a jazycích.
Jasný že existují lidé co jsou opatrní, extra opatrní a ty bez chyby jako já. Ale né každý se tam může řadit.
To byl samozřejmě vtip. Dělám chyby denně a s věkem čím dál víc a jako mladý jsem je dělal možná ještě víc. Prostě chybovat je lidské.
Takže jakýkoliv nástroj co mi umožní své chyby odhalit a i ideálně napravit vždy vítám. A proto jsem si zvolil jazyk D. Umožnil mi psát dle mých představ. Zaručil mi poměrně velké bezpečí toho že nedělám chyby a zároveň vše fungovalo dobře a rychle. A zároveň dělá vše co jsi psal (GC - což je v podstatě jakákolv automatická správa paměti i RC a ARC, nebavím se o borrow checkingu), částečně má i podporu správy paměti jako má rust, dělá kontrolu že nezasahuji mimo buffer, že nepracuji s již nevalidní pamětí atd.
Takže za mne zatím jazyk který mi nabízí veškeré výhody a nemusím platit co jse pohledu výkonu týče (krom C++, ale tam mi ještě chybí pár drobností).
[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.
"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.
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.
[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
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.
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...
Kdyz hodi odpovednost z vyvojare na jazyk, neverim tomu ze potom budou mit lepsi produkty....
Never, ale cela odvetvi, kde opravdu o neco jde (o zivoty) se snazi maximalne eliminovat rizika selhani lidskeho faktoru, i kdyz se jedna o nadstandardne vyskoleny personal, protoze vi, ze se na nej neda 100% spolehnout a driv nebo pozdeji se dopusti chyby. Typicky priklad letectvi. Sice mas vyskolene piloty s pravidelnym prezkusovanim, ale i tak je cely system rizeni nastaveny, aby se pilot nedopustil chyby. A kdyz se pokusi udelat chybu, je durazne upozornovan, ze se blizi problem. Proc by to nemelo fungovat i v programovani?
Nikdy jsem moc nerozuměl tomu kultu kolem Plan9, co na něm má být tak úžasného. Podle mne to byl prostě experiment jakých jsou tisíce, a mnohé z nich se ukázaly přínosnější.
Dneska se Pike motá kolem komunity suckless vůči které mám absolutní averzi a neumím si představit, že bych kohokoli z nich považoval za rozumného vývojáře. Poslední věc, co jsem od Pika četl na blogu (už je to nějaká doba) je, že by se suckless měl dělat v Go. Takže asi tak.
Zdravim RDa, co jeste nikdy nezavlekl do programu bug.
C++ za to mozna nemuze, ale sprava pameti neni tezka u projektiku co vypisuje "Hello World". Je to tezke kdyz musis interagovat s cizimi knihovnami, ktere maji interni stav, kvuli rychlosti treba nemohou vsechno kopirovat, interfacy jsou dane, strojovy kod pristupujici k objektum v pameti se generuje za behu, neco musi byt thread safe atd.
Pak treba knihovne predas (v zmyslu std::move pro unique pointer) dva objekty ktere cez nekolik objektu pouzivaji neco spolecneho a za jistych okolnosti se musis zajimat, v jakem poradi se volaji destruktory. To cele kvuli kodu, o kterem nemas jak vedet, kdyz nectes vsechny implementace.
RDa hlavne nepouziva 3rd party knihovny (a takove cross-concept bastly jak jsi popsal netvori) a pise si svuj vlastni kod kteremu rozumi. Bugy se sem tam stanou, ale to odhali uz vetsinou uz moje integracni faze, kdy se kod zacne pouzivat nad ramec piskoviste kde vznikl.
Vyjimecne se stane, ze se bug, za ktery muze muj kod dostane mimo me, ale i ten posledni zachytilo dlouhodobejsi predprodukcni testovani u zakaznika - a to jsem za to mohl jen z pulky, protoze slo o sw vs. hw race condition. Byl to ale zajimavy proces, kdyz Ti zareportuji podivne chovani s urcitym patternem - a hned bylo zrejme, ze ktera cast kodu za to muze. Opraveno obratem.
Ale ja jsem divnej - ale nepouzivam ani debugger, ani verzovani. A jediny 350KLoC codebase v C sdili vsechny projekty urciteho druhu - takze to je opakovane "testovano" a pripadne vylepsovano - bez nutnosti podivnych branchu a merge konfliktu.
Nejvetsi for je totiz ten, ze kdyz se snazite neco poslepovat z 3rd party veci kvuli jednoduchosti, tak dojedete na tu integracni slozitost :-)
350 KLoC napříč všemi projekty je absolutní nic. Firefox má nějakých 20 MLoC a to zdaleka není nejvetší současný open source projekt. Takže při vší úctě evidentně nemáš zkušenost s prací na velkém projektu, do kterého je zapojená spousta lidí.
A 3rd party knihovny se používají z dobrého důvodu: napsat správě a hlavně bezpečně dejme tomu random generátor, krypto nebo třeba jpeg loader není tak úplně jednoduché a je lepší, když to někdo vyřeší jednou a pořádně, než když to každý umělec bastlí sám, narychlo a nevyhnutelně blbě.
To je jenom 57x vice? A predpokladam ze meli vice nez 57 part-time programatoru nasazenych za poslednich 10 let. Takze jejich produktivita je.. rozhodne mensi nez moje (a tohle bylo jenom C, co jsem nastekal v PHP bude i delsi, ale neni to tak uceleny).
A ted sis krasne nabehl - protoze JPEG bylo neco co jsem si implementoval sam. A proc? Protoze typicka distribucni libjpeg.so umi jenom 8-bit obrazky (baseline profil) a ja potreboval pracovat s temi co patri pod extended profile a lossless jpeg format.
Vsechny tri profily jsou popsany ve stejne ITU specifikaci - ale nekdo, kdo se to rozhodl implementovat pro Linux to navrhl od pocatku spatne: pred kompilaci si musite zvolit zda jsou pixely 8bit nebo 16bit, takze vam to rozese*e cele API. Takto se pisou sdilene knihovny? jako fakt ne jako, tohle pouzivat odmitam, navic to tenkrat nemelo akceleraci pro extended a lossless snad zcela chybel.
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).
Pamatovat si neco o 350kLoC je neco jineho nez pamatovat si to o 100MLoC.
Jak sem psal - Chromium resi vykon a proto se nektere veci musi delat jinak nez programatorsky optimalne.
Zrejme ti nikdo nehleda v kodu zranitelnosti. Pady jsou o tom, co se deje velmi casto. O rad vice je bugu, ktere tam jsou a projevi se jen u opakovaneho specifickeho poradi volani z vicero vlaken nebo tak neco. Vetsinou jde o bugy, kde se treba i nekdo zamyslel nad treba data race, napsali se testy, ale nezohlednil se nektery pripad.
Super názor!
Já si to myslím taky. Navíc je třeba si uvědomit, že prohlížeč není jen o C++ - prohlížeč vlastně sahá na všechno - grafika, zvuk, síť, filesystem, dnes i multiprocess a rychlé IPC, hodně OS specific věcí, které stejně mají C-API - tam jiný jazyk vůbec nepomůže - pokud mám nějaký handle, tak ho můžu leaknout nebo předčasně zavřít z kteréhokoliv jazyka a je průser. Navíc je tam JS engine, který má GC a potřebuje držet reference na objekty v C++ (třeba DOM nebo různé rendering contexty atd). Je to celé hodně komplikované a třeba doteď nevidím benefit Rustu ve Firefoxu.
Dnes máme v C++ mnohem větší možnosti než 10 let dozadu - milion druhů sanitizérů, atd... Důležité je testovat. Jasně, Rust je super, ale není to žádná spása...
Já už jsem se k tomu vyjadřoval jinde. Těch 70% problémů s pamětí je dáno tím, že 70% vývojářů Chrome neumí C++. Nebo se učili C++ před rokem 2011. Nebo dodnes nikdo nepřepsal velmi staré kusy kódu v Chrome (Webkit, blink). I to, že jsem s tím kódem měl tu čest někdy v roce 2014 pracovat, protože jsem musel mít jeho fork.
od C++ 11 máme std::unique_ptr a std::make_unique. Sice to ještě není ekvivaletní borrow checkeru, ale je to na dobré cestě. Pokud totiž si v C++ neděláte vlastní správu paměti, na problémy memory leaků nemáte prakticky šanci narazit - vyjma speciálních situacích, které nepořeší například referenční čítače na shared_ptr u kruhových referencí - kde to chce buď lépe promyslet strukturu aby nevznikaly cykly, nebo použít nějaký GC.
Co mi v zásadě v normě chybí je možnost označit && referenci jako force-move, tedy atribut který oznámí kompilátoru, že proměnná, kterou narvu do takové reference bude po návratu neplatná, protože se tady zaručeně stěhuje vlastnictví (klasický std::move sice označuje místo přesunu vlastnictví, ale když ho volaná strana nepřesune, pak je původní proměnná stále platná)
Dál mi samozřejmě chybí zamykatelné reference - které si člověk ale může napsat sám, jen to prostě není v normě. Takové to, že když si přistoupit k objektu, musím ho zamknout buď shared lockem (dostanu const ref) nebo exclusive lockem (dostanu mutable ref). Tohle řeší přístup pro vícevláknový přístup, který se podle mne musí dělat runtime (i ten RUST tam někde bude mít zámky na úrovni RT).
Tohle je ten starý paeudoargument, že vývojáři Googlu "neumí C++" (zatímco každý Pepa na rootu je samozřejmě expert, jenom škoda, že se svět neobrátil na něj, a přitom dokázal napsat hello world...) Google zveřejnil i jiná, stejně známá data, že podobné procento bugů je méně než rok starých. Už nevím, kde to bylo, vygooglujte si to. Jak sami autoři zdůrazňují, neznamená to, že by nový kód byl horší, než ten starý. Znamená to, že jak se starší bugy řeší, neustále přibývají nové. Neboli i s celým std::move a unique_ptr a spol. C++ nedokáže zaručit správnost kódu. Mimo jiné proto, že tyhle věci jsou v podstatě kosmetické, doopravdy nefungují.
Sdílení referencí mezi vlákny se v Růstu řeší dost jiným způsobem.
Vážně? Tak co třeba tohle:
std::vector<int> v;
v.push_back(666);
auto u = std::move(v);
std::cout << v[0] << std::endl;
Jakýkoli C++ compiler to vezme, a jak jsem si právě ověřil s g++ 11.2.1, při běhu to udělá jak jinak než segfault.
Takže vaši poznámku beru tak, že toho, že to nefunguje, jste si opravdu nevšiml :)
to je správné chování.
protože v je prázdné pole.
Špatně je tu, že operator[] nemá kontrolu rozsahů. A to z důvodu efektivity.
A kdybyste četl celý můj příspěvek, přesně o tom jsem psal. Chtělo by to do C++ přidat mechanismu, kdy explicitně prohlásím po použití std::move proměnnou jako více neexistující aby překladač označil použití v za nesprávné.
Na druhou stranu, je to forma syntaxtického cukru, nic co by se nedalo udělat.
Š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.
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
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é).
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.
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
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.
"Tohle je ten starý paeudoargument, že vývojáři Googlu "neumí C++" (zatímco každý Pepa na rootu je samozřejmě expert, jenom škoda, že se svět neobrátil na něj, a přitom dokázal napsat hello world...) "
Hmm, on ten chrome staví hlavně na open source prohlížeči kde se podílelo mnoho dobrovolných vývojařů. A stačí si ten kód otevřít a zjistíte, kterou část psal který pepa. Protože k velké účtě open source komunitě, nemělo by se to přehánět. V okamžiku, kdy program je víc umělecké dílo než funkční celek a k tomu aby to pořádně fungovalo to musí někdo lepit k sobě kobercovkou, pak to podle toho vypadá.
Nekde jsem videl pokus o neco podobneho(link uz bohuzel nemam).
Slo o to, ze pri vytvoreni instrance tridy na zasobniku se pouzije jiny konstruktor/alokator nez pro instanci na heapu.
Kazda instance si nejak pamatovala kde byla alokovana a pomoci typoveho systemu nebylo mozne vytvorit na heapu strukturu ktera by obsahovalala pointer na stack nejakeho vlakna.
Tyhle problemy kdy je v heapu pointer na stack jiz ukonceneho vlakna se hrozne tezko odhaluji.
Cele to ale bohuzel bylo trochu pracne, a cely mechanizmus by vyzadoval vytvoreni wrapperu okolo kazdne knihovny.