> Dnia 06-05-2011 o 01:29:52 Michoo <m...@v...pl> napisał(a):

>

> > W dniu 05.05.2011 00:32, fir pisze:

> >>> tworzenia stu instancji ktore pozniej moga spokojnie hulac

> >>

> >> wogole to nie chcialem sie wdawac w takie dlugie wyjasnienia, chcialem

> >> tylko owiedziec (a nawet wcale nie chcialem tego pwiedzec) tylko  

> >> zauwazyc

> >> ze tak jest:

> >>

> >> w statycznym c NAPRAWDE nie ma takiego pojecia i problemu

> >> jak leaki (jest to pojecie absolutnie nieznane)

> > Pokazałem Ci leak w statycznym kodzie. i to bardzo prostym.

> >

> > Mam cały czas wrażenie, że podchodzisz do programowania z punktu  

> > widzenia programów "Ahoj przygodo!!!" w którym żeby mieć  

> > błąd/leak/nieoczekiwane zachowanie trzeba się naprawdę postarać. Gdy  

> > tymczasem programowanie to dużo, dużo więcej a wykrycie błędów w  

> > "statycznym C fira" jest wyjątkowo trudne.

> >

> >> jak ktos nie wierzy to mz jego problem

> > Tak, bo Twoja racja jest najtwojsza...

>

> Prawdę mówiąc, w tym przypadku zgadzam się z autorem pierwszego posta.  

> Twój przykład nie ma wycieku pamięci jako takiego, tylko nieumiejętne  

> zarządzanie tablicą. Jeśli mam tablicę od 0 do 9 i ustalę, że pierwszym  

> elementem jest 5, to mimo tego w każdym miejscu programu nadal jestem w  

> stanie dostać się do pierwszych czterech elementów. Jeśli napiszę zaś  

> funkcję, która zaalokuje pamięć i jej nie zwolni (oraz nigdzie nie  

> pozostawi do niej wskaźnika), to w praktyce *nie* jestem w stanie do tej  

> pamięci już się dostać. To jest bardzo istotna różnica, która - moim  

> zdaniem - nie pozwala nazwać pierwszego przypadku wyciekiem pamięci.

>

> Fir mówi o wyciekach pamięci na poziomie zarządzania pamięcią operacyjną,  

> Ty mówisz o "wyciekach" na poziomie logiki programu.

>

> Inaczej: napisz mi taki program (w C++), który używa tylko obiektów  

> alokowanych statycznie i zgłosi wyciek pamięci:

>

> #define _CRTDBG_MAP_ALLOC

> #include <crtdbg.h>

>

> int main (int argc, char * argv[])

> {

> // Tu Twój kod

>

> _CrtDumpMemoryLeaks();

> }

>

> Pozdrawiam -- Spook.

>

co do tamtego przykladu (se spawn itd) to najkrocej mowiac roznica
jest taka ze w jednym wypadku niezwolnione obiekty sa 'martwe'
(wyciekly, nie mozna ich uzyc) zas w drugim doskonale i w pelni
'zywe' (nietkniete, zdrowe, itp)


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

do góry

W dniu 2011-05-06 01:29, Michoo pisze:
> W dniu 05.05.2011 00:32, fir pisze:

>
> Mam cały czas wrażenie, że podchodzisz do programowania z punktu
> widzenia programów "Ahoj przygodo!!!"

Zeby zostawic tupolewa a pozostac przy lotnictwie, w obszernym watku
wspomnianym.
To co dociera do mnie o Airbusie, to jest po prostu straszne. Bledny /
niepewny / niezaufany odczyt z jednego czujnika (rurka Pito) wynika ze
blokowal cale sterowanie samolotem. Trudno w to uwierzyc, ale kto wie...

Jesli dziennikarze czegos nie sfabrykowali (co jest tez mozliwe) to
projektanta nie nalezy rozstrzelac, tylko bardzo powoli, zeby sobie
ostatni raz design przemyslal....

do góry

On 06/05/2011 05:31, Wojciech "Spook" Sura wrote:
>
> Fir mówi o wyciekach pamięci na poziomie zarządzania pamięcią
> operacyjną, Ty mówisz o "wyciekach" na poziomie logiki programu.

Jak zaalokujesz pamięć przez malloc i nie zwolnisz przez free to błąd
jest na poziomie logiki programu.

Z drugiej strony jeśli masz statyczną tablicę, w której masz wolną pulę
elementów, które sobie przydzielasz dla nowych danych i zwracasz z
powrotem do puli, to to co w tym momencie robisz, to właśnie forma
"zarządzania pamięcią".

> Inaczej: napisz mi taki program (w C++), który używa tylko obiektów
> alokowanych statycznie i zgłosi wyciek pamięci:
>
> #define _CRTDBG_MAP_ALLOC
> #include <crtdbg.h>
>
> int main (int argc, char * argv[])
> {
> // Tu Twój kod
>
> _CrtDumpMemoryLeaks();
> }

Wyciek to z definicji to, co zgłosi _CrtDumpMemoryLeaks()? Nie popadajmy
w absurd.

do góry

Wojciech "Spook" Sura wrote:

> 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.

To prawda. Ale sterte tez mozesz sobie przegladac/iterowac itd.

> Ba, można banalnie łatwo napisać odśmiecacz,
> który z powrotem odzyska nieużywane rekordy.

Nie mozna, bo skad wiadomo, ktore sa nieuzywane?

--
Michal

do góry

> 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

do góry

> Wojciech "Spook" Sura wrote:

>

> > 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.

>

> To prawda. Ale sterte tez mozesz sobie przegladac/iterowac itd.

>

niby jak?

> > Ba, można banalnie łatwo napisać odśmiecacz,

> > który z powrotem odzyska nieużywane rekordy.

>

> Nie mozna, bo skad wiadomo, ktore sa nieuzywane?

>

> --

> Michal



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

do góry

On Tue, 03 May 2011 08:59:52 +0200, Paweł Kierski<n...@p...net>
wrote:
> Inaczej - zgubienie uchwytu do zasobu (np. wskaźnika do
> bloku pamięci) jest jednym (pewnie najpopularniejszym)
> sposobem powstawania wycieków.

Można też zauważyć, że jeśli przydziela się w programie elementy ze
statycznej tablicy, to taki element można traktować jak zasób, a
indeks jako uchwyt. Zresztą przecież te wszystkie systemowe uchwyty i
deskryptory to zwykle są indeksy w jakichś systemowych tablicach.

do góry

> tu wogole nie ma pojecia zwalniania - leak dotyczy _utracen referencji_

defakto nie wiem czy przypadkiem cos takiego

f()
{
char* txt ="yellow girls are running backwards";

}

nie spalnia definicji leaka - bo ref jest tracona a dane, o ile
wiem, zostaja raczej na stercie (bezuzyteczne), niz sa zwijane ze stosu



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

do góry

> On Tue, 03 May 2011 08:59:52 +0200, Paweł Kierski<n...@p...net>

> wrote:

> > Inaczej - zgubienie uchwytu do zasobu (np. wskaźnika do

> > bloku pamięci) jest jednym (pewnie najpopularniejszym)

> > sposobem powstawania wycieków.

>

> Można też zauważyć, że jeśli przydziela się w programie elementy ze

> statycznej tablicy, to taki element można traktować jak zasób, a

> indeks jako uchwyt. Zresztą przecież te wszystkie systemowe uchwyty i

> deskryptory to zwykle są indeksy w jakichś systemowych tablicach.

mozna ale nie trzeba i ja tak nie robie - wogole mam raczej na pienku z
uchwytami

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

do góry

W dniu 06.05.2011 06:31, Wojciech "Spook" Sura pisze:
> Prawdę mówiąc, w tym przypadku zgadzam się z autorem pierwszego posta.
> Twój przykład nie ma wycieku pamięci jako takiego, tylko nieumiejętne
> zarządzanie tablicą. Jeśli mam tablicę od 0 do 9 i ustalę, że pierwszym
> elementem jest 5, to mimo tego w każdym miejscu programu nadal jestem w
> stanie dostać się do pierwszych czterech elementów. Jeśli napiszę zaś
> funkcję, która zaalokuje pamięć i jej nie zwolni (oraz nigdzie nie
> pozostawi do niej wskaźnika), to w praktyce *nie* jestem w stanie do tej
> pamięci już się dostać.
Alokator sobie gdzieś istnieje, więc MOŻESZ się do niej dostać.
Bezpieczne to nie jest, ale możliwe ;)

> Fir mówi o wyciekach pamięci na poziomie zarządzania pamięcią
> operacyjną, Ty mówisz o "wyciekach" na poziomie logiki programu.
W którymś z postów już napisałem, że ograniczanie się do czystych
"memory leaks" na poziomie systemu operacyjnego jest sztuczne, bo
mechanizm "wycieku" zasobów jest ten sam i dla pamięci, i dla puli
obiektów i dla socketów: w momencie gdy pozbywamy się referencji na
obiekt nie zwalniamy go.

A prawie w każdym systemie musimy mieć dynamiczny przydział zasobów - w
ten czy inny sposób, więc zachwalanie jakiejś metodyki dlatego, że w
niej nie wycieka "czysta pamięć" jest bez sensu, bo błąd tego samego
typu może spowodować wyciek innego zasobu.

> Inaczej: napisz mi taki program (w C++), który używa tylko obiektów
> alokowanych statycznie i zgłosi wyciek pamięci:
Pokazałem kod w którym raz jest alokacja oparta o new/delete a raz
przydział z puli. Reszta kodu jest DOKŁADNIE taka sama. Czy to znaczy,
że w drugiej sytuacji nic nam nie "wyciekło"?
Imo wyciekło, tylko nie "czysta pamięć" a obiekty z puli, ale mechanizm
jest dokładnie ten sam.

--
Pozdrawiam
Michoo

do góry