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
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).
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í.
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
Celkom pekne a rychle intro do Rustu napisali chalani z Thoughtram.io. Fakt odporucam.
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
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.
V C++ to není tak složité. Pro naprostou většinu případů stačí „ukrást“ malloc, realloc a free.
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.
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í).
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.