reklama

Rust vs. C++ (funkcionální vs. OOP)

Kit

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #15 kdy: 13. 03. 2016, 14:26:45 »
Mám třády ApplicationElement, UIElement, GenericStack, PartStack, kdy následující třída vždy dědí z předchozí.

Nejsem si jist, zda je te dědičnost uvělána správně. UIElement může být speciálním případem ApplicationElement, ale GenericStack určitě není specializací UIElement. Spíš bych se odvážil tvrdit, že UIElement bude komponentou GenericStack.

Tedy v případě vztahu GenericStack a UIElement nemá být použita dědičnost, ale kompozice.

reklama


javaman

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #16 kdy: 13. 03. 2016, 14:43:41 »
Přesně tak, je čas na Javu.

Klidně, jen kdyby tam nebyl GC a overhead s voláním C funkcí. Jazyk jako takový se mi líbí.

Můžeš si ho vypnout :D Ale jinak GC je asi nejlepší.

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #17 kdy: 13. 03. 2016, 15:06:07 »
...Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. ...

Já jsem to věděl, že si to ještě pamatuju:
https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctors

bjarne

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #18 kdy: 13. 03. 2016, 15:12:22 »
Mám třády ApplicationElement, UIElement, GenericStack, PartStack, kdy následující třída vždy dědí z předchozí.

Nejsem si jist, zda je te dědičnost uvělána správně. UIElement může být speciálním případem ApplicationElement, ale GenericStack určitě není specializací UIElement. Spíš bych se odvážil tvrdit, že UIElement bude komponentou GenericStack.

Tedy v případě vztahu GenericStack a UIElement nemá být použita dědičnost, ale kompozice.

GenericStack je genericka abstraktni trida dedici z UIElement a slouzici jako predek pro vsechny UIElementy, ktere obsahuji dalsi UIElementy, ale vzdy zobrazuji v dany cas jen jeden a nejakou navigaci pro aktivaci tech ostatnich. Jsem presvedcen, ze takhle je to navrzene spravne.

uetoyo

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #19 kdy: 13. 03. 2016, 15:19:47 »
Bez pohledu do zdrojáku se dá těžko rozhodnout, jestli je ta hierarchie správně, ale podmenované to je divně.
`UIElement <-- GenericStack`?

Citace
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

reklama


bjarne

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #20 kdy: 13. 03. 2016, 15:22:15 »
...Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. ...

Já jsem to věděl, že si to ještě pamatuju:
https://isocpp.org/wiki/faq/strange-inheritance#calling-virtuals-from-ctors

Jj ono to dava smysl, ze to nejde. Tenhle problem je v podstate ve vsech jazycich, kde je ten koncept konstruktorů a virtualnich metod, takze treba i v Jave. Vlastne jsem na to jednou v Jave narazil, tam se totiz ta virtualni metoda potomka zavola, ale proste datove cleny potomku, u kterych jeste nebyl vyvolan konstruktor, jsou inicializovane na svoje defaultni hodnoty. Tenkrat jsem se tim pekne strelil do haksny.

bjarne

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #21 kdy: 13. 03. 2016, 15:29:49 »
Bez pohledu do zdrojáku se dá těžko rozhodnout, jestli je ta hierarchie správně, ale podmenované to je divně.
`UIElement <-- GenericStack`?

Citace
There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

A co je na tom divného, že třída GenericStack dědí ze třídy UIElement? To nějak nechápu, co vadí. GenericStack je UIElement.

uetoyo

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #22 kdy: 13. 03. 2016, 15:41:08 »
Můžeš se hádat s Kitem (a on se bude hádat .), jestli to má být dědičnost nebo kompozice, ale bez pohledu do zdrojáku se hůře argumentuje. Jinak GenericStack mi evokuje datovou strukturu, neříkám, že to nemůže být nějaký UI element/kontejner, ale je to matoucí (osobní názor).

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #23 kdy: 13. 03. 2016, 15:55:38 »
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Radek Miček

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #24 kdy: 13. 03. 2016, 15:58:49 »
GenericStack mi evokuje datovou strukturu, neříkám, že to nemůže být nějaký UI element/kontejner, ale je to matoucí (osobní názor).

IMO Stack je celkem normální název pro UI elementy - viz třeba GtkStack, QStackedLayout případně WPF StackPanel.

uetoyo

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #25 kdy: 13. 03. 2016, 16:06:44 »
Už mi svitlo.

Radek Miček

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #26 kdy: 13. 03. 2016, 16:15:03 »
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Jaká je situace s knihovnami a vývojovými prostředími na Linuxu? Případně na Windows?

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #27 kdy: 13. 03. 2016, 16:20:46 »
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Jaká je situace s knihovnami a vývojovými prostředími na Linuxu? Případně na Windows?
Swift může přímo volat kód (knihovny) v C (podobně jako Go), takže stačí dynamicky linkovat. IDE nepoužívám, tak nevím, vi to jistí.

Radek Miček

Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #28 kdy: 13. 03. 2016, 16:25:54 »
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Jaká je situace s knihovnami a vývojovými prostředími na Linuxu? Případně na Windows?
Swift může přímo volat kód (knihovny) v C (podobně jako Go), takže stačí dynamicky linkovat. IDE nepoužívám, tak nevím, vi to jistí.

Díky. Spíše jsem ale myslel, jaké knihovny bude Apple portovat na tyto platformy?

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Rust vs. C++ (funkcionální vs. OOP)
« Odpověď #29 kdy: 13. 03. 2016, 16:32:37 »
Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.
Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Jaká je situace s knihovnami a vývojovými prostředími na Linuxu? Případně na Windows?
Swift může přímo volat kód (knihovny) v C (podobně jako Go), takže stačí dynamicky linkovat. IDE nepoužívám, tak nevím, vi to jistí.

Díky. Spíše jsem ale myslel, jaké knihovny bude Apple portovat na tyto platformy?
Swift má svou "standard library" a Apple portuje na Linux Foundation (přepisuje ji z ObjC, ale ještě tam pár věci chybí, myslím, že cíl je mít úplný port v 3.0).

 

reklama