Vlákno názorů k článku Máte dost paměti? od kvr - Pouzity pristup ma pomerne dost velke nevyhody: a) neni...

Pouzity pristup ma pomerne dost velke nevyhody:
a) neni transparentni pro zdrojovy kod, prinejmensim, co se onoho pamatovani FILE, LINE tyce
b) neni transparentni pro linker, tzn. nutnost rekompilace, o 3rd party kodu ani nemluve
c) poznamka k efektivite - linearni seznam nepatri zrovna mezi nejrychlejsi datove struktury

Reseni:
a) pouzit napr. backtrace(3, linux specific), ostatne prvni frame nad alokaci toho obvykle stejne moc nerekne
b) pouzit napr. LD_PRELOAD, v horsim pripade aspon pridat knihovnu pri linkovani
c) lepsi struktura ;)

Celkove mi prijde ten clanek jako hezky nastin problemu, nicmene je asi vhodnejsi poohlednout se po jiz hotove veci ala zminovany efence, jehoz memory-leak detection je prece jen dotazenejsi a v mnoha smerech zpusobe implementace agresivnejsi.

proc? C++ afaik pri pokusu o dealokaci nealokovane pameti nic neudela, proste operator delete ignoruje.

?? Mam uplne jine zkusenosti z praxe. Vetsinou to nadela docela slusnou paseku, hlavne takovym tim "tichym stylem", ze se to zacne projevovat az pozdeji.

IMHO jedine co operator delete ignoruje je volani s NULL-em, takze kdyz clovek NULLuje pointer na pamet po delete, tak i v pripade dvojiteho delete se stejnym zdrojem hodnoty to uz fungovat bude, ale pokud tohle neni planovane chovani diky "robustnosti" kodu, tak je to stejne spatne a programator by si na to mel davat pozor.

> Celkove mi prijde ten clanek jako hezky nastin problemu, nicmene je asi vhodnejsi poohlednout se po > jiz hotove veci ala zminovany efence...

Jenomze efence je zastaraly, ma chabou podporu vlaken a c++.

Pouzivam valgrind.