Názory k článku
Interaktivní shell Fish přechází z C++ na Rust

Dva roky sú dosť dlhá doba. To je akurát zanalyzovať, zrefaktorovať, upratať, zdokumentovať. Naviac je už hotový prototyp, majú to s čím porovnávať. Najzábavnejšie je zistiť, že s akými bugmi fungoval roky originál a nikomu to nevadilo (alebo sa na to neprišlo).

Jak znám projekty 10+ let staré, tak přepsat je je rychlejší než v nich opravovat chyby.

Jenže ty části přepisovali/nah­razovali postupně, nešli na to tak, že přepíšou všechno na zelené louce.

Vzhledem k tomu, jak špatně se to dá měřit, to je odvážné tvrzení.

Myslím si, že je oveľa odvážnejšie tvrdiť, že tie prieskumy nemajú žiadnu vypovedaciu hodnotu. Takže ja svoje tvrdenie pokojne zopakujem.

Okrem toho, nikde som netvrdil, že C++ rastie nejako rapídne. Na druhej strane ale, čo sa rapídneho rastu týka, tak z nuly sa rastie rýchlo. To sa možno ekonómovia učia dokonca už v prvej triede.

Ale o tom sa vôbec baviť nemusíme, môžeme to pokojne ignorovať. Z mojej strany to bola poznámka k vtípku vášho predrečníka, ktorý popieral to, že C++ sa zlepšuje.

Takže pokiaľ nemáte nejaký relevantný podklad k tvrdeniu, že sa C++ nezlepšuje, tak to musím považovať iba za anonymný výkrik do tmy a môžeme túto debatu ukončiť.

Nerostou všechny obecně používané jazyky? Je to stejné, jako že roste počet uživatelů Linuxu, i když procento je furt podobné.

Pardón, ale rast alebo nerast už nie je aktuálna téma. Už sme sa vrátili o krok späť k podstate veci. A tou bolo to, či je novšie C++ lepšie alebo nie je. Pokiaľ nie je, tak prosím objektívne fakty. Inak tá debata nemá zmysel.

Která verze C++ mi poskytne záruky, že pokud udělám něco podle příručky, tak že mi ohlídá, zda jsem něco nepřehlédl? Ne nutně všude samozřejmě, to nejde. Ale třeba alespoň paměť, RC, ... ?

Jsem ochoten se dohadovat s kompilátorem. Nejsem ochoten (už) používat kompilátor, který je schopen zjistit, že kompiluje blbost a neřekne mi to.

Ja som niekde písal o zárukách? A ešte k tomu v súčasnej verzii C++? To som si naozaj nevšimol.

Ee?

Otázka zněla: "A tou bolo to, či je novšie C++ lepšie alebo nie je."
Odpověď zní: Není, protože neposkytuje záruky. Je to "objektívne fakty." ?
Pokud ne, tak skutečně "Inak tá debata nemá zmysel.".

Aha, ja ale nemôžem za to, že čítate diskusiu od stredu. Ja som sa do nej zapojil zamyslením o dôvodoch prečo sa autori projektu rozhodli prepísať kód a lepšie C++ som spomenul s ohľadom na budúcnosť, so znalosťou toho, že v rámci komunity sú snahy urobiť C++ bezpečnejším, čo som zjednodušene nazval lepšie C++, a spomenul som, že za poslednú dekádu prichádza lepšie C++ každé 3 roky, čo je podľa mňa objektívna pravda a nemyslel som tým práve iba oblasť bezpečnosti, ale celú škálu nových vecí, ktoré od C++11 prišli.

V súvislosti s tým som potom reagoval na vtípek, ktorý zlepšenie C++ spochybňuje, vzhľadom na to, že sa v tom vtípku nikde nepísalo o bezpečnosti predpokladám, že bol mienený všeobecne a v tom smere bola aj moja reakcia. Na ktorú ste potom reagovali vy. A pokiaľ ste si to vyhodnotili, že sa to týkalo konkrétne aktuálnej verzie a konktérne bezpečnosti, tak to naozaj nemôžem nijako ovplyvniť.

Inak by ma zaujímalo čo konkrétne myslíte, nech sa netočíme dookola, ale ešte predtým ako sa do toho prípadne pustíme, tak áno, nie všetky veci sa podarili, áno, v aktuálnej verzii aj v nových veciach sú niektoré veci, ktoré sa správajú prekvapujúco, ale je to známe, a veci, čo sa budú dať opraviť budú opravené a veci, ktoré nebudú opravené, nebudú opravené s ohľadom na spätnú kompatibilitu, čo nie je nejaký výmysel tých, čo vývoj C++ riadia, ale požiadavka od jeho používateľov, prinajmenšom tých, ktorí majú nejaký vplyv, teda tých, ktorí majú tie kvantá kódu, ktorý nebude nikto prepisovať, o čom píšem niekde nižšie alebo vyššie, pretože logicky, keby ho chcel niekto prepisovať, nebránil by sa zmene jazyka s odstránením spätnej kompatibility, ktorá by vyžadovala čiastočné prepísanie.

Takže celá situácia je naozaj oveľa komplexnejšia ako jeden aspekt, ktorý momentálne zaujíma vás.

Nevim jestli ti programovací jazyk zákáže psát blbosti - takový neznám...

Kvantifikátory, kvatifikátory, ...

Třeba borrow checker máme i v C++, jmenuje se unique_ptr. Ale není to tak cool a 90% programátorů (z množiny, které jsem za svůj život poznal) o něm buď neví, nebo ho schválně nepoužívají.

Je to tak.

Třeba borrow checker máme i v C++, jmenuje se unique_ptr.

Promiň, ale víš vůbec, co dělá borrow checker? Mám podezření, že ne, protože bys jinak nemohl napsat takový nesmysl. Jak mi pomůže unique_ptr s tímto?

int main()
{
    auto a = std::make_unique<int>(0);
    auto b = std::move(a);

    // USE AFTER MOVE!!!
    std::cout << *a;

    return 0;
}

Rust takovou chybu chytí při překladu a tohle je smysl borrow checkeru, unique_ptr rozhodně borrow checker není.

Akorát to není use after move, je to null pointer access. Proč se tady bavím s lidma, kteří tomu nerozumí?

Jediná výhoda v Rustu je, že vám to řekne překladač. Mezitím překladače pro C++ se samozřejmě dále vylepšují na úrovni statické analýzy a vsadím se, že už někde je, nebo bude překladač co na to minimálně upozorní.

Akorát to není use after move, je to null pointer access. Proč se tady bavím s lidma, kteří tomu nerozumí?

Tak to jsi na velkém omylu. Tvářiš se jako velký znalec C++, ale nevypadá to. Není to null pointer access (to je až side effect use after move). Objekt po move stále existuje a je ve validním stavu. C++ standard to jasně říká:

Objects of types defined in the C++ standard library may be moved from (12.8). Move operations may be explicitly specified or implicitly generated. Unless otherwise specified, such moved-from objects shall be placed in a valid but unspecified state.

Takže je to volání operátoru dereference na moved objektu (to je ten bug), nikoliv null pointer acccess, to je až implementační detail. Primární problém je v přístupu k objektu po move.

Říkám, že tomu nerozumíte. A nemusíte se do toho nořit hloubš a hloubš.

To jak funguje move je implementační detail. Dereference moved objektu není bug, to je feature. Proto to není use after move, protože to není žádná chyba.

Běžně používám objekty opakovaně po move. třeba


std::vector<char> buffer;
while (true) {
fill_buffer (buffer);
dispatch_buffer(std::mo­ve(buffer));
}


Protože move v tomto případě přesouvá obsah, ne samotnou proměnnou.

Ale o tom to vůbec nebylo. unique_ptr neumožňuje use after move, protože dávno neukazuje na přesunutý objekt. Bavíme se přece o objektu na který ukazuje,ne o pointeru. To že unique_ptr je nějak implementovaný je implementační detail. V základě umožňuje to co borrow checker. V danou chvili vždy někdo drží vlastnictví - a funguje to napříč kompilačními moduly a i mezi ABI

Překladače samozřejmě mohou upozornit na dereferenci po přesunu, protože se do objektu přiřazuje null, který se pak dereferencuje. Pokud překladač během optimalizace tohle vidí, může upozornit, že tam taková věc je. (to jestli kód pustí nebo nepustí dál záleží jestli to udělám error nebo warning)

Dereference moved objektu není bug, to je feature. Proto to není use after move, protože to není žádná chyba.

Možná bys autorům clang-tidy měl vysvětlit, že use after move není žádná chyba, takže to hlídají úplně zbytečně.

C++ standard jasně říká, že objekt je po move ve validním, ale NESPECIFIKOVANÉM stavu, takže dělat na moved objektu cokoliv jiného než volání destruktoru, je hraní si s ohněm. Ono to může fungovat, ale spíš kvůli tomu, že se jedná o konkréttní implementační detail (náhodou je to implementovné tak, že něco po move funguje a v nové verzi objektu už to nemusí platit).

Tady bych jen vypíchnul, že move semantika byla do C++ přidána teprve nedávno a nikdo pořádně neví (včetně tebe), jak to funguje a jaké to dává nebo nedává garance.

V Rustu move funguje out of the box, programátor se o to nemusí vůbec starat (žádné psaní move konstruktorů), protože move je v Rustu interně implementované jako memcpy. Move v Rustu řeší překladač, takže v tom nejde udělat chyba a je to vždy správně, narozdíl od C++, kde se o move musím ručně starat. Dobrý příklad toho, jak je Rust oproti C++ v bezpečnosti i ergonomii o světelné roky napřed.

Ja sa teda pripojím... Nemohlo sa stať, že si mýlite use after move u všeobecného objektu štandardnej knižnice a u špecifického objektu, ktorý sa volá unique_ptr? Alebo že nechápete čo tie jednotlivé stavy znamenajú?

To druhé sa týka toho, že primárny problém nie je v prístupe k objektu po presunutí všeobecne. Objekt je vo platnom, ale nešpecifikovanom stave. To znamená, že k objektu sa dá po presunutí pristupovať, ale iba niektoré operácie sú podporované, napríklad opätovné priradenie alebo deštrukcia, zatiaľ čo iné operácie v tom stave podporované nie sú.

To prvé sa týka toho, že, to, čo citujete sa týka objektov štandardnej knižnice, ale iba tých, ktoré nemajú bližšie špecifikované správanie. unique_ptr ale správanie bližšie špecifikované má v inej časti štandardu a v jeho špecifikácii je, že ukazovateľ spravovaný jedinečným ukazovateľom je nastavený na nullptr.

Toto priradenie nie je činnosť, ktorá by prebiehala z vlastnej iniciatívy poskytovateľov prekladačov v zóne nedefinovaného správania, čo ani všeobecne neznamená, že sa tam nič nedeje, ale je to predpísané špecifikáciou.

to linuxák:

Sakra nemáte pravdu. Nevím kde jste četl že po move objekt je v nespecifikovaném stavu.

Move operace by neměla objekt strkat do žádného nespecifikovaného stavu. Ten stav musí být jasně specifikovaný, jako všechno v C++. Navíc po move je objekt stále validní. To co na něm lze nebo nelze dělat za operace je čistě rozhodnutí designera objektu. To je rozdíl od Rustu, kde move znamená, že mám smůlu.

Ano v Rustu je move víc move než v C++. To je určité řešení problému co s věcí, která se přesunula. Jeden to řeší tím, že řekne, že se přesunul stav. Druhý to řeší tím, že ta věc, na původním místě přestala úplně existovat.

I v clang-tidy mohou být chyby. Nebo je to porušení na úrovni abstrakce, - pokud vím, Rustaři moc abstrakci neberou, takže mne jen překvapuje, že jste to vytáhl

Nemáte pravdu ani v tom, že move byl přidán nedávno

C++ move semantics a rvalue reference byla přidána v C++11, to je rok 2011. Ale existovala už v C++0x. Ta nula před x znamená, že jsme před rokem 2010. Přitom šlo jen o řešení palčivého problému s auto_ptr, který bez rvalue reference fungoval špatně a mnozí radili se mu vyhnout

Rust vznikl kolem roku 2010 a oficiálně byl vydán až v 2011. Dalo by se říct, že možná v té době někdo řešil stejné problemy v C++ a rozhodl se jít cestou nového jazyka.

Mimochodem, tento rok se to opakuje, zase vznikají nové jazyky protože kolem C++ panuje pomalejší vývoj. Ale já si nejsem jist, že kdykoliv se objeví nějaký trendující problém , že hned se musí začínat vynálezem kola

30. 12. 2024, 21:10 editováno autorem komentáře

Myslím, že to nedorozumenie spočíva v tom, vy píšete o objektoch všeobecne, teda hlavne tých, ktoré píšete vy sám, linuxák o objektoch štandardnej knižnice všeobecne, teda tých, ktoré píšu poskytovatelia prekladačov na základe normy, ale iba o tých, ktoré nemajú ďalšiu špecifikáciu, pričom ale unique_ptr a ostatné ukazovatele medzi tieto všeobecné objekty nepatria, lebo majú ešte dodatočnú špecifikáciu v inej časti normy.

Move operace by neměla objekt strkat do žádného nespecifikovaného stavu. Ten stav musí být jasně specifikovaný, jako všechno v C++.

Ne, ne ne. Je vidět, že C++ opravdu nerozumíš. Takže nějaké konkrétní příklady.

std::string má v C++ optimalizaci, kdy krátké stringy ukládá přímo do objektu a dlouhé stingy alokuje na heapu. Pokud udělám std::move na krátkém stringu, kde jsou data uložená v objektu, udělá to reálně copy a ne move. Pokud udělám std::move na dlouhém stringu, kde je to skutečně uložené na heapu, musí to interně přehodit pointery na heap. Standard nic neříká o tom, jestli musí být původní string po move prázdný, v prvním případě to klidně může nechat původní string v objektu a není to nic proti ničemu. Proto je ve standardu napsané, že je objekt v nespecifikovaném stavu, a to je také ten důvod, proč to clang-tidy hlídá.

Stejnou optimalizaci by mohl mít i std::vector (reálně nemá, ale nic tomu nebrání). C++ standard nezaručuje, že bude std::vector po move prázdný. Většina implementací se tak chová, ale obecně to neplatí, std::vector nemá ve standardu definovaný moved from state. Takže pokud tvůj kód, který jsi poslal, závisí na tom, že je vector po move prázdný, zahráváš si s ohněm, není to zaručené: https://stackoverflow.com/questions/17730689/is-a-moved-from-vector-always-empty

Linuxak opět nemáte pravdu ale ja nemam už naladu vám to vysvětlovat. Hele radši si to nastudujte sám

Linuxak opět nemáte pravdu ale ja nemam už naladu vám to vysvětlovat. Hele radši si to nastudujte sám

Věcné argumenty došly, tak radši jen plácneš něco do větru?

Takže znovu. V C++ je objekt po move v NESPECIFIKOVANÉM stavu. Ten kód, který jsi poslal a používá std::vector po move a pravděpodobně předpokládá, že je vector po move prázný, je chybný. Spoléhá se na něco, co standard nezaručuje. std::vector nemá v C++ standardu specifikovaný moved from state. Proto také clang-tidy takové věci kontroluje, autoři clang-tidy vědí, proč to dělají a dává to velmi dobrý smysl.

Mimochodem kdybys používal Rust, tak nenapíšeš stejně chybný kód jako ten tvůj v C++, který používá std::vector po move, protože Rust překladač tuto chybu chytí. Takže Rust by byl přínosný i pro tebe, máš praktickou ukázku chyby, kterou jsi udělal a Rust by ji narozdíl od C++ chytil při překladu.

Tady se pro změnu ozvu já:

"Jediná výhoda v Rustu je" -- tohle je tak strašné a až děsivé nepochopení, že mě to od profesionálního a zřejmě zkušeného programátora opravdu překvapuje.

Zásadní rozdíl je v tom, že sebelepší C++ překladač tě na to možná upozorní.
Zatímco Rust tě nepustí dál.

C++ versus Rust jdou ideově proti sobě. C++ vychází z rozbitého kódu, který programátor svým umem opravuje. Rust vychází z funkčního (jak to jen matematika dovoluje) kódu, kde se programátor svým umem snaží protlačit featury.

Až toto pochopíš tak pochopíš, jak zbytečné jsou tvé příspěvky.

Jen se snažím ukázat, že božské featury Rustu nejsou až tak božské v jiném jazyce. Protože to co tady prezentujete je víra. Prostě to na čem Rust staví své jméno a prezentuje jako výhodu je v jiném jazyce normální nástroj, který akorát spousta lidí nechce používat. Vždycky je v tom nakonec nějaká víra (ti lidé co to nechtějí používat se na to dívají jako na nástroj ďábla).

Já jsem ateista.

A to jestli něco překladač pustí nebo ne je forma zlepšování uživatelského zážitku. Ani to není důvod učit se nový jazyk. Já bych samozřejmě chtěl, aby se na úrovni překladačů provedlo spousta vylepšení v úrovni statické analýzy kódu, aby mi třeba překladač vyhodil všechna místa, kde hrozí UB (je na mne, abych si je ošetřil nebo ne). Nic z toho není důvod tvořit nový jazyk od nuly, jen proto, že v jiném jazyce chybí nějaká featura.

Warningy se dají považovat za chyby, je na to switch

Ta "božská feature" je právě ta filozofie. Když podobné chování v C++ musím vynutit, tak na to někde zapomenu, a zapnout to globálně mi znefunkční dřívější kód.

std::unique_ptr z C++ odpovídá Box v Rustu. A shared_ptr je něco jako Rc (nebo podobné Arc).

Move operace obecně s tím nemá co dělat, ta jen umožňuje hlídat co se děje se zdrojem.

Už ten Váš příklad s nullptr je totiž ukázkou problému. To jestli se po move nastaví zdroj na nullptr je zcela zastíněno faktem, že v C++ je možné potom udělat dereferenci nullptr ve zkompilovaném programu, což způsobí pád během runtime! Rust to nedovolí na úrovni překladače. Takže ani přehlédnutí nějakého obskurního chování dle standardu nezpůsobí pád aplikace.

Samozřejmě, že ve výsledku jde jen o překlad nějaké syntaxe a ty kontroly se dají dělat různě. C++ si s sebou ovšem táhne tolik balastu a kompatibility se starým kódem, že tohle nemůže změnit.

Přiznám se, že jsem se nevyjádřil úplně nejlíp. Ten božský rozdíl je v tom, že v C++ se musíš snažit, abys nepustil chybu (a stejně nebudete mít jistotu). V Rustu se musíš snažit, abys tu chybu vytvořil.

Když pustím nad Rustem nějaký tool, tak mi řekne, kolik unsafe sekcí (panic, etc) tam je a kde, a podle toho mohu hodnotit v jakém stavu ten kód je, a nějak odhadnout rizika. Vlastně se dostanete na úroveň kódu těch nejlepších programátorů.

V C++ se mohu orientovat jen podle toho, jak zkušené programátory mám. Což je zoufale málo. Ano, dobré nástroje mi najdou některé chyby. Což je, opět, zoufale málo.

Sám si říkal, že naučit programátory dobře C++ je nereálné. A vzhledem k tomu, že sám o sobě tvrdíš, že neuděláš v kódu chybu, tak mě tato životní strategie vlastně nezajímá. Proč plejtvat potenciálem na to, aby programátoři nedělali chyby, když se můžou soustředit na featury?

C++ nemá to co má Rust - bezpečnost by default.
C++ nemá to co má Rust - čitelnější a jednodužší syntax.
C++ nemá to co má Rust - záruky.

(vono toho C++ nemá víc, ale nebudu dál provokovat)

Ještě donedávna měl C++ niku v aplikacích náročných na paměť a výkon. Nikdo soudný by nepsal herní engine v Javě nebo dokonce v Smaltalku. S příchodem Rustu se to změnilo.
Prostě je konec.
Smiř se s tím.

Ano, můžeš věřit, že C++ je lepší. Ale nakonec je to jedno, protože stále budeš mít práci. Legacy projektů v C++ je mraky. Takže o nic nejde. Pokud Rust nechápeš a neumíš ocenit, nic ti nehrozí.

"C++ nemá to co má Rust - bezpečnost by default.
C++ nemá to co má Rust - čitelnější a jednodužší syntax.
C++ nemá to co má Rust - záruky."

Tak v čem jsou napsány systémové knihovny, které Rust v runtime používá?
Jsou bezpečné by default? Celek je tak bezpečný jako jeho nejméně bezpečná část.

C++ má legacy kouli na noze, to je pravda. Pro WG21 je zpětná kompatibilita zásadní a k jejímu porušení se přistupuje opravdu v krajním či okrajovém případě.
C++ nenutí programátory používat raw pointery či nativní datové typy napřímo, takže to není o tom, zda něco C++ nemá, ale zda se používá ta část jazyka určená pro nízkou úroveň na té vysoké. Ano, je to bolest, ale je to zatím tak. Pokud někdo chce, může si nastavit flagy Wall a Werror a používat cppcheck či clang tidy.
Od C++26 jsou tu profily, které budou vypínat dle potřeby ne-bezpečné části jazyka.

Stroustrup na jedné přednášce řekl: "Kdo pochopil std::vector pochopil C++"
To vystihuje úplně vše. Kdo bude prasit C++ stejně jako C v garážovém stylu "Osmdesátek", tak výsledek bude hnůj. Většina dnešních C++ programátorů ten jazyk neumí používat, protože je to nikdo nenaučil - mantra o složitosti C++ je směšná, týká se to tak maximálně šablon a to jenom ve standardech před C++20.

No psát o Rustu jako nástupci C++ je celkem vtipné, protože každý jazyk směřuje totálně jinam(po stránce vlastní evoluce).

Nakonec přeji, ať nadšení z Rustu vydrží co nejdéle.

> Celek je tak bezpečný jako jeho nejméně bezpečná část.

Tohle přirovnání je absolutně mimo. Když to vztáhneme na oblíbený řetěz, budeš raději hlídat každý článek plastového řetězu pořád dokola, jestli náhodou někde nezačne praskat, nebo použiješ ocelový s jedním plastovým článkem, který se snáz hlídá a opravuje?

Tohle je taky mimo, ale bližší realitě. Navíc i když najdeš exploitovatelnou chybu v libc, musíš se k ní nejdřív skrz program dostat - což v případě Rustu nemusí být vůbec snadné.

ne, já jen nesdílím ten optimismus rustaru ze se neco zmeni, uz ted sam rust na spouste mistech ukazuje ze jeho system neni bez chyby a musi vznikat rovnaky na ohejbaky v podobe unsafe kodu,

proste je to porad dokola misto toho aby se dumalo jako danoi vec v jednom jazyce vyresit, zavedeme novy jazyk, ktery tu vec resi, mozna, ale na oplatku se musim vzdat hromady vyhod z toho puvodniho jazyka a jeste musim prijmout viru ktera vznikla jen proto aby tento problem zakryla.

> "Pokud Rust nechápeš a neumíš ocenit, nic ti nehrozí"

"proste je to porad dokola misto toho aby se dumalo jako danoi vec v jednom jazyce vyresit, "

C++ nejde opravit. Má chybné paradigma už od začátku. Změna paradigmatu je ještě horší nápad, to ti doufám nemusím vysvětlovat.

"na oplatku se musim vzdat hromady vyhod z toho puvodniho jazyka"

Proti Rustu nemá C++ žádné výhody. (Pokud nebudeme považovat za výhodu ohromné množství existujícího kódu, to je samozřejmě fakt.) Natož hromady.

"C++ nejde opravit. Má chybné paradigma už od začátku."
Jaké? Prosím o vysvětlení co je od začátku špatně.

"C++ nejde opravit. Má chybné paradigma už od začátku."
Jaké? Prosím o vysvětlení co je od začátku špatně.

Velké téma v C++ komunitě je aktuálně memory safety. Všichni by chtěli C++ memory safe (včetně mě), ale problém je v tom, že C++ nejde udělat memory safe bez ztráty zpětné kompatibilty, což taky nikdo nechce. Jsou docela velké tlaky na to, aby C++ bylo memory safe, např. i ze strany US governmentu. Situace v US je taková, že kdo bude chtít dodávat software pro US government, bude muset používat memory safe programovací jazyk (ne hned, ale jasně to k tomu spěje). To je špatná situace pro C++, protože to nevyhnutelně povede k tomu, že firmy kvůli tomuto požadavku US governmentu začnou od C++ migrovat pryč, pravděpodobně k Rustu.

Takže C++ standardizační komise je teď ve schizofrenní pozici. Musí řešit memory safety, což ale v podstatě nechce, protože většinový názor uvnitř C++ standarnizační komise je zachovat zpětnou kompatibilitu. Vzniknul návrh na Safe C++, který vypadá docela hezky, ale pochopitelně rozbíjí zpětnou kompatibilitu a dělá z C++ tak trochu Rust, takže ho standardizační komise smetla ze stolu a v podstatě se tím odmítla zabývat. Místo toho se tlačí safety profiles, ale to je jen takový hybrid, který trochu bezpečnosti pomůže, ale neudělá z C++ memory safe jazyk.

Uvidíme, jak se to bude vyvíjet dál. Externí tlaky na memory safety jsou velké a v C++ to nejde udělat bez ztráty zpětné kompatibility.

Ano, je to velké téma a zabývají se tim hlavouni z WG21 již nějaký ten pátek. Ale není to záležitostí nějakého paradigmatu.
Profily ani nejsou tolik hybridní řešení, ale je to věc kompileru - maximálně to přidá práci na straně programátora, např. by default bude nějaká konstrukce nebezpečná ale po přidání atributu/klíčového slova a podob. bude bezpečná a kompilace projde, takže nejde jestli je jazyk bezpečný a nebo ne, ale zda se používá tak, aby výsledný zápis bezpečný byl. Podle mě se v případě profilů jedná o mezikrok, který přidá čas k nalezení lepšího řešení. Zpětná kompatibilita je zásadní, nikdo z WG21 nechce opakovat situaci s Pythonem 3 a jsou snahy jít cestou TypeScriptu a tam jsou dvě možnosti: nová syntax bude mixovatelná s tou původní, nebo se udělají něco jako epochy v Rustu. Další věcí mířící do standardu je Erroneous behavior, které by mělo nahradit zatím undefined behavior při definici proměnné bez inicializace.
Nakonec ještě k bezpečné syntax - WG21 má zájem "nebezpečné" části jazyka zachovat, ale jejich použití by mělo být explicitní, důvod je ten, že existují místa a použití, kdy např. kontrola indexu do pole je příliš nákladná.

C++ je by default nebezpečný
Rust je by default bezpečný

Když si zobrazíte kus kódu v Rustu tak hledáte nebezpečné konstrukce: unsafe, panic, etc. Máte-li tam dejmetomu pět takových konstrukcí, tak je to pseudomatematicky

bezchybné - 5

Když si zobrazíte kus kódu v C++, a spustíte si na tom nějaký linter, checker, a cokoliv, tak vám to najde pět chyb. Takže pseudomatematicky je to

(blíže neurčené množství chyb) - 5

(Rád bych tě upozornil, že pokud budeš poukazovat na všemi včetně Rustařů známý fakt, že Rust neodchytí všechny chyby, tak si tě zaškatulkuju jako beznadějný případ, kterému není možno vysvětlit ani cenu rohlíku.)

Pořád jsem nedostal odpověď na moji otázku:

"C++ nejde opravit. Má chybné paradigma už od začátku."
Jaké? Prosím o vysvětlení co je od začátku špatně.

C++ je celkově unsafe, a můžeš mít části safe.
Rust je celkově safe, a můžeš mít části unsafe.

Dochází ti důsledky?

Díky tomu je prakticky nereálné, aby si se dostal s C++ k celkově safe. Důsledky jsou evidentní: Pokud budeš mít fakt dobrý programátory, o hodně lepší jak Ondřej Novák, a budeš mít velkorysí rozpočet - dostaneš se kvalitou na úroveň Rustu psaného průměrnými programátory za setinu ceny.

"C++ je celkově unsafe, a můžeš mít části safe.
Rust je celkově safe, a můžeš mít části unsafe."
To není žádné paradigma a je to minimálně zavádějící srovnání.
Podle teorie programovacích jazyků je C++ multiparadigmatický jazyk. Paradigmata jsou např. funkcionální, objektové, procedurální, modulární atd.
Pokud jde o podstatu C++ tak se jedná o jazyk s přímým přístupem k HW a abstrakcí bez nadbytečné režie(zero overhead abstraction - you don't pay for what you don't use), což je
velice správné.

Pokud bych srovnával C++ s Rust pak bych to udělal takto:

Oba jazyky si lze představit jako kufr s nářadím(budu se bavit o core language, nikoli o knihovnách).
Ten C++ kufr je o dost větší a obsahuje o dost více nástrojů, ke všem je stejně snadný přístup ať už je jejich používání s rizikem či bez, ale všechny jsou velice užitečné.
Rust má volný přístup jenom k nástrojům, které nenesou riziko při použití a ty ostatní jsou pod zámkem, takže musí být explicitně odemčeny.
Do C++ míří profily, které by měly ty nebezpečné nástroje zamknout, což bude zatím stačit, možná bude syntax 2.0 s možností zpětné kompatibility a nebo epochy, co se prosadí se uvidí.

Co se týče programátorů:
V C++ nevyšlo pouze z C ale taky ze Simuly, ale většina programátorů tehdy byli Cčkaři a tehdejší styl vývoje se propaguje dodnes - raw pointery, přetypování, mapování na paměť atd.
To ale není problém C++. To je problém toho, že tento styl se stále vyučuje, ikdyž k tomu nění žádný inženýrský důvod. Dodnes spousta učitelů(tím nemyslím pouze na školách) má za to, že
před C++ je dobré se nejdříve naučit C a pak až C++. Naproti tomu učitelé post C++11 mají za to, že to je kontraproduktivní a to právě z důvodu, že se pak huře zvyká na bezpečné nástroje.
Takže problém bude převážně s těmi programátory, kteří se naučili C++ před 30 a více lety. Tím ten argument s platy nebude takový horký.
Znám spousty programátorů, kteří na C++ svalují stav produktu, který kdysi výtvářeli, ale už nikoho z nich nenapadne, že ten jazyk používali špatně, oni totiž žijí pořád v omylu, že C++ je C s třídami a to doslova.

Znám C++ natolik, abych věděl jaké má důsledky ho využívat jako C nebo jaké důsledky jsou z používání jeho temných zákoutí.

Tak C++ je původně C s třídami, první verze snad byla implementovaná v C plus makra. Podobně jako Objective-C je další přístup přidání tříd do C. Až o dekády později je napadlo udělat z C++ "samostatný jazyk" po vzoru moderních jazyků a "reinvent the wheel" - přepsat standardní knihovny C do C++ stylu. Něco jako když Firefox měl rozšíření Firebug, ale pak implementoval vlastní vývojářský panel až po ostatních prohlížečích. A že se rekrutovali C++ vývojáři z vývojářů v C? Podle mě většina vývojářů Rustu se rekrutuje z C++kařů a problém to není.

To byl tvz. CFront - za pomocí maker se převádělo C++ do C, bylo to na začátku, sloužilo to jako "proof of concept", nicméně to nebyl cíl ani nikdy neměl být - Stroustrup to zmiňuje opakovaně - Simulu si v C++ většina programátoru neuvědomuje. Problém byl, že to programátoři C jako "C with classes" vzali. Standardní knihovny C++ dlouho nebyly, šablony jsou z Ady a byly implementovány do C++ na začátku devadesátých let, první iso je C++98.
Opět k těm vývojářům - když je někdo učí "C with classes" tak chápu, že ten Rust je vysvobození. To samé platilo i o Javě a C#, to byly ty jazyky, které všechno měly spasit.
Ano, Objective-C je opravdu objektové rozšíření C, C++ nikoli.

Jsem z toho úplně nepochopil, zda ti tedy dochází ty důsledky. Vypadá to, že asi ne. Každopádně jsem přesvědčen, že už není jaký další hint dodat. A platí stejná věc, jako u Ondřeje - můžeš si dovolit Rust nedocenit. Práce pro C++ vývojáře bude stále dost.

Jelikož mám znalost a praxi od Assembleru x86 a Motorola až po Lisp a stejně tak od jednočipu až po komplexní informační systémy, celkem mám vhled do toho , co se skrývá pod pojmy memory safety, resource safety, speculative execution, stack underflow či overflow, race condition, bounds checking atd. tak jsem si vědom důsledků toho co se stane, když se bude vyvíjet jako v garáži v osmdesátých letech minulého století nebo na úrovni kernelu či RT systému když to je kontraproduktivní. Moderní C++ je opravdu veliká množina nástrojů a pokud se chci vyhnout problémům vím co mám použít a jak to mám použít, není to žádná raketová věda, jde o to si to pouze osvojit a odstranit špatné návyky. Já chápu u nadšenců do Rustu, že vnímají C jako problematické, to já taky, ale Rust míří evolucí jinam, než C++, už jsem to v jednom příspěvku psal. Znám hodně zhrzených bývalých C++ vývojářů, většinou je to proto, že je to někdo špatně naučil nebo všechno věděli nejlépe nebo obojí a většina z nich vinu za problémy hodili na C++, to že za pomoci tohoto jazyka vytvořili prasečinu si často nedokázali ani připustit, čest vyjímkám.

> Moderní C++ je opravdu veliká množina nástrojů a pokud se chci vyhnout problémům vím co mám použít a jak to mám použít, není to žádná raketová věda, jde o to si to pouze osvojit a odstranit špatné návyky. Já chápu u nadšenců do Rustu, že vnímají C jako problematické, to já taky, ale Rust míří evolucí jinam, než C++, už jsem to v jednom příspěvku psal. Znám hodně zhrzených bývalých C++ vývojářů, většinou je to proto, že je to někdo špatně naučil nebo všechno věděli nejlépe nebo obojí a většina z nich vinu za problémy hodili na C++, to že za pomoci tohoto jazyka vytvořili prasečinu si často nedokázali ani připustit, čest vyjímkám.

Když tedy připustím existenci programátora - supermana, který nedělá chyby a nikdy "neprasí", pořád je zde skutečnost, že většinu produktů píše více lidí a často se udržují spoustu let. A pokud daný jazyk neposkytuje záruky, nedá se na (přinejmenším) cizí kód spolehnout.

Ta věc v C++ vyřešit už z principu nejde bez kompletního zahození zpětné kompatibility a překopání to v něco, co bude úplně nový jazyk - což už je Rust.

Jenže to by ty features musely být v C++ by default, a to by zas rozbilo dosavadní kód.

Jasně chápu, Rust je výjimečný hlavně tím, že programátorovi velkou spoustu věcí zakazuje. To je skvělá featura (ironie).

Vlastně ani nevíš, jak jsi trefil hřebíček na hlavičku.

Jasně chápu, Rust je výjimečný hlavně tím, že programátorovi velkou spoustu věcí zakazuje. To je skvělá featura.

Skoro každý jazyk nad C/C++ ti něco zakazuje.

To je otázka životní filozofie. Prostě jsou typy lidí, které tak trochu uráží, že by je mělo něco hlídat. A pak je jiná skupina lidí, která to umí ocenit a využít ve svůj prospěch.

30. 12. 2024, 18:41 editováno autorem komentáře

A co brání mít v C++ safe sekce?

Přežil jsem i javascriptové "use strict".

To je ta nuance, která vám uniká. :-)

akademická diskuze

No, jestli to někdy standardizační komise schválí..

Ten překladač pro C++ je už dnes tak strašně složitý, že vývojáři mají co dělat, aby dodrželi všechny nuance toho, jak ten kód má chovat. Nemluvě o tom, že to roubování nových chování vyžaduje dost krkolomnou syntaxi.

Pamatuju třeba odpověd Uliho Dreppera na bug report v g++: "Tohle Vám někdy fungovalo? Tak to se omlouvám, už se to nestane." (šlo o nedefinované chování dle standardu, které gcc začalo hlídat)

Tam jde totiž hlavně o přístup. C++ historicky povoluje věci, které jsou sporné a mohou být problematické, vývojář ručí za to co dělá. Rust v takové chvíli naopak hlásí problém, ani unsafe nedovolí obejít všechno.

Chytřejší nástroje vznikají pro oba jazyky (pedantic clippy je až moc přísné i na Rust).

Áno, je to o prístupe. Jedna vec je, čo C++ umožňuje, druhá vec je, čo je odporúčané používať alebo od čoho sú programátori priamo odradzovaní. Vznikajú nové abstrakcie, písaný kód je prehľadnejší a bezpečnejší. A bude sa to iba zlepšovať.

To se z principu nemůže stát.

Kód, který je živý, se přepisuje běžně. Firmy na přepsání peníze mají a u nadšenců zas potřebuješ, aby to bavilo i nové lidi. Rust na některé vývojáře ten efekt má.

No vzhľadom na to, že nie je pozorovateľný úbytok programátorov v C++, tak ten kód sa pravdepodobne neprepisuje do Rustu nijako masívne.

Čo sa toho ostatného týka, tak ja neviem, ale, súdiac podľa rôznych materiálov z oblasti osobného rastu, ľudí asi dosť priťahuje možnosť mať nejaký vplyv, zanechať nejakú stopu, dosiahnuť nejaký výsledok, vedieť, že úsilie nebolo zbytočné, nemusí to byť iba niečo nové, čo sa zdá byť atraktívne.

Ja proti Rustu naozaj nič nemám, ale nenahovárajme si, že to je nástroj, ktorý vyrieši všetky problémy sveta a spasí každého.

"Ja proti Rustu naozaj nič nemám, ale nenahovárajme si, že to je nástroj, ktorý vyrieši všetky problémy sveta a spasí každého."

To netvrdím. Já tvrdím, že Rust zabil C++. Nikdo nikdy mě už nedonutí se k C++ vrátit.

Je zvláštne, že tú smrť C++ nevidno. Sú vývoj alebo rast jej príznakmi? To pochybujem. A k tomu, aby ste sa vrátili k C++ vás predsa nikto neprehováral. Takže to asi uzavriem tým, že si myslím, že najrozumnejšie je povedať si, že uvidíme o niekoľko rokov...

Proč by měl nějaký jazyk umřít. Vždy bude spousta legacy projektů, které se budou udržovat. Klidně desítky let. To je stejné jako s mobily, počítači či auty - důležité je poměr v těch nových prodávaných.

Ja som predsa netvrdil, že C++ zomrelo. To predrečník písal, že Rust zabil C++. A zabitie znamená smrť, nie? Inak C++ tu samozrejme ostane ešte dlho. A čo sa týka pomeru "tých nových predávaných", existuje nejaká štatistika, ktorá by tvrdila, že počet nových projektov v Ruste je vyšší ako počet nových projektov v C++? Ja o tom dosť pochybujem, ale je to samozrejme iba môj osobný názor.

Ono to trvá.

Rust umí navíc být taky složitý (lifetimes..), takže je složitější pro něj najít programátory. Najít někoho, kdo umí základní C a nařídit mu jen MISRA podmnožinu jazyka je snazší a levnější. Obzvláště, pokud už ten projekt nějakou dobu (dekádu..) běží.

C++ s objevením a rozvojem Rustu ztrácí hodně výhod "monopolu".

Býval to jediný rozumný jazyk s dobrými abstrakcemi pro nízkoúrovňové programování. A teď má konkurenci (sice ne jedinou, ale Nim se asi mainstreamem nestane).

C/C++ bylo jediné rozumně certifikované prostredí pro automotive. Rust už je taky (minimálně překladač).

C++ se STL navíc mívalo naprosto příšerné chybové hlášky (ty rozvoje šablon zabraly celé obrazovky.. ano a vím, že existuje preprocesor). Rust chybu ukáže a rovnou vysvětlí co je špatně a jak to opravit (pokud to jde poznat).

Takže já si prošel tím samým. C++11 jsem považoval za dobrý vývoj jazyka, oproti starším revizím to začalo být i hezké. A po pár letech jsem celý projekt přepsal do Rustu. A zpátky mě nikdo nedostane. Ten kód je prostě mnohem čitelnější.

No ja viem, že veci sa nestávajú hneď. A preto som napísal, že uvidíme o niekoľko rokov. Ale koľko rokov už čakáme? 10? Tak si ešte počkajme a predebatujeme stav, ktorý bude aktuálny v tej dobe.

C++ ale rozhodne nespí, naopak, rozvíja sa a motivácia je naozaj veľká.

Napríklad tie vaše chybové hlásenia STL, to je predsa historická záležitosť z doby, keď ešte nejaký Rust vôbec neexistoval. STL priniesla na svoju dobu revolučný spôsob oddelenia spracovania od dát. A to stále s typovou kontrolou.

Bavme sa o súčasných veciach. Chybové hlásenia značne vylepšujú koncepty a v C++26 má byť niečo ako možnosť chybové hlásenia do istej miery definovať kódom.

Zároveň ale nikomu neberiem to, že sa mu v inom jazyku píše kód lepšie. To je absolútne v poriadku.

Ale napriek všetkému, prehlásenia v zmysle, že je C++ mŕtve naozaj nie sú ani náhodou na mieste.

No jestli se dívám správně, tak koncepty jsou až v C++20?

https://en.cppreference.com/w/cpp/language/constraints

Navíc to vyžaduje kód navíc (někdo ty koncepty do těch knihoven musí napsat). Takže to je něco, co mě už nepotkalo no.

Vypadá to jako where v Rustu: https://doc.rust-lang.org/std/keyword.where.html (standardizováno 2014)

Je to určitě krok správným směrem, ty jazyky se vyvíjí všechny.

A protože musím občas řešit více věcí ve více jazycích, tak každou malou divnost ve standardu neznám. Jako třeba ten nullptr po move unique_ptr. Proto jsem rád, že mě překladač upozorní, méně často se střelím do nohy.

Proto pokud můžu použít Rust, tak dnes opravdu preferuji ten.

"Býval to jediný rozumný jazyk s dobrými abstrakcemi pro nízkoúrovňové programování. A teď má konkurenci (sice ne jedinou, ale Nim se asi mainstreamem nestane)."

Existuje ještě Zig. Ale ten mě neoslovil (možná jsem mu nevěnoval dostatečnou pozornost) svou filozofií. Přišlo mi, že je příliš benevolentní a nesympaticky spoléhá na programátora.

I chirurg má blbej den a něco pokazí. Podobně zrovna nedávno ten pilot v Jižní Koreji, který zabil skoro 200 lidí včetně sebe, protože nedokázal rozumně zhodnotit situaci.

Asi mi nebylo rozumnět. Je to samozřejmě o standardech a postupech. Odborníkem se člověk stává, když zná ty správné postupy a standardy. Když ví, jak se věci mají dělat, ne jak si myslí, že se mají dělat. Spousta programuje v C++ ale neumí ho, stejně tak spousta lidí si umí doma zapojit rozvaděč, ale nejsou to elektrikáři. A pak je to o náhodě. Někomu prostě ta elektřina způsobí požár, a ti ostatní mají pak pocit, že oni jsou ti odborníci. Nikdo z nich není, jen měli štěstí.

Být odborník není o štěstí. Odborník ví, jak se věci mají dělat i v případě, že má blbej den. Nepotřebuje štěstí, potřebuje znalosti.

Vypadá to, že jsme tě pochopili správně.

Mluvíš dobře, ale o něčem jiném.

I odborník dle tvé definice může mít špatný den, a udělat blbost. Ba co víc. Čím více se musí snažit, aby byl "odborníkem", tím méně udělá práce. Proto lékaři i ti nejlepší používají ochranné pomůcky, normované léky, atd. Bariéry nejsou proti hlupákům a neodborníkům. Ale proti blbému dni. A navíc to rozvazuje ruce.

Proč myslíš, že má chirurg k ruce tři specialisty? Si myslíš, že by to nezvládl sám? Když by to byl chirurg v duchu C++, znal by všechny správné postupy a standardy, a byl by na to sám. Já raději Rustího chirurga, který možná zná půlku těch standardů, ale kolega mu ve správný okamžik řekne "počkej, co děláš?!".

A tohle přesně C++ neumí a Rust ano.

Zrovna ty standardizované postupy zachraňují v nemocnicích dost pacientů:
https://amie.so/blog/checklist-manifesto-summary

Podobně u programování je dobré, když vás kompilátor klepne přes prsty, než váš kód pojede na produkci. Vyšší jazyky ten problém řeší po svém, ale chyběl tady jazyk pro lowlevel kód s plnou rychlostí (to vyšší jazyky zvládají díky JIT), ale i s nízkou spotřebou RAM (vyšší jazyky ji mají násobně vyšší kvůli automatické správě paměti, což ne všude chcete).

30. 12. 2024, 17:57 editováno autorem komentáře

To mi připomělo, že z Rustu mám dejavů když si vzpomenu na to jak se na přelomu tisíciletí prosazovala Java a jak se tvrdilo, že brzo nahradí všechny ostatní jazyky, zeména pak C (C++ v té době nebyl takový deal).

Mno, skok o 25 let do budoucnosti a kde máme Javu?

Zato já musím trpět, když čtu kód, který napsal nějaký Céčkař. Čekal jsem aspoň, že ti Céčkaři zmizí.

Na Rustu mi vadí, že je to extenze C. Jazyka, který bych nejradši pohřbil hluboko do hlíny. Některé naprosto tragické programátorské postupy, které bych chtěl eliminovat, se v Rustu naopak ještě podporují.

A opět je mi vnucováno, že jednou bude vše v Rustu

V roce 2050 si řekneme

Není Java a C# např. většina kódu ve firmách? C nemůže zmizet, když je to jediné stabilní ABI mezi jazyky.

Já vím, už se to řešilo na listopadovém meetu Rust A C++ programátorů. Bridge mezi těmito jazyky zajistí C zatím nejlépe.

Nevím, jestli mám brečet nebo se smát (zoufale).

30. 12. 2024, 18:22 editováno autorem komentáře

V okamžiku, kdy jsem uviděl Rustí kód, který dokázal fungovat bez runtime jsem pochopil, že je (pro mě) C++ mrtvá záležitost. Proti Rustu není nic, co by mohl nabídnout.

Samozřejmě C++ nevymře, stejně jako neumřelo Cobol, Java, nebo takový ASM. Ale smrskne se na omezené domény - microchipy, brutální optimalizace (kde se dneska ještě píše v čistém ASM?), a samozřejmě legacy.

"který dokázal fungovat bez runtime"

To mi prosím vysvětlete

Spousta vyšších jazyků, i když se překládají do strojáku, tak si sebou tahají vlastní bázovou knihovnu. Někdy je alespoň staticky linkovaná. Ale značně to omezuje použití dotyčného jazyka. Na aplikace dobré. Ale C a C++ míří na low-level, a tam toto není úplně to sympatické. Je možné psát C programy bez stdio. A když jsem viděl, že i toto Rust dokáže, tak mě to dost zaujalo.

Tak že jsou jazyky které potřebují runtime nelze rozporovat.

Nicméně jak C tak C++ dokáže běžet bez runtime. Samozřejmě že operátor new bude nejspíš potřebovat malloc(), ale i tam mám možnost si napsat vlastní verzi. Protože Rust je extenze C, tak bych se nedivil, že i on nebude potřebovat runtime pro omezené použití. Konečně všechno se překládá do LLVM, to ve výsledku vede na jeden společný bajtkód, který se následně překládá do strojového kódu.

Ten program nebude potřebovat runtime, dokud ho nebude potřebovat váš kód. To je snad jasné.

Programoval jsem AVR i ARM mikrořadiče v C++, bez problému. Určitě by to šlo i v Rustu.

"Rust je extenze C"

WTF?

Samotný jazyk C++(core language) runtime nepotřebuje. Vše záleží na překladačí a cílové platformě.

Určitě sis všiml, že jsem nikdy netvrdil opak.

No já to psal proto, že bez knihovny stdio bylo zmíněné jenom C a řeší se zde vztah mezi Rust a C++. Dále by bylo dobré zmínit, že u jazyků, které jsou určeny k přímému přístupu k HW, je volitelný runtime standard.

Stejně to je u Rustu.

Doufám, že nebudu nikdy potřebovat chirurga, který bude potřebovat kolegu, aby mu řekl, že dělá něco, co se nesmí.

Trvám si na svém. Tvůj argument odmítám uznat.

V pořádku. A myslím, že jsem si ujasnili, že já zase upřednostním jiného vývojáře, který bude mít větší cit pro realitu.

Držím palce. Doufám, že na práci toho programátora nenarazím, jako třeba teď jsem trpěl u základní softwarové výbavy pro Arduino, která je zralá na přepsání od základů. Ale o tom mám rozepsaný blogpost na rootu, snad vyjde do konce týdne.

Raději někoho, kdo více reflektuje realitu.

Proto tvrdím, že odborníka aby člověk lupou pohledal.

Odborník si umí příznat, že neumí vše a není neomylný.

Znáte "Vím, že nic nevím?", řekl to takový jeden starý filozof. Sókratés se jmenoval.

Ona se chyba navíc může objevit i při pozdějších úpravách. Předělával jste někdy projekt, který jste rok neviděl? A pořád jste si pamatoval všechny vazby a interní detaily, které jste znal, když jste to kdysi dávno psal?