Správa paměti v C++

Při používání move sématiky (C++11) se čítač referencí také neaktualizuje, takže STL tuhle optimalizaci používá i bez explicitní podpory překladače.

@1 Řeč byla o statické analýze, ne move sémantice.

V zasade bych rekl, ze leaky hrozi vsude. a) V jazykach s garbage collectorem typu java, b) v jazykach s rucni alokaci a dealokaci i c) v jazycich, kde je to nejak dobastlene dodatecne jako v C++ a kde neni nejake jednotne vseobecne pouzivane reseni.
V zasade bych rekl, ze nejlip se mi to pise s gc jako v jave, ale celkem priznavam, ze dani za to je, ze kdyz nastane problem, tak clovek nemusi mit reseni ve svych rukach. Nejhur s mi to pise v c), ale to muze byt dost subjektivni.

Opravdu pekne, nicmene to ma jeden maly, ale podstatny hacek... ano, v C++ clovek muze psat kvalitne, bezpecne, atd... jenze.. JENZE, a to je jadro problemu: nemusi. Ano, N_E_M_U_S_I - takze staci jeden clovek v tymu ktery to nedodrzuje a memory leak je na svete.

Cely clanek se da v podstate napsat o JAKEMKOLIV jazyce, vcetne assembleru - protoze v JAKEMKOLIV jazyce se da pri striktnim dodrzovani pravidel (pouzivanim vhodnych knihoven, atd.) dosahnout kvalitniho kodu.
Podstatny rozdil je ale v tom ze ten kvalitni kod NENI zasluha jazyka, ale cloveka, ktery velmi disciplinovane pouziva "spravne" postupy.

Shrnuto: veskera zminovana ochrana pred memory-leaky a ztizene psani kodu, kde clovek musi vice premyslet je dano "OSVICENYM PROGRAMATOREM", nikoliv pouzitim C++ a tedy se da vztahnout na libovolny jazyk.

@4 Ne tak úplně, v C++ stačí zakázat používání new/delete (což by měla být samozřejmost). Co píšete se týká třeba ObjC (bez ARC), kde jsou pravidla a konvence, které je nutné dodržovat. V C++ člověk bez new vyrobí memory leak jen referenčním cyklem (kromě leaků, které lze vyrobit i s GC, např. ponechání instance v globální proměnné apod.).

@2 Však move sématika je taková statická analýza, akorát se analyzuje pouze kontrakt, není potřeba provádět hloubkovou analýzu použití, díky čemuž to funguje i přes hranice sdílených knihoven, obousměrně a do neomezené hloubky. To je totiž to, co se mi na vývoji C++ líbí: místo aby byla rovnou přidána zajímavá vlastnost, přemýšlí se nad tím, jestli to samé nelze udělat i nějak jinak, lépe a jednodušeji :)

@6 To nic nemění na tom, že move sémantikou optimalizovat čítač referencí nelze.

@5 Ale to je prave to o cem mluvim: "v C++ stačí zakázat používání new/delete" je to, na cem to cele stoji a pada - a realita je bohuzel takova ze u vetsiny projektu to "zakazat" jde jen velmi tezko (resp. jde to casto pouze z pozice sefprogramatora nebo podobne).

Tedy dokud v C++ bude PRINCIPIALNE MOZNE zapsat new a delete (nehlede na to ze se najdou vykukove kteri i v C++ pouzivaji malloc/free - zazil jsem to), tak C++ bohuzel JE jazyk nachylny k memory leakum.

Proste v realnych podminkach JSOU programy psane v C++ nachylne na memory leaky. To ze je to zpusobene nedbalosti, hlouposti nebo lajdactvim je vedlejsi.
A oznacovat ty co to tvrdi za "veleosly" se mi vubec nelibi.

@8 "Veleosly" prosím ignorujte, jsou pro rozproudění diskuse.

Když už tedy diskutujeme věcně, podotýkám, že i v Javě či C# je nutná jistá sebedisciplína. V C++ vidím problémy s pamětí jinde než u new/delete, ale to by bylo na jinou diskusi.

V C++ sice nedelam, ale prijde mi trochu divne oznacovat lidi za veleosly, kdyz jim o neco nize pak zakazujete new/delete. A pokud vim, shared_ptr tam take neni od zacatku.

Takze mozna, dnes to tak plati, a lze v (modernim) C++ psat bezpecne. Ale oznacovat lidi za osly jen proto, ze nesleduji posledni trendy? Kdyz pravem kritizovali neco, co bylo spatne navrzene? Trochu odvazne, rekl bych.

@10 Konečně zajímavá diskuse. Díky.
RIAA je v C++ odnepaměti. Zmiňovaný Stroustrupův příklad je někdy z 90. let. Můžeme to nazývat moderním C++, ale těžko posledním trendem. Kdyby oni kritici kritizovali výkon (bez move sémantiky, jež je vskutku "posledním trendem", by to bylo právem), nic bych nenamítal. Ovšem papouškovat bezmyšlenkovitě 20 let starou kravinu, to opravdu nesvědčí o přílišné inteligenci. Takoví by se měli aspoň zamyslet, a snad je vysvětlení v tomto článku snadné k pochopení. Na druhou stranu tito "kritici" beztak nevědí, jak funguje GC v Javě nebo C#, takže nemůžou srovnávat.

> Na diskusních fórech se stále dokola opakuje tvrzení, že v C++ hrozí úniky paměti, že je na ně náchylné

> V C++ člověk bez new vyrobí memory leak jen referenčním cyklem (kromě leaků, které lze vyrobit i s GC, např. ponechání instance v globální proměnné apod.).

Tak hrozí úniky nebo nehrozí?

@12 Nehrozí více než v jiných jazycích.

> Opět lze namítnout, že existují deterministické GC, jenže ty se používají jen ve speciálních případech (typicky real-time systémech, i když tam se většinou GC nepoužívá vůbec), neboť mají spoustu jiných nevýhod.

Na druhou stranu GC může rozložit dealokaci mnoha objektů v čase.

@14 To jde i bez GC, jenže to nepřináší žádné výhody, tak proč by to někdo dělal?

@13 Jen člověk nesmí používat new a delete a také nesmí tvořit referenční cykly.

@15 Zrovna v těch real-time aplikacích to může být důležité.

To s tim RAII, xxx_ptr je hezky v teoreticky rovine. V praxi jste casto nucen pouzit knihovnu/framework, ktera(y) ve sve dokumenteci rika: "sem mi predej void**(popr. char*) a ja ti nereknu co s tim nakonec udelam".

@18 Céčkové knihovny mají většinou aspoň tolik "slušnosti", aby vyžadovaly const pointer. Pak to není problém. V horším případě je nutný wrapper, který problematický kód zapouzdří. To už jsme ale mimo C++.

Dalsi problem pouzivania new/delete je heap corruption, ked je delete volane 2 krat pre ten isty pointer. Je to velmi tazke analyzovat, ked to spadne u zakaznika. Aj ked mate crashdump, je vam to nanic, lebo program spadne na uplne inom mieste. Tu pomozu len programy ako Application Verifyier alebo BoundsChecker. A na nepoucitelnych code review, nech si pripadaju ako menejcenni :-)

@20 Prostě new/delete je pure evil. Měli by to z normy jazyka vyhodit :-)

RAII primárně není a nikdy nebyl o uvolňování paměti.

RAII je o pouhém zavolání destruktoru, jakmile skončí obor platnost proměnné, která nese objekt.

Stačí špatně naimplementovat destruktor a memory leaky nebo resource leaky budou hvízdat jak kulky na frontě.

Samozřejmě, že s pomocí RAII a vhodných tříd lze memory leakům do značné míry zabránit. Na rozdíl od GC se stará nejenom o uklizení paměti, ale obecně o uklizení všech použitých zdrojů, které objekty používají.

Nicméně musí být objekty dobře implementovány.

RAII negantuje uklizení paměti, RAII garantuje pouze to, že budou korektně zavolány destruktory všech objektů, kterým končí obor platnosti. Nic víc.

To nic nemění na tom, že při vhodném stylu se v C++ programátor o uvolňování paměti starat nemusí.

@22 Správný destruktor je žádný destruktor. O nepaměťových zdrojích článek není, ty je nutné ošetřit explicitně s GC i bez.

„Správný destruktor je žádný destruktor.“ – zřejmě názor nějakého přehnaného aktivisty.

„O nepaměťových zdrojích článek není, ty je nutné ošetřit explicitně s GC i bez.“

V C++ se ošetřuje obojí stejně – tedy často implicitně.

Výhoda RAII konceptu je deterministicky určené místo a čas úklidu. Na rozdíl od GC (s výjimkou reference counter).

@24 Kdo má vše pět pohromadě by destruktor pro správu paměti nikdy nepoužil.

Pokud vím, tak v C++11 je povolena implementace i pomocí GC. Pokud to nebude vlastnost, kterou budou překladače schválně ignorovat, tak si časem každý zvolí co chce.

[23] Správný destruktor je žádný destruktor.
???
Až do teď jsem jakžtakž stíhal, ale teď mám pocit, že jsem zabloudil k nějakým militantním aktivistům ...

Proc proboha zakazovat new/delete? Pochopim tedy snahu vyhnout se explicitnimu volani delete ale proc new? Jakekoliv pokusy nahradit new vedou k neprehlednemu kodu. To uz je lepsi new pretizit tak jak jsem naznacoval ve svem blogu a pouzivat alokatory, ktere nesou globalni zodpovednost za pridelenou pamet.

Největší problém v zakázání new/delete a používání move sémantiky vidím v tom, že se ochuzuji o OOP prvky C++. Hodně se mi stěžuje použití dědičnosti, programování proti rozhraní a polymorfismu.

K tomu "oslování" bych chtěl slyšet nějaký argument. Obecně z různých statistik a výzkumů vyplývá, že v praxi jsou memory leaky velký problém. Taky to je ten hlavní důvod proč je GC mezi tvůrci jazyků tak populární.

Zaujímalo by ma, ako sa dajú bez použitia new/delete naimplementovať štruktúry ako fronta, zásobník, strom (a iné grafy)
Najmä taký Composite pattern by ma zaujímal. A tiež ako to spojiť so situáciou, keď píšem pluginovateľnú aplikáciu (cez polymorfizmus+de­dičnosť).

Toto je nejaky pokus o flame alebo ako to chapat?

PS : make_shared vam samozrejme nepomoze v situaciach kde nezmazete odkaz (co sa tyka obecne aj javy) takze sa pomocou neho vyhnete iba urcitym formam memory leakov.

To už mi příjde smysluplnější zakazovat hvězdičky... rozumějte, používání přímých pointerů a vynucování používat chytré ukazatele. Opět to nejde vždycky, třeba při přetypování (třeba dynamic_cast) pointeru z chytrého ukazatele není dobré přetypovaný pointer ukládat zase do chytrého ukazatele. Takže se to nedá vynutit všude. Ale minimálně mezi memberemy třídy bych hvězdičku nerad viděl

Používám new i delete i další C-like funkce v C++ a hodlám v tom i nadále pokračovat. Pokud si někdo neumí otestovat aplikaci na úniky paměti, ať dělá v jazycích typu Java a necpe se mezi profi-programátory, kterým záleží jak na rychlosti, tak na efektivitě programování (díky OOP).

@33 Není co dodat. C++ rocks :-)

[33] "Používám new i delete i další C-like funkce v C++ a hodlám v tom i nadále pokračovat"

No nevím, sice jsem ze světa C/C++ už hezkých pár let pryč, ale jestli se ve vesmíru něco hodně nepokazilo, new a delete nejsou a nikdy nebyly "C-like funkce". Ostatně, ony to nejsou funkce ani v C++.

V prve rade velmi pekny blog, bookmark!

Ad GC, vs ne-gc, vs skopove (pun intended) alokace/uvolneni.

Myslim ze idealni je v dnesni dobe (i pro systems programming) opravdu GC, protoze zpravidla zapada do stylu "nevynalezat znova kolo, i za cenu toho ze holt nebude pornokino".

Osobne jsem si zvykl "high" konstrukce ( http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization#Ad-hoc_mechanisms ) a boehmgc i v cistem C, da se s tim jit dost nizko pokud hw neni vylozene spartansky - clovek ma vicemene prehled jak to funguje, takze neprichazi o deterministicke chovani (jako by to snad bylo az na minimum pripadu vubec potreba :).

Nevynucene GC co do produktivity v low jazycich na moji strane jednoznacne vitezi.

O rezii se vubec da rozsahle polemizovat - je lepsi nejaky slusny generacni mark & sweep, nebo refcounting pri predavani reference kazde shared blbinky, jakozto obcas v C++ templaty "vynucena" forma gc? Zalezi jak je program koncipovan.

Je-li to spis C-like monolit, tak refcounting je asi jasna volba (gamesky, linux kernel), s tim ze pooling/gc implementujem kde to smysl ma (linux kernel ma samozrejme GC v *mnoha* subsystemech).

Pokud to je pouze "komplexni bussiness logika", aka interakce mezi bazilionem objektu ktere se vsude mozne predavaj, refcounting spis generuje prusery - napriklad v Pythonu je refcounting udajne proto aby byl gc "deterministicky". Ok, napisu, odladim v techto podminkach a je fajn ze se mi spojeni do db zavre presne ve chvili kdy se ztrati posledni reference, teda az do ty chvile nez se nekde vytvori refcount cykl mrtvych objektu a musi se cekat na M&S. Oops.

Python to takto dela proto ze lidi proste maji tendence pouzivat M&S na uvolnovani ne-pameti, nedejboze volani destruktoru....

Nech je proklet ten co pouziva GC na uvolnovani cehokoliv jineho nez pameti, nebo se spoleha na deterministicke destruktory. Bohuzel to plati i pro vetsinu "high" veci jako Java, useknout ruce :( Vetsinou to funguje bez problemu, nez se objevi nejaka takovato zprasena ohyzdnost, nicmene GC je v tom nevinne, pouze jeho mizerne uziti v mistech kde vubec nema co delat.

"Nech je proklet ten co pouziva GC na uvolnovani cehokoliv jineho nez pameti"

Takoví existují? :-o

>> Takoví existují?

Java, to je celej narod kaciru :) Zrovna dneska jsem se spalil s http://bugs.sun.com/view_bug.do?bug_id=4724038

jak nekdo muze obhajovat takovej hnusnej bordel jako je C++ to fakt nechapu :) kdyby jazyky nejak vypadali tak C++ si predstavuju jako neco co je oblepeny asi 100000x izolepou takze uz nikdo ani netusi co to puvodne bylo a co to vlastne dela ... (?)

:)

@39 Podle tvého pravopisu lze soudit i na znalosti programování :-P

[35] No jo, měl jsem to napsat přesněji. Chtěl jsem jen říci, že se nebojím použít v C++ konstrukce OBDOBNÉ programování v čistém C v zájmu efektivity kódu (tj. nejsem žádný OOP purista).