Ideálny programovací jazyk

[KarelI KarelI]

Naopak od C++11 se o to neni potreba starat a funguje to. Narozdil od GC jazyku jako java navic i deterministicky

Ještě k té deterministické dealokaci - dobře že to zmiňuješ, protože to názorně ukazuje posunuté myšlení C++ programátorů. Deterministická dealokace je sama o sobě zbytečná, řešený problém si ji sám o sobě nežádá. Ovšem v C++  je to způsob, jak uvolnit zdroje, takže se tak používá na vše. Jenže už se nemyslí na to, že to má neblahý vliv na výkon dealokace. Ta kdyby se nedělala pro každý objekt zvlášť, ale pro větší bloky, tak je to mnohem výhodnější a právě to je moment, ve kterém získává GC navrch - uklízí až když je to nutné, což je v běžných scénářích mnohem výhodnější než se starat o každý mazaný objekt.

[Reklama]

[Cikáda]

...a právě to je moment, ve kterém získává GC navrch - uklízí až když je to nutné, což je v běžných scénářích mnohem výhodnější než se starat o každý mazaný objekt.

Čistě z logiky věci, takhle fungující GC by asi nebyl moc výkonný... nutné je to, když paměť chybí, a tudíž buď a) nemáme dost paměti a pak je úplně jedno, jestli jedu RAII, nebo GC, nebo ruční správu b) paměť už měla být uvolněná.

[nula]

Naopak od C++11 se o to neni potreba starat a funguje to. Narozdil od GC jazyku jako java navic i deterministicky

Ještě k té deterministické dealokaci - dobře že to zmiňuješ, protože to názorně ukazuje posunuté myšlení C++ programátorů. Deterministická dealokace je sama o sobě zbytečná, řešený problém si ji sám o sobě nežádá. Ovšem v C++  je to způsob, jak uvolnit zdroje, takže se tak používá na vše. Jenže už se nemyslí na to, že to má neblahý vliv na výkon dealokace. Ta kdyby se nedělala pro každý objekt zvlášť, ale pro větší bloky, tak je to mnohem výhodnější a právě to je moment, ve kterém získává GC navrch - uklízí až když je to nutné, což je v běžných scénářích mnohem výhodnější než se starat o každý mazaný objekt.

Naopak, to je nejvetsi pain GC a to je proc pri serioznim pouziti jsou s Javou obrovske problemy. Nikdy nevis kdy zacne GC uvolnovat a jak velkou kupu pameti. Vede to casto k tomu, ze jakekoli vetsi aplikace se v jave ladi daleko pracneji nez i ve starem C.

[Zabanovaný Anonymní Troll]

Naopak od C++11 se o to neni potreba starat a funguje to. Narozdil od GC jazyku jako java navic i deterministicky

Ještě k té deterministické dealokaci - dobře že to zmiňuješ, protože to názorně ukazuje posunuté myšlení C++ programátorů. Deterministická dealokace je sama o sobě zbytečná, řešený problém si ji sám o sobě nežádá. Ovšem v C++  je to způsob, jak uvolnit zdroje, takže se tak používá na vše. Jenže už se nemyslí na to, že to má neblahý vliv na výkon dealokace. Ta kdyby se nedělala pro každý objekt zvlášť, ale pro větší bloky, tak je to mnohem výhodnější a právě to je moment, ve kterém získává GC navrch - uklízí až když je to nutné, což je v běžných scénářích mnohem výhodnější než se starat o každý mazaný objekt.

Naopak, to je nejvetsi pain GC a to je proc pri serioznim pouziti jsou s Javou obrovske problemy. Nikdy nevis kdy zacne GC uvolnovat a jak velkou kupu pameti. Vede to casto k tomu, ze jakekoli vetsi aplikace se v jave ladi daleko pracneji nez i ve starem C.

Kde jsi v Jave proboha potreboval ladit GC?

[KarelI KarelI]

Ano, ale zdaleka ne všechny musí člověk používat. O tom je C++, neplatím za to, co nepoužívám. A nejkrásnější je na tom, že nikdo nikoho nenutí všechno používat. Takže opravdu se o to programátor starat nemusí.

To co označuješ za výhodu (že se nemusí starat), lze z druhé strany nahlédnout jako nevýhodu (když se nepostará, tak nedostane). Stejně tak platí výkonem za to, že nepoužil co mohl.
Je to hezká teorie, ale v praxi spíš vidím, že C++ programátoři jsou řešením paměti úplně posedlí.

Proč by se nemělo pracovat se samotnými strukturami? Co je "hodnota třídy"?

Tím jsem myslel strukturu na stacku, čili že se chová jako hodnota.

V jiných jazycích nejsou potřeba, ale jiné jazyky většinou neposkytují takový výkon. Ony to ty "jiné jazyky" většinou dělají, ale jaksi "pod kapotou", tudíž když to neudělají dobře, tak to nemám jak ovlivnit.

To je pointa celé mé úvahy, že ten výkon můžu klidně dostat tak, že to napíšu v jazyku, ve kterém nemusím řešit polovinu věcí, protože GC, to mi výrazně zjednoduší kód a ve výsledku to JIT zoptimalizuje líp, než bych to napsal v tom C++.

Tak shared_ptr většinou není moc proč používat. Pokud někdo používá shared_ptr, aby nemusel řešit životnost objektů, tak C++ fakt není pro něj. To je jako kupovat si Ferrari s tím, že s ním budu jezdit po poli...

Teď mi to budeš muset lépe vysvětlit. Na jednu stranu zde čtu, že C++11 výrazně zlepšuje práci s pamětí (a snad chápu jak je to myšleno) a vzápětí říkáš, že shared_ptr není na životnost objektů. K čemu tedy je?

[Reklama]

[KarelI KarelI]

Naopak, to je nejvetsi pain GC a to je proc pri serioznim pouziti jsou s Javou obrovske problemy. Nikdy nevis kdy zacne GC uvolnovat a jak velkou kupu pameti. Vede to casto k tomu, ze jakekoli vetsi aplikace se v jave ladi daleko pracneji nez i ve starem C.

Popravdě jsem nikdy nedělal v Javě nic tak velkého. Zatím mi vždy stačil přístup napsat to jednoduše, hlavně pustit z hlavy poučky o mikro optimalizacích z C++ a v případě problému to zprofilovat.
Docela mě zajímá, jaké charakteristiky má taková větší aplikace u které dělá problém spuštění GC.

[Cikáda]

Ano, ale zdaleka ne všechny musí člověk používat. O tom je C++, neplatím za to, co nepoužívám. A nejkrásnější je na tom, že nikdo nikoho nenutí všechno používat. Takže opravdu se o to programátor starat nemusí.

To co označuješ za výhodu (že se nemusí starat), lze z druhé strany nahlédnout jako nevýhodu (když se nepostará, tak nedostane). Stejně tak platí výkonem za to, že nepoužil co mohl.
Je to hezká teorie, ale v praxi spíš vidím, že C++ programátoři jsou řešením paměti úplně posedlí.

Ano, může to být i nevýhoda. Ale když se nepostará, tak jsme +/- u céčka. Pokud nepoužil, co mohl, tak mu asi nejde primárně o výkon, a pak tedy záleží, co vlastně programátor chce...
Na tom posledním se shodneme.

Proč by se nemělo pracovat se samotnými strukturami? Co je "hodnota třídy"?

Tím jsem myslel strukturu na stacku, čili že se chová jako hodnota.

Tak na stacku se ta paměť moc "manuálně" řešit nemusí, takže spíš nechápu souvislost.

V jiných jazycích nejsou potřeba, ale jiné jazyky většinou neposkytují takový výkon. Ony to ty "jiné jazyky" většinou dělají, ale jaksi "pod kapotou", tudíž když to neudělají dobře, tak to nemám jak ovlivnit.

To je pointa celé mé úvahy, že ten výkon můžu klidně dostat tak, že to napíšu v jazyku, ve kterém nemusím řešit polovinu věcí, protože GC, to mi výrazně zjednoduší kód a ve výsledku to JIT zoptimalizuje líp, než bych to napsal v tom C++.

Ano, i ne. Záleží, jak moc se chce člověk spoléhat na GC. Problém GC bývá i to, že prostě není schopen nejlepšího řešení (už z principu věci). Někdy je problém latence, jindy spotřeba paměti... s RAII i ruční správou toho nejlepšího řešení dosáhnout mohu, pokud to bude potřeba.

Tak shared_ptr většinou není moc proč používat. Pokud někdo používá shared_ptr, aby nemusel řešit životnost objektů, tak C++ fakt není pro něj. To je jako kupovat si Ferrari s tím, že s ním budu jezdit po poli...

Teď mi to budeš muset lépe vysvětlit. Na jednu stranu zde čtu, že C++11 výrazně zlepšuje práci s pamětí (a snad chápu jak je to myšleno) a vzápětí říkáš, že shared_ptr není na životnost objektů. K čemu tedy je?

Tak nějak doufám, že je to pozdní hodinou a ne tím, že by sis myslel, že

"Pokud někdo používá shared_ptr, aby nemusel řešit životnost objektů..."

je stejné jako

shared_ptr není na životnost objektů

.

Problém je, že pokud někdo používá shared_ptr místo unique_ptr, resp. používá shared_ptr tak, že nechce řešit, kde co alokoval, jaká je scope a že by tedy občas měl udělat nějaký move, tak není C++ pro něj. To se to pak může fakt psát v té Javě.
Jen podotýkám, že nejsem žádný expert na C++, ale moc si nevzpomínám, kdy bych byl nucen použít shared_ptr.

[KarelI KarelI]

Problém je, že pokud někdo používá shared_ptr místo unique_ptr, resp. používá shared_ptr tak, že nechce řešit, kde co alokoval, jaká je scope a že by tedy občas měl udělat nějaký move, tak není C++ pro něj. To se to pak může fakt psát v té Javě.
Jen podotýkám, že nejsem žádný expert na C++, ale moc si nevzpomínám, kdy bych byl nucen použít shared_ptr.

Nemyslím to v situacích, kde by šel shared_ptr nahradit pomocí unique nebo move apod. Já se s tím běžně setkávám u grafových algoritmů, kde prostě není jeden vlastník objektu, ale je jich víc rovnocenných. V takovém případě buď použiju shared a daný objekt zmizí s posledním vlastníkem nebo bych si to musel evidovat někde bokem.

[alex6bbc]

Myslim, ze to je v Rustu, i kdyz jsem o rom cetl jen letmo, ze = pro objekty je automaticky move. To se mi libi oproti c++.

[Cikáda]

Problém je, že pokud někdo používá shared_ptr místo unique_ptr, resp. používá shared_ptr tak, že nechce řešit, kde co alokoval, jaká je scope a že by tedy občas měl udělat nějaký move, tak není C++ pro něj. To se to pak může fakt psát v té Javě.
Jen podotýkám, že nejsem žádný expert na C++, ale moc si nevzpomínám, kdy bych byl nucen použít shared_ptr.

Nemyslím to v situacích, kde by šel shared_ptr nahradit pomocí unique nebo move apod. Já se s tím běžně setkávám u grafových algoritmů, kde prostě není jeden vlastník objektu, ale je jich víc rovnocenných. V takovém případě buď použiju shared a daný objekt zmizí s posledním vlastníkem nebo bych si to musel evidovat někde bokem.

Tak je otázkou, jestli by se měly vrcholy vlastnit mezi sebou... U stromů to není problém, ale tam není problém použít unique_ptr. U jiných grafů si dovedu představit, že si je všechny držím v nějaké struktuře a mezi sebou mají jen pointery, nebo seznam id ostatních vrcholů. Se shared_ptr by mohl být problém např. u cyklů, když nad tím přemýšlím...

[alex6bbc]

Proti cyklum s shared_ptr slouzi weak ptr.

[Mirek Prýmek]

Myslim, ze to je v Rustu, i kdyz jsem o rom cetl jen letmo, ze = pro objekty je automaticky move. To se mi libi oproti c++.

Jo, ale jenom pokud pro typ není definován trait Copy.

Viz https://doc.rust-lang.org/std/marker/trait.Copy.html a https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html - hlavně část "Ways Variables and Data Interact: Move" a následující.

[Mirek Prýmek]

Na to jsem myslel, proto jsem měl napsat, že jediná správná syntax je prefixová, čili

Kód: [Vybrat]

int i = 0Z dokumentace zrovna vidim

Kód: [Vybrat]

var i, j int = 1, 2vždyť to je strašný.

Vůbec to není strašný, je to jenom ze začátku nezvyk, který ale člověk rychle překoná. Rozhodně je to nekonečně lepší syntax než céčkový "zápis do spirály" (šnekfixový zápis? ), což je naprostá zhůvěřilost, která nikdy neměla vzniknout.

Dále už bylo mnoho napsáno o řešení výjimečných stavů v go...

Go má spoustu ujetostí a v praktickém používání mě hodně zklamalo, ale to, co jsi psal, prostě celkem přesně sedí

[Mirek Prýmek]

ale to, co jsi psal, prostě celkem přesně sedí

P.S. já osobně bych od moderního jazyka chtěl spíš věci jako:

1. má dobře vyřešenou správu balíčků a jejich závislostí
2. má aspoň nějakou formu generik nebo jiný mocný mechanismus psaní abstraktního kódu
3. má homoikonická makra (ale v dokumentaci je palcovým písmem napsáno, že se nemají zneužívat tam, kde opravdu nejsou potřeba)
4. má pattern matching
5. překladač se snaží seč může odhalit chyby při překladu (a jazyk mu v tom jde naproti)
6. vůbec nemá null, místo něj je Option
7. má alespoň jednoduché algebraické typy

...což jsou přesně painpointy Gočka...

Příklad pokročílé vlastnosti ad 1: Elm umí sám detekovat změnu API a vynutí povýšení sémantické verze při pushnutí balíčku.

ad 5: například relativně jednoduchá, ale strašně užitečná featura překladače, je kontrola vyčerpávajícnosti pattern matchingu (např. když matchuju enum, musím pokrýt všechny zadefinované varianty).

ad 6: Option "navíc", jako možnost, což u některých jazyků je, je k ničemu - pokud je null "občas někde", musím ho čekat všude a tímpádem Option ztrácí význam.

ad 7: stačí jednoduché sum a product types (sorry, nevím, jak se "product type" překládá do češtiny). Praktické hlavně pro jednoduché použití silně typovaných tuples. Praktičnost vylítne do nebes ve spojení s pattern matchingem.


...takže mi do toho sedí spíš Rust než Go

[Cikáda]

3. má homoikonická makra (ale v dokumentaci je palcovým písmem napsáno, že se nemají zneužívat tam, kde opravdu nejsou potřeba)

Teď to neber špatně, ale když jsme tu diskutovali o JavaScriptu, tak standard ani dokumentace nebyly směrodatné, tak mě překvapuje, že máš potřebu to psát do dokumentace.

ad 6: Option "navíc", jako možnost, což u některých jazyků je, je k ničemu - pokud je null "občas někde", musím ho čekat všude a tímpádem Option ztrácí význam.

Souhlasím. Co takové std::optional v C++ ? To je taky "option navíc", nebo je to trošku dál?