Vlákno názorů k článku
Interaktivní shell Fish přechází z C++ na Rust od Wavelet - To zdůvodnění mi přijde jako v polovině 90....

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é.

Tohle přirovnání je absolutně mimo. ...

Vo vašom svete sa kód sa píše tak, že všetky časti sú rovnako slabé, alebo že všetky časti majú rovnaký objem, alebo že všetky časti bežia rovnako dlhý čas, že všetky časti sú rovnako vyťažené? Zároveň všetci programátori pracujúci na projekte sú rovnako schopní alebo neschopní a majú v rámci projektu všetci rovnaké rozhodovacie práva? O tom veľmi silne pochybujem. Tak prečo si myslíte, že sa tak píše kód v 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é.

Takže vo všetkých projektoch v Ruste sa používajú iba knižnice, ktoré sú napísané v Ruste? O tom tiež veľmi silne pochybujem. A čo sa robí v Ruste, aby sa dali knižnice napísané v iných jazykoch použiť? Myslím si, že presne to isté, čo sa dá urobiť v C++. A mimochom je to všeobecne odporúčané pre prácu s cudzími knižnicami, aj s iných dôvodov ako je bezpečnosť.

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.

Dekády? Samostaný jazyk v úvodzovkách? Naozaj píšeme o tom istom C++?

1979: "C with Classes"
1983: premenované na C++ a prvé komerčné vydanie

C malo pre C++ rovnakú úlohu ako má JavaScript pre TypeScript.

Myslím věci nad rámec samotného přidání tříd, např. standardní knihovna funkcí:

"History. The std::string type is the main string datatype in standard C++ since 1998, but it was not always part of C++. From C, C++ inherited the convention of using null-terminated strings that are handled by a pointer to their first element, and a library of functions that manipulate such strings."

"In a 1991 retrospective on the history of C++, its inventor Bjarne Stroustrup called the lack of a standard string type (and some other standard types) in C++ 1.0 the worst mistake he made in its development; "the absence of those led to everybody re-inventing the wheel and to an unnecessary diversity in the most fundamental classes"."

https://www.google.com/search?q=std+string+c%2B%2B+when+it+was+created

2. 1. 2025, 14:16 editováno autorem komentáře

Chápem, takže ste spojili dve veci, ktoré sa stali v dvoch rôznych obdobiach do jednej vety týkajúcej sa neskoršieho časového obdobia z pôvodných dvoch, predpokladám, že z dôvodu jednoduchšieho písania.

Inak to, že neexistoval reťazec v štandardnej knižnici, neznamená že neexistovalo x rôznych implementácií reťazcov v rôznych iných knižniciach. Ale to nie je až také podstatné.

Dnes se považuje C++ za samostatný jazyk od C, proto se někteří čílí, když někdo napíše "C/C++". Ale po desetiletí C++ sloužilo k objektovému programování, ale samo žádné funkce nemělo - volali jste funkce z C.

Chápem, podľa vás robí jazyk samostantým jazykom to, keď používa iba knižnice napísané v tom jazyku a nie vyjadrovacie schopnosti, ktoré poskytuje jeho syntax.

Ty vyjadřovací schopnosti v první verzi C++ zvládla C makra. Ano, pojetí jazyka je dnes již jiné. Bez standardní knihovny je to jen pokus studentíka a velká část vyjadřovacích schopností je jen syntaktický cukr.

To je zvláštne, že ten pokus študentíka sa celkom ujal a tie vami spomenuté dekády na ňom stála a ešte stále stojí podstatná časť tohto sveta.

velká část vyjadřovacích schopností je jen syntaktický cukr

Bez ktorého si ani v Ruste nedokážete predstaviť život, lebo vám dramaticky sprehľadňuje kód a umožňuje vidieť veci, ktoré by ste inak nevideli.

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.

Když tedy připustím existenci programátora - supermana ...

Programátor - superman je niekto, kto sa spolieha na to, že neurobí chybu alebo niekto, kto používa všetky nástroje, teda aj tie, ktoré nad rámec prekladača kontrolujú kód, prípadne aj jeho vykonávanie, či kód neobsahuje chyby?

... nedá se na (přinejmenším) cizí kód spolehnout

V rámci jednej organizácie cudzí kód neexistuje. A čo sa knižníc týka, platia rovnaké pravidlá ako pre knižnice, ktoré boli napísané v iných jazykoch a sú používané v Ruste.

A když budeš mít toho supermana, který použije všechny nástroje etc - dostane se na úroveň Rustu? Velmi, velmi, velmi možná.

Stále tu hraje tu roli nepochopení zásadního rozdílu v paradigmatu C++ versus Rust.

A když budeš mít toho supermana

Ja som tu začal písať niečo o supermanoch? Čítate diskusiu opäť od stredu a nie od začiatku?

Stále tu hraje tu roli nepochopení zásadního rozdílu

Áno, ale na vašej strane, nie na mojej.

Jsem z toho úplně nepochopil, zda ti tedy dochází ty důsledky.

Pointa je v tom, že to zatiaľ žiadne dôsledky nemá. C++ nikto nezakázal. A keby naozaj hrozilo, že sa to naozaj stane, tak tí, ktorí bránia tomu, aby C++ stratilo spätnú kompatibilitu ustúpia spoločenskej požiadavke, pretože síce majú kvantá kódu ktorý budú musieť prepisovať, čomu sa zatiaľ bránili, ale keby hrozilo, že ich investícia do doterajšieho kódu bude jeho zákazom alebo zákazom jeho ďalšieho rozvoja znehodnotená, rozhodnú sa skôr pre prepísanie do bezpečnejšej verzie toho istého jazyka, ako do úplne nesúvisiaceho jazyka.

Zase nepanikařte. Nikdo tu netvrdí, že C++ někdo chce zakázat. Vaši práci vám nikdo nevezme. Jen už to nebudou nové aplikace. A pravděpodobně přijdete o spoustu již existujících. Ale legacy je věčné.

C++ jen přišlo o svůj monopol na svou doménu. Už není nejlepší.

Vy ma fakt bavíte. Čoraz viac...

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.

To nebude nový jazyk. Bude to kombinácia vybranej podmnožiny existujúceho jazyka s možnosťou výberu správania sa v problematických oblastiach a s novoimplemento­vanými funkcionalitami, abstrakciami, knižnicami a nástrojmi. A ten jazyk sa bude stále volať C++.

Jo, ale např. místo std:: budu muset vše předělat na std2::, plus zjistit odlišnosti chování nových tříd.

Ja osobne si myslím, že dá celkom rozumne predpokladať, že to bude dokumentované. Jedine že by ste mali veľký problém veriť dokumentácii.

Ako aj to, že na niektoré modernizácie, zvlášť tie, ktoré uvádzate, budú nástroje. A ak nebudú, tak že sa budú dať urobiť. Možno dokonca veľmi jednoducho. Tak ako sa to robí už teraz.

Jenže v tu chvíli už bude jedno, jestli to přepíšu do "Safe C++ profile B extra" nebo jiného jazyka. Prostě se daný vývojář nebo firma bude muset naučit kompletně novou sadu pravidel a doporučení.

Tím, že zachováte jméno a napíšete dokumentaci nezajistíte adopci. V tu chvíli mám tudíž volnost se rozhodnout i pro libovolné jiné řešení. Změna to bude každopádně.

A základom pre rozhodovanie bude to, čo sa v danej chvíli ukáže ako jednoduchšie a lacnejšie pri porovnateľnom výsledku.