Názory k článku Máte dost paměti?
-
Libor (neregistrovaný)No Martine, zasnu nad tim, ze takovy zaryty Fortranista jako Ty fusuje i do C++. Jinak skvely clanek, jen skoda, ze nevysel pred rokem, kdy jsem presne tento problem resil. A moc takhle neponocuj nebo pak v praci nebudes podavat maximalni vykon a sef Ti bude muset v lete snizit plat.
-
Zdenek (neregistrovaný)Proc neposlusny proces? Proces potrebuje pamet na urcitou operaci a tak se zepta OS jestli mu ji da. Pokud OS rekne nedam, tak proces muze pouzit jiny algoritmus s mensi spotrebou pameti, ale treba s delsi casovou narocnosti. Aby hned OS zabijel a treba i jine aplikace, ktere podle jeho logiky zerou hodne se mi nezda v urcitych pripadech vhodne.
-
kvr (neregistrovaný)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. -
Ped (neregistrovaný)?? 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. -
Je sice pěkné, že je tu hezký a rychlý způsob výpisu seznamu alokované paměti (a to pamatuju třeba z Visual C++), ale tento přístup rozhodně neřeší otázku vzniku, jako např. vznik memory leaků při volání výjimek (neodchytnuté výjimky nebo špatné čištění po výjimce).
Ve všech případech (i při volání výjimky) se ruší všechny lokální proměnné. Tohoto jevu se užívá u tzv. chytrých ukazatelů (smart pointers), kteří existují pouze jako lokalní proměnné a udržují si ukazatel na nějaký (libovolný, definice přes template) objekt. Pokud si navíc udržují i počet referencí (nutno definovat kopírovací konstruktor), lze takový chytrý ukazatel vrazet z funkce, předávat jej jako parametr atd. Problémy nastávají u cyklyckých odkazů, kdy jedna třída ukazuje na jinou a obráceně, pro tyto případy se používá slabá vazba (weak) z jedné strany. Není složité ani použití ve vícevláknovém prostředí, kdy stačí ošetřit pouze počítání referencí.
Pro více informací doporučuji google.com (smart-pointers) a naučit se pracovat s templaty (není nic složitého). Už nikdy memory-leaky!!!
A na závěr poznámečku: C++ není nadstavba C, aby se z něj používaly pouze třídy... Hlavní síla je v klíčovém slovětemplate. -
Ups, zapomněl jsem připomenout, že daný objekt, na který chytrý ukazatel ukazuje, se ruší zároveň s ukazatelem (tj. platnost jako lokální proměnná) a v případě počítání referencí navíc v situaci, kdy na objekt nikdo neukazuje.
Správa paměti je jakoby automatická (pseudoautomatická pro rejpaly :-)), už žádné explicitní delete (new je stále potřeba jednou při vytváření objektu). Výjimky jsou ošetřeny, už nejsou potřeba žádné složité čištěcí procedury, jestli objekt náhodou byl, nebo nebyl vytvořen. -
majka (neregistrovaný)pre implementaciu reference countingu pozri cast 16.22 na http://www.parashift.com/c++-faq-lite/freestore-mgmt.html
-
V případech, kdy není třeba těžce optimalizovat, jako např. GUI (ve srovnání s výkonnou částí programu), jsou smart-pointery snadnou volbou, jak zamezit vzniku memory-leaků. A v oblasti multi-threadingu je reference-counting neocenitelnou záležitostí (a stejně se dojde k podobné, ne-li stejné implementaci).
Ve větších projektech pak nějaký memory leak checker je sice hezký, ale jeho výsledky nemusí odpovídat reálnému stavu, nebo jsou programátoři na úrovni, že nic takového nepoužívají (co to je memory-leak?), či nálezy ignorují... A nejhorší situace je, že se takové utilitky vůbec nemůžou používat, protože prostě není čas a pak je lepší garbage-collector např. na úrovni smart-pointerů. (Ale povídejte jim to, když to nejlepší, co z C++ viděli, je klíčové slovo class :-)) -
Michal Kára (neregistrovaný)Dobra technika je take poolovana alokace. Je vhodna jen pro urcity typ programu, kde se provede nejaka operace, ze ktera sice spotrebuje hodne pameti, ale ze ktere je "maly" vysledek (pripadne se vysledek zapise nekam do souboru, posle pres sit, atp.) a pak je mozno vsechna data z pameti zapomenout... Hodne se mi osvedcila ;-)
-
martin kukacka (neregistrovaný)Clanek byl minen presne tak, jak se pise v jedne reakci - jako uvod do problematiky (dejme tomu pro stredne - co to je? - pokrocile programatory). Nedotazene veci (napr. neefektivni spojovy seznam) jsou v clanku zmineny. Samozrejme, ze existuje rada pristupu, jak se vyhnout memory leakum (ze by snad namet na pokracovani?), ale kazdy ma krome vyhod take nevyhody ci omezene pouziti. Napr. zminene smart pointry - standardni std::auto_ptr ma "move" semantiku, takze kod
auto_ptr<NejakaTrida> a(new NejakaTrida); auto_ptr<NejakaTrida> b; b=a; cout << "a:" << a.get() endl;by mel vypsat, ze a je NULL (myslim, ze treba MSVC to nedela, ale to je jedno, norma si to zada). Existuji i lepsi smart pointry, ty ale zase nejsou standardizovane. Nekdy se proste smart pointry nehodi... -
Ano,
auto_ptrje jen takova kravinka (prakticky nepouzitelna) a zrovna moc chytra neni (ve skutecnosti to zrovna smart-pointer neni). Jedna implementace je napr. v balikuboost. Ve vicevlaknovem prostredi je ale vzdycky otazka, ktere prostredky mame (linux-threads, Win32...), ale knihovnaboostje psana prenositelne a ma vlastni implementaci vazanou na konkretni system (bezi jak pod Linuxem, tak pod Win32). Ale jak bylo (nekde) receno, je to dalsi knihovna, na ktere jste zavisli.
Ja pouzivam vlastni implementaci a kdyz se spravne pouzivaji template, pak staci jen zmenit implementaci mutexu+semaforu a muze to pracovat pod libSDL (kdyz si zrovna hraju s libSDL), nebo treba jen s linux-threads, nebo jak si clovek zamane (zmena dvou kratickych trid a vsechno ostatni zustava).
ČLÁNKY DO MAILU