Vlákno názorů k článku Programovací jazyk Rust: náhrada C nebo slepá cesta? od martin1397 - Ako presne má Rust riešené OOP? Lebo by...
-
rust (neregistrovaný)
ano takto to samozrejme umi, akorat se pouziva jina terminologie a malinko odlisna semantika. Pekne je to popsane tady https://blog.rust-lang.org/2015/05/11/traits.html
-
krel (neregistrovaný)
Zrovna dědičnost v Rustu chybí a líbí se mi to víc než C++/Java OOP. Stejně nakonec v tom C++ i v Javě je lepší se dědičnosti vyhnout a programovat jen čistě proti rozhraní. I ty traity (rustový interface) jsou implementované trochu jinak (interface se implementuje ve zvláštní bloku, takže klidně můžu lokálně rozšiřovat rozhraní typů definovaných v jiných modulech - ideální pro DSL).
-
SB (neregistrovaný)
Dědičnost není realizací rozhraní, jak se někteří pod vlivem Javy a podobných jazyků domnívají, ale realizací pravidla DRY ve specializovaných třídách. V okamžiku, kdy dědičnost zrušíte, buďto musíte funkcionalitu napsat znovu (porušení DRY se všemi důsledky), nebo musíte použít delegaci, což může být značně kostrbaté a porušující zapouzdření.
-
JSH (neregistrovaný)
Ono i v novém C++ je to s pamětí už dost v pohodě. Doporučuju kouknout na https://www.youtube.com/watch?v=JfmTagWcqoE&t=4361s
-
Smazaný profil
Celkom pekne a rychle intro do Rustu napisali chalani z Thoughtram.io. Fakt odporucam.
-
kozzi11 (neregistrovaný)
Tak ono hodne zalezi co si predstavis pod pojmem nemuset se starat o pamet. Pokud ti jde o to ze se nechces starat o to jak a co se kde alokuje a aby se to nejak samo odstranilo, tak je asi vhodne pouzit jazyk s GC, tusim ze rust ho ma v planu pridat? Jinak nevim jestli znas jazyk D, ten by ti mel vyhovovat jeho OOP model je blizsi tomu co ma Java
-
jarouš (neregistrovaný)
GC můžeš použít i v C++, ale rozhodně to není úplně bezbolestné (potřebuješ sdílený runtime, aby neměla každá knihovna svůj GC, použití speciálních pointerů nebo intrusivních objektů - paměťový overhead pravděbodobně větší než u Javy). Taky budeš limitovaný použitými algoritmy (např. nesmíš použít algoritmy co přesouvají objekty v paměti - neplatné ukazatele po úklidu). IMHO pokud chceš GC, použij Javu, D, Go apod. V C++ nebo i v tom Rustu to bude spíš jen specialita pro omezené části programu.
-
Sten (neregistrovaný)
V C++ to není tak složité. Pro naprostou většinu případů stačí „ukrást“ malloc, realloc a free.
-
jarouš (neregistrovaný)
Jenže tohle obecně nemůžeš použít, protože to rozbije RAII. Vzhledem k tomu, že to je doporučovaný styl v C++, tak bys nemohl použít prakticky žádný cizí kód. A to nemluvím o rychlosti toho algoritmu nebo, že vlastně pořád můžeš mít memory leaky, protože všechno co vypadá jako ukazatel považuje za ukazatel.
-
Sten (neregistrovaný)
RAII to nerozbije, tam, kde je RAII, se nadále bude používat RAII, ten GC podporuje i GC_free. (Mimochodem už i v JVM se lokální proměnné nealokují přes garbage collector, ale používají stack a synchronní finalizaci.)
K memory leakům přímo nedojde. Může dojít k pozdější dealokaci, ale to se obecně může stát v každém jazyce s GC (garbage collector nezaručuje, kdy k úklidu dojde). Problém by ještě mohl nastat, pokud si nějaká třída uloží ukazatel, který nemá ukládat, tak jej GC neuklidí a bude nadále dostupný (de facto memory leak), ale s RAII by v tom případě nastal ještě horší problém (dangling pointer a možné nedefinované chování).
-
jarouš (neregistrovaný)
Vzhledem k tomu, že C++ neinicializuje member proměnné, tak opravdu k memory leaku dojít může, i když pravděpodobnější je zpožděná dealokace, další problém třeba std:vector, který si předalokuje více dat a inicializuje je až když jsou potřeba. Musel bys kód přepsat tak, aby všechny proměnné, byly vždy inicializované (což je určitě dobrý přístup, ale rozhodně není používaný všude a třeba u vectoru se podepíše na rychlosti). Stejně tak ti nepomůže když RAII objekt vytvoříš na haldě. GC_free zase rozbíjí sémantiku GC, protože musíš myslet na destrukci objektu. V GC jazycích se tohle řeší blokem finally.
