> Dnia 03-05-2011 o 01:14:36 Andrzej Jarzabek <a...@g...com>  

> napisał(a):

>

> > On 02/05/2011 22:06, f...@W...gazeta.pl wrote:

> >> czyli w skrocie ->  ZAPCHANIE sobie tablicy (przez bledy w poodznaczaniu

> >> flag) to nie WYCIEKI

> >

> > To są wycieki.

>

> Kwestia definicji. Program nadal może dostać się do "zapchanych" elementów  

> tablicy jawnie ją indeksując. Ba, można banalnie łatwo napisać odśmiecacz,  

> który z powrotem odzyska nieużywane rekordy. Natomiast nie ma już szansy  

> odzyskać utraconego wskaźnika do dynamicznie zaalokowanej pamięci.

>

> Błąd architektury, logiki programu - jak najbardziej tak. Wyciek? Nie.

>

> >> (z tego jak to widze leaki raczej nieodzownie lacza

> >> sie z utraconymi referencjami czyli nieodzownie zagubionym ramem)

> >

> > To jest tylko kwestia implementacyjna. Logicznie masz ten sam problem:  

> > jeśli element w tablicy nie może być już do niczego użyty (nie ma i  

> > logicznie nie mogą pojawić się indeksy tego elementu), a nie został  

> > oznaczony jako wolny czy wpisany do puli wolnych elementów, to RAM  

> > zajmowany przez ten element jest "nieodzownie zagubiony".

>

> Tylko że Firowi _cały czas chodzi o fizyczne wycieki_, a nie o logiczne,  

> związane z konstrukcją programu. Tobie zaś chodzi o logiczne (w których  

> zawierają się fizyczne) i dlatego obaj kłócicie się bezproduktywnie.

>

leak z definicji to sytuacja w ktorek traci sie referencje do
kawalka ramu

przyklad leaka:

unsigned char* p = NULL;
p = malloc(1000);
p = malloc(2000); //wyciek!

tu wogole nie ma pojecia zwalniania - leak dotyczy _utracen referencji_

porzytek z dyskusji jest przynajmniej taki (choc niespecjalnie duzy)
ze wyklarowalo mi sie pojecie leaka


--
kanye west - graduation



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl