Jak efektivně studovat programování?

[Jiří Havel]

Pokud může házet úplně všechno, pak se dost blbě udržujou invarianty objektů. Daleko lepší je házející kus a pak commit co nic házet nesmí. Při čtení kódu ale jednoduše nepoznám, kde zrovna jsem.

Můžeš to prosím rozvést?

Myslel jsem konkrétně "strong exception safety". Takže operace buď projde, nebo se komplet rollbackne. To se obvykle dělá tak, že se spočítá celý nový stav a ten se pak swapne s tím starým. Výpočet nového stavu může házet podle libosti, ale swap nesmí. A teď jak zaručit že nic v tom swapu nehází.

Pokud může házet cokoliv, tak se dá maximálně dosáhnout "basic exception safety". Takže po vyhození výjimky nic neleakuje, ale stav je nějak změněný a musím si ho nějak vyresetovat. Jo, invarianty jednotlivých objektů jsou obvykle ok. To jsem napsal trochu blbě. Myslel jsem spíš něco jako návrat programu do stavu před (high level) operací, co tu výjimku vyhodila.

Takže problém je v tom, že potřebuju bloky kódu o kterých si můžu být jistý že nehází. Můžu zkontrolovat jednotlivé funkce a ověřit podle typu nebo dokumentace. Ale tuhle tupou mechanickou činnost bych rád nějak přehodil na překladač. Navíc to není při letmém čtení kódu nijak vidět. Můžu přidat komentář, který kus nehází, ale ten co do toho bude koukat po mně stejně neví, jestli tomu komentáři může věřit.
Ani checked exceptions to zas tak moc neřeší. U nich vím co může z funkce lítat, ale pokud chci vědět i odkud, tak musím hledat.

Zrovna chyby jsou místo, kde je pomoc překladače obzvlášť potřeba. Protože řešení chyb a nestandardních situací je vždycky ten nejmíň otestovaný a nejvíc zabugovaný kus projektu. A to díky tomu, že jsou ty situace vzácné.

[Reklama]

[BoneFlute]

Pokud může házet úplně všechno, pak se dost blbě udržujou invarianty objektů. Daleko lepší je házející kus a pak commit co nic házet nesmí. Při čtení kódu ale jednoduše nepoznám, kde zrovna jsem.

Můžeš to prosím rozvést?

Myslel jsem konkrétně "strong exception safety". Takže operace buď projde, nebo se komplet rollbackne. To se obvykle dělá tak, že se spočítá celý nový stav a ten se pak swapne s tím starým. Výpočet nového stavu může házet podle libosti, ale swap nesmí. A teď jak zaručit že nic v tom swapu nehází.

Pokud může házet cokoliv, tak se dá maximálně dosáhnout "basic exception safety". Takže po vyhození výjimky nic neleakuje, ale stav je nějak změněný a musím si ho nějak vyresetovat. Jo, invarianty jednotlivých objektů jsou obvykle ok. To jsem napsal trochu blbě. Myslel jsem spíš něco jako návrat programu do stavu před (high level) operací, co tu výjimku vyhodila.

Takže problém je v tom, že potřebuju bloky kódu o kterých si můžu být jistý že nehází. Můžu zkontrolovat jednotlivé funkce a ověřit podle typu nebo dokumentace. Ale tuhle tupou mechanickou činnost bych rád nějak přehodil na překladač. Navíc to není při letmém čtení kódu nijak vidět. Můžu přidat komentář, který kus nehází, ale ten co do toho bude koukat po mně stejně neví, jestli tomu komentáři může věřit.
Ani checked exceptions to zas tak moc neřeší. U nich vím co může z funkce lítat, ale pokud chci vědět i odkud, tak musím hledat.

Zrovna chyby jsou místo, kde je pomoc překladače obzvlášť potřeba. Protože řešení chyb a nestandardních situací je vždycky ten nejmíň otestovaný a nejvíc zabugovaný kus projektu. A to díky tomu, že jsou ty situace vzácné.

Děkuji za příspěvek.

Na jednu stranu je to co píšeš dost inspirativní. Na druhou stranu si nejsem úplně jist, zda tě dobře chápu.

Cítím v tvém popisu defer z Go. Taky mi přijde, že mluvíš vlastně o určité podobě transakcí - kód změní stav, a pokud vznikne chyba, tak se vrátí původní stav. Je to to co myslíš? Jak se práce se stavem promítne do věcí jako side effects (zapisování do souboru, posílání emailu)? Nechtěl by si napsat nějakou ukázku kódu, jak by to mělo fugovat?

To co popisuješ, existuje to v nějakém jazyce, nebo je to jen studie/úvaha?

Dělal jsem si jednu studii, kdy jsem měl jazyk, který si jednak hlídal při kompilaci, zda jsou všechny scénáře pokryty, zda nemůže dojít k nějaké neošetřené chybě. A dále si při každém spuštění apky kontroloval, zda jsou dostupné externí závislosti (nainstalované knihovny, dostupné externí rutiny/binárky, dostupnost k databázi, filesystému). Čímž jsem chtěl zajistit, aby vlastní běh té aplikace nemohl selhat.

[Jiří Havel]

Děkuji za příspěvek.

Na jednu stranu je to co píšeš dost inspirativní. Na druhou stranu si nejsem úplně jist, zda tě dobře chápu.

Cítím v tvém popisu defer z Go. Taky mi přijde, že mluvíš vlastně o určité podobě transakcí - kód změní stav, a pokud vznikne chyba, tak se vrátí původní stav. Je to to co myslíš? Jak se práce se stavem promítne do věcí jako side effects (zapisování do souboru, posílání emailu)? Nechtěl by si napsat nějakou ukázku kódu, jak by to mělo fugovat?

To co popisuješ, existuje to v nějakém jazyce, nebo je to jen studie/úvaha?

Dělal jsem si jednu studii, kdy jsem měl jazyk, který si jednak hlídal při kompilaci, zda jsou všechny scénáře pokryty, zda nemůže dojít k nějaké neošetřené chybě. A dále si při každém spuštění apky kontroloval, zda jsou dostupné externí závislosti (nainstalované knihovny, dostupné externí rutiny/binárky, dostupnost k databázi, filesystému). Čímž jsem chtěl zajistit, aby vlastní běh té aplikace nemohl selhat.

Jestli by měl z mého příspěvku být cítit nějaký jazyk, tak C++. O exception safety se primárně mluví právě v souvislosti s c++ i když je to obecnější koncept. Ale právě v c++ je tohle uvažování vcelku běžné. Strong exception safety jsou transakce, jen se neřeší atomičnost z pohledu jiných vláken.

Zápis do souboru jako transakce je myslím poměrně známý postup :
- Vytvořím pomocný soubor zapíšu ho a flushnu na disk. Pokud tohle selže, pak je původní soubor stále netknutý.
- Přejmenuju pomocný soubor. Pokud má tahle operace strong exception safety, pak ji bude mít i celý zápis souboru.

A stejně se dá uvažovat i o jednotlivých objektech programu. Např při přidávání do dynamického pole mi může selhat alokace, nebo kopírování nějakého objektu. Takže alokuju nový kus paměti, všechno do něj nakopíruju a nakonec swapnu odkaz na nový blok paměti.

Obecně pokud mám swap, který dokáže prohodit vnitřnosti objektů bez možných výjimek, pak se na tom dá stavět transakční chování pro větší a větší bloky programu. A dobrým zvykem je, pokud je to možné, dávat vlastním objektům rozumný swap který jen prohodí ukazatele a nemůže házet.

[BoneFlute]

Děkuji za příspěvek.

Na jednu stranu je to co píšeš dost inspirativní. Na druhou stranu si nejsem úplně jist, zda tě dobře chápu.

Cítím v tvém popisu defer z Go. Taky mi přijde, že mluvíš vlastně o určité podobě transakcí - kód změní stav, a pokud vznikne chyba, tak se vrátí původní stav. Je to to co myslíš? Jak se práce se stavem promítne do věcí jako side effects (zapisování do souboru, posílání emailu)? Nechtěl by si napsat nějakou ukázku kódu, jak by to mělo fugovat?

To co popisuješ, existuje to v nějakém jazyce, nebo je to jen studie/úvaha?

Dělal jsem si jednu studii, kdy jsem měl jazyk, který si jednak hlídal při kompilaci, zda jsou všechny scénáře pokryty, zda nemůže dojít k nějaké neošetřené chybě. A dále si při každém spuštění apky kontroloval, zda jsou dostupné externí závislosti (nainstalované knihovny, dostupné externí rutiny/binárky, dostupnost k databázi, filesystému). Čímž jsem chtěl zajistit, aby vlastní běh té aplikace nemohl selhat.

Jestli by měl z mého příspěvku být cítit nějaký jazyk, tak C++. O exception safety se primárně mluví právě v souvislosti s c++ i když je to obecnější koncept. Ale právě v c++ je tohle uvažování vcelku běžné. Strong exception safety jsou transakce, jen se neřeší atomičnost z pohledu jiných vláken.

Zápis do souboru jako transakce je myslím poměrně známý postup :
- Vytvořím pomocný soubor zapíšu ho a flushnu na disk. Pokud tohle selže, pak je původní soubor stále netknutý.
- Přejmenuju pomocný soubor. Pokud má tahle operace strong exception safety, pak ji bude mít i celý zápis souboru.

A stejně se dá uvažovat i o jednotlivých objektech programu. Např při přidávání do dynamického pole mi může selhat alokace, nebo kopírování nějakého objektu. Takže alokuju nový kus paměti, všechno do něj nakopíruju a nakonec swapnu odkaz na nový blok paměti.

Obecně pokud mám swap, který dokáže prohodit vnitřnosti objektů bez možných výjimek, pak se na tom dá stavět transakční chování pro větší a větší bloky programu. A dobrým zvykem je, pokud je to možné, dávat vlastním objektům rozumný swap který jen prohodí ukazatele a nemůže házet.

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Jak by vypadala syntaxe?

[Idris]

Děkuji za příspěvek.

Na jednu stranu je to co píšeš dost inspirativní. Na druhou stranu si nejsem úplně jist, zda tě dobře chápu.

Cítím v tvém popisu defer z Go. Taky mi přijde, že mluvíš vlastně o určité podobě transakcí - kód změní stav, a pokud vznikne chyba, tak se vrátí původní stav. Je to to co myslíš? Jak se práce se stavem promítne do věcí jako side effects (zapisování do souboru, posílání emailu)? Nechtěl by si napsat nějakou ukázku kódu, jak by to mělo fugovat?

To co popisuješ, existuje to v nějakém jazyce, nebo je to jen studie/úvaha?

Dělal jsem si jednu studii, kdy jsem měl jazyk, který si jednak hlídal při kompilaci, zda jsou všechny scénáře pokryty, zda nemůže dojít k nějaké neošetřené chybě. A dále si při každém spuštění apky kontroloval, zda jsou dostupné externí závislosti (nainstalované knihovny, dostupné externí rutiny/binárky, dostupnost k databázi, filesystému). Čímž jsem chtěl zajistit, aby vlastní běh té aplikace nemohl selhat.

Jestli by měl z mého příspěvku být cítit nějaký jazyk, tak C++. O exception safety se primárně mluví právě v souvislosti s c++ i když je to obecnější koncept. Ale právě v c++ je tohle uvažování vcelku běžné. Strong exception safety jsou transakce, jen se neřeší atomičnost z pohledu jiných vláken.

Zápis do souboru jako transakce je myslím poměrně známý postup :
- Vytvořím pomocný soubor zapíšu ho a flushnu na disk. Pokud tohle selže, pak je původní soubor stále netknutý.
- Přejmenuju pomocný soubor. Pokud má tahle operace strong exception safety, pak ji bude mít i celý zápis souboru.

A stejně se dá uvažovat i o jednotlivých objektech programu. Např při přidávání do dynamického pole mi může selhat alokace, nebo kopírování nějakého objektu. Takže alokuju nový kus paměti, všechno do něj nakopíruju a nakonec swapnu odkaz na nový blok paměti.

Obecně pokud mám swap, který dokáže prohodit vnitřnosti objektů bez možných výjimek, pak se na tom dá stavět transakční chování pro větší a větší bloky programu. A dobrým zvykem je, pokud je to možné, dávat vlastním objektům rozumný swap který jen prohodí ukazatele a nemůže házet.

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

[Reklama]

[BoneFlute]

Děkuji za příspěvek.

Na jednu stranu je to co píšeš dost inspirativní. Na druhou stranu si nejsem úplně jist, zda tě dobře chápu.

Cítím v tvém popisu defer z Go. Taky mi přijde, že mluvíš vlastně o určité podobě transakcí - kód změní stav, a pokud vznikne chyba, tak se vrátí původní stav. Je to to co myslíš? Jak se práce se stavem promítne do věcí jako side effects (zapisování do souboru, posílání emailu)? Nechtěl by si napsat nějakou ukázku kódu, jak by to mělo fugovat?

To co popisuješ, existuje to v nějakém jazyce, nebo je to jen studie/úvaha?

Dělal jsem si jednu studii, kdy jsem měl jazyk, který si jednak hlídal při kompilaci, zda jsou všechny scénáře pokryty, zda nemůže dojít k nějaké neošetřené chybě. A dále si při každém spuštění apky kontroloval, zda jsou dostupné externí závislosti (nainstalované knihovny, dostupné externí rutiny/binárky, dostupnost k databázi, filesystému). Čímž jsem chtěl zajistit, aby vlastní běh té aplikace nemohl selhat.

Jestli by měl z mého příspěvku být cítit nějaký jazyk, tak C++. O exception safety se primárně mluví právě v souvislosti s c++ i když je to obecnější koncept. Ale právě v c++ je tohle uvažování vcelku běžné. Strong exception safety jsou transakce, jen se neřeší atomičnost z pohledu jiných vláken.

Zápis do souboru jako transakce je myslím poměrně známý postup :
- Vytvořím pomocný soubor zapíšu ho a flushnu na disk. Pokud tohle selže, pak je původní soubor stále netknutý.
- Přejmenuju pomocný soubor. Pokud má tahle operace strong exception safety, pak ji bude mít i celý zápis souboru.

A stejně se dá uvažovat i o jednotlivých objektech programu. Např při přidávání do dynamického pole mi může selhat alokace, nebo kopírování nějakého objektu. Takže alokuju nový kus paměti, všechno do něj nakopíruju a nakonec swapnu odkaz na nový blok paměti.

Obecně pokud mám swap, který dokáže prohodit vnitřnosti objektů bez možných výjimek, pak se na tom dá stavět transakční chování pro větší a větší bloky programu. A dobrým zvykem je, pokud je to možné, dávat vlastním objektům rozumný swap který jen prohodí ukazatele a nemůže házet.

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)

[Ink]

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)

No podle mě zas tak ne. Třeba v Haskellu je kód s efekty oddělený od kódu bez efektů. Takže by, teoreticky, napřed došlo k výpočtu finálního stavu a pokud by výpočet prošel, došlo by k jeho zápisu. Že by ten zápis byl chráněn transakcí, je jasné, ale to už by si ta low level část systému musela pohlídat sama...

[Idris]

Děkuji za příspěvek.

Na jednu stranu je to co píšeš dost inspirativní. Na druhou stranu si nejsem úplně jist, zda tě dobře chápu.

Cítím v tvém popisu defer z Go. Taky mi přijde, že mluvíš vlastně o určité podobě transakcí - kód změní stav, a pokud vznikne chyba, tak se vrátí původní stav. Je to to co myslíš? Jak se práce se stavem promítne do věcí jako side effects (zapisování do souboru, posílání emailu)? Nechtěl by si napsat nějakou ukázku kódu, jak by to mělo fugovat?

To co popisuješ, existuje to v nějakém jazyce, nebo je to jen studie/úvaha?

Dělal jsem si jednu studii, kdy jsem měl jazyk, který si jednak hlídal při kompilaci, zda jsou všechny scénáře pokryty, zda nemůže dojít k nějaké neošetřené chybě. A dále si při každém spuštění apky kontroloval, zda jsou dostupné externí závislosti (nainstalované knihovny, dostupné externí rutiny/binárky, dostupnost k databázi, filesystému). Čímž jsem chtěl zajistit, aby vlastní běh té aplikace nemohl selhat.

Jestli by měl z mého příspěvku být cítit nějaký jazyk, tak C++. O exception safety se primárně mluví právě v souvislosti s c++ i když je to obecnější koncept. Ale právě v c++ je tohle uvažování vcelku běžné. Strong exception safety jsou transakce, jen se neřeší atomičnost z pohledu jiných vláken.

Zápis do souboru jako transakce je myslím poměrně známý postup :
- Vytvořím pomocný soubor zapíšu ho a flushnu na disk. Pokud tohle selže, pak je původní soubor stále netknutý.
- Přejmenuju pomocný soubor. Pokud má tahle operace strong exception safety, pak ji bude mít i celý zápis souboru.

A stejně se dá uvažovat i o jednotlivých objektech programu. Např při přidávání do dynamického pole mi může selhat alokace, nebo kopírování nějakého objektu. Takže alokuju nový kus paměti, všechno do něj nakopíruju a nakonec swapnu odkaz na nový blok paměti.

Obecně pokud mám swap, který dokáže prohodit vnitřnosti objektů bez možných výjimek, pak se na tom dá stavět transakční chování pro větší a větší bloky programu. A dobrým zvykem je, pokud je to možné, dávat vlastním objektům rozumný swap který jen prohodí ukazatele a nemůže házet.

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)

Přesně to jsem myslel

[Idris]

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)

No podle mě zas tak ne. Třeba v Haskellu je kód s efekty oddělený od kódu bez efektů. Takže by, teoreticky, napřed došlo k výpočtu finálního stavu a pokud by výpočet prošel, došlo by k jeho zápisu. Že by ten zápis byl chráněn transakcí, je jasné, ale to už by si ta low level část systému musela pohlídat sama...

To “zahodit” znamená, že výpočet se v monádě dostane na vedlejší kolej. Ten kód oddělený není, jen pracuje v rámci složitějšího typového systému. BoneFlute má pravdu, že to je v podstatě zdarma.

[Ink]

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)

No podle mě zas tak ne. Třeba v Haskellu je kód s efekty oddělený od kódu bez efektů. Takže by, teoreticky, napřed došlo k výpočtu finálního stavu a pokud by výpočet prošel, došlo by k jeho zápisu. Že by ten zápis byl chráněn transakcí, je jasné, ale to už by si ta low level část systému musela pohlídat sama...

To “zahodit” znamená, že výpočet se v monádě dostane na vedlejší kolej. Ten kód oddělený není, jen pracuje v rámci složitějšího typového systému. BoneFlute má pravdu, že to je v podstatě zdarma.

Však já polemizuju pouze s tím "Tady trochu provokuju". "kód oddělený není, jen pracuje v rámci složitějšího typového systému" - není to slovíčkaření? Prostě se ví, která funkce má efekty a která ne a dokud se výpočet dělá v bezefektové funkci, víme, že výsledek se může zahodit.

[Idris]

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)

No podle mě zas tak ne. Třeba v Haskellu je kód s efekty oddělený od kódu bez efektů. Takže by, teoreticky, napřed došlo k výpočtu finálního stavu a pokud by výpočet prošel, došlo by k jeho zápisu. Že by ten zápis byl chráněn transakcí, je jasné, ale to už by si ta low level část systému musela pohlídat sama...

To “zahodit” znamená, že výpočet se v monádě dostane na vedlejší kolej. Ten kód oddělený není, jen pracuje v rámci složitějšího typového systému. BoneFlute má pravdu, že to je v podstatě zdarma.

Však já polemizuju pouze s tím "Tady trochu provokuju". "kód oddělený není, jen pracuje v rámci složitějšího typového systému" - není to slovíčkaření? Prostě se ví, která funkce má efekty a která ne a dokud se výpočet dělá v bezefektové funkci, víme, že výsledek se může zahodit.

Možná jsem jen úplně nepochopil komentář o tom rozdělení.

Nicméně zajímavější jsou ty “efekty,” to s tím zahazováním je tedy rollback? A co je pak commit? Jakému typovému operátoru odpovídá? Podle mě je tohle všechno ve FP plně transparentní, ale možná mi něco uniká.

[BoneFlute]

Takže jsi myslel trasakčnost na úrovni jazyka a to včetně externích závislostí. Zajímavé.

Zajímavé je, jak by se něco takového provedlo v čistě funkcionálním kódu.

To mi moc zajímavé nepřijde. Funkcionální kód nemá efekty. Tudíž transakce je jednoduchá - zahodit ;-) (Tady trochu provokuju.)

No podle mě zas tak ne. Třeba v Haskellu je kód s efekty oddělený od kódu bez efektů. Takže by, teoreticky, napřed došlo k výpočtu finálního stavu a pokud by výpočet prošel, došlo by k jeho zápisu. Že by ten zápis byl chráněn transakcí, je jasné, ale to už by si ta low level část systému musela pohlídat sama...

To “zahodit” znamená, že výpočet se v monádě dostane na vedlejší kolej. Ten kód oddělený není, jen pracuje v rámci složitějšího typového systému. BoneFlute má pravdu, že to je v podstatě zdarma.

Však já polemizuju pouze s tím "Tady trochu provokuju". "kód oddělený není, jen pracuje v rámci složitějšího typového systému" - není to slovíčkaření? Prostě se ví, která funkce má efekty a která ne a dokud se výpočet dělá v bezefektové funkci, víme, že výsledek se může zahodit.

Možná jsem jen úplně nepochopil komentář o tom rozdělení.

Nicméně zajímavější jsou ty “efekty,” to s tím zahazováním je tedy rollback? A co je pak commit? Jakému typovému operátoru odpovídá? Podle mě je tohle všechno ve FP plně transparentní, ale možná mi něco uniká.

@Ink defakto přesně pochopil mou provokaci. (IO) Monády ve FP (nebo jakákoliv jejich alternativa) jsou přesně ta část jazyka, která není funkcionální. Tudíž nesplňuje zadání :-)

Vezmu-li čistě funkcionální kód, tak ten je v okamžiku kompilace "vyřešen" a neexistuje tam cesta jak něco může selhat. Tudíž předem vím, že 8 `div` 0 se nemůže vykonat, tudíž ho ani nevykonám, tudíž pro něj nejen že nealokuju paměť, já ho prostě budu ignorovat, vůbec nebude. Monády to celé trochu zamotávají, ale jinak fungují úplně stejně.

Pak je tam taková ta vazba mezi pure functional a zbytkem - ať už pomocí IOMonád, nebo Effects, nebo čehokoliv jiného. A tam to zase dostává na starost jazyk, aby se s tím popral -

ale to už by si ta low level část systému musela pohlídat sama.

.

Mě víc zajímala ta syntaxe, jak si to @Jiří Havel představoval. Protože tam je IMHO ještě co objevovat a vylepšovat.

[Jiří Havel]

Mě víc zajímala ta syntaxe, jak si to @Jiří Havel představoval. Protože tam je IMHO ještě co objevovat a vylepšovat.

Já tu ale nepíšu o nějakých hypotetických nových jazycích. Já tu píšu o tom, jak se v c++ normálně píše kód se strong exception safety. Například mám třídu co má dvě dynamické pole stejné délky a metodu resize:

Kód: [Vybrat]

class Foo
{
private:
  std::unique_ptr<Bar[]> m_Bar;
  std::unique_ptr<Baz[]> m_Baz;
  size_t m_Size = 0;
public:
  void resize( size_t new_size )
  {
    std::unique_ptr bar( new Bar[new_size] ); // muze hodit
    std::unique_ptr baz( new Baz[new_size] ); // muze hodit
    // nějake kopirovani co muze hazet atd.

    // noexcept "commit" :
    m_Bar = std::move( bar ); // nebo swap( m_Bar, bar );
    m_Baz = std::move( baz );
    m_Size = new_size;
  }
}

O co mi šlo je, že ten házející a neházející kód se nijak neliší, takže při čtení od sebe nejdou poznat. Ty  výjimky prostě probublávají bez povšimnutí. A líbilo by se mi mít něco jako :

Kód: [Vybrat]

  void resize( size_t new_size )
  {
    std::unique_ptr bar( new Bar[new_size] ); // muze hodit
    std::unique_ptr baz( new Baz[new_size] ); // muze hodit
    // nějake kopirovani co muze hazet atd.

    noexcept {
      m_Bar = std::move( bar );
      m_Baz = std::move( baz );
      m_Size = new_size;
    }
[/quote]
Prostě říct překladači, kde nesmí nic lítat. A pokud bych tam zavolal něco co není noexcept tak aby to zahlásil.

Jinak podobnost se zmiňovanými funkcionálními myšlenkami není vůbec náhodná. Ten házející kód vytváří nový stav pokud možno s minimem vedlejších efektů. A viditelné vedlejší efekty se stanou v té commit fázi.

[BoneFlute]

Mě víc zajímala ta syntaxe, jak si to @Jiří Havel představoval. Protože tam je IMHO ještě co objevovat a vylepšovat.

Já tu ale nepíšu o nějakých hypotetických nových jazycích. Já tu píšu o tom, jak se v c++ normálně píše kód se strong exception safety. Například mám třídu co má dvě dynamické pole stejné délky a metodu resize:

Kód: [Vybrat]

class Foo
{
private:
  std::unique_ptr<Bar[]> m_Bar;
  std::unique_ptr<Baz[]> m_Baz;
  size_t m_Size = 0;
public:
  void resize( size_t new_size )
  {
    std::unique_ptr bar( new Bar[new_size] ); // muze hodit
    std::unique_ptr baz( new Baz[new_size] ); // muze hodit
    // nějake kopirovani co muze hazet atd.

    // noexcept "commit" :
    m_Bar = std::move( bar ); // nebo swap( m_Bar, bar );
    m_Baz = std::move( baz );
    m_Size = new_size;
  }
}

O co mi šlo je, že ten házející a neházející kód se nijak neliší, takže při čtení od sebe nejdou poznat. Ty  výjimky prostě probublávají bez povšimnutí. A líbilo by se mi mít něco jako :

Kód: [Vybrat]

  void resize( size_t new_size )
  {
    std::unique_ptr bar( new Bar[new_size] ); // muze hodit
    std::unique_ptr baz( new Baz[new_size] ); // muze hodit
    // nějake kopirovani co muze hazet atd.

    noexcept {
      m_Bar = std::move( bar );
      m_Baz = std::move( baz );
      m_Size = new_size;
    }
[/quote]
Prostě říct překladači, kde nesmí nic lítat. A pokud bych tam zavolal něco co není noexcept tak aby to zahlásil.

Jinak podobnost se zmiňovanými funkcionálními myšlenkami není vůbec náhodná. Ten házející kód vytváří nový stav pokud možno s minimem vedlejších efektů. A viditelné vedlejší efekty se stanou v té commit fázi.

Což je si ale, přiznejme si, nic moc.

Kód: [Vybrat]

# Python
with open('dog_breeds.txt') as src, threading.Lock(), db.connection() as con:
    con.insert(src.readlines())

(GoLang má defer, což je něco podobného ale hnusnějšího.)

Řekl bych, ty tak docela nepotřebuješ rozlišovat co může selhat a co ne. Jako spíše zajistit tu atomicitu.

Ten with řeší dvě věci, automaticky uzavřít zdroj, když něco selže, a rollback při chybě v bloku.

Tohle je zatím nejhezčí s čím jsem se setkal.

[Ink]

Kód: [Vybrat]

# Python
with open('dog_breeds.txt') as src, threading.Lock(), db.connection() as con:
    con.insert(src.readlines())

(GoLang má defer, což je něco podobného ale hnusnějšího.)

Řekl bych, ty tak docela nepotřebuješ rozlišovat co může selhat a co ne. Jako spíše zajistit tu atomicitu.

Ten with řeší dvě věci, automaticky uzavřít zdroj, když něco selže, a rollback při chybě v bloku.

Tohle je zatím nejhezčí s čím jsem se setkal.

Teď se Ti myslím povedla demonstrace jedné ze skutečných výhod výjimek, která ale může fungovat asi jenom v dynamických jazycích typu Pythonu - ten context manager pozná výjimku podle parametru, který ji identifikuje.

Jinak je to věc, která se dá řešit destruktorem při výstupu z rozsahu platnosti proměnné - třeba v Rustu se udělá drop v opačném pořadí (vzhledem k pořadí definice proměnné) automaticky a je vymalováno taky.