> W dniu 04.05.2011 20:29, fir pisze:

> > tamto mowienie o 'wyciekach' na statycznej tablicy mz

> > mozna porownac do sytuacji gdy nie zwalnia sie juz nie uzywanych

> > elementow stlowego wektora - to nie sa defakto wycieki tylko zapchanie

> > sobie kontenera

> >

> http://prowizorka.da.ru/~michoo/smieci/kod2.cpp

> Czym się różni uruchomienie aplikacji skompilowanej z -DSTATIC_FIR i

> bez? Tak czy tak pamięć wycieka - staje się niedostępna.

>

> Co gorsza w przypadku "statycznym" istnieje spora szansa, że programista

> po napotkaniu sytuacji końca bloku dojdzie do wniosku, że ustawił za

> małe N i po prostu je powiększy. A w przypadku malloc/new valgrind

> pięknie pokaże, że są błędy.

zauwazasz poprawne rzeczy tylko wypowiadasz odwrotne wnioski niz rozum
nakazuje - - jesli programista jest przekonany ze ma obecnie 'zywych' 30
samolotow, tablica jest na 100 i jest komunikat o zapelnieniu, to nie
zwiekszy limitu tylko sie zdziwi i zauwazy ze cos jest nie tak - a
z leakami tego moze nie zauwazyc; moze zauwazyc leaki albo nie, a jak
zauwazy leaki to niekoniecznie bedzie wiedzial ze to sa leaki z
samolotow i moze szukac tego przez dwa dni

inna rzecz jest tez taka co powtarzam, ze ja uzywam flagi .enabled
do odlaczania encji z petli przetwarzania - inaczej mowiac jesli ZAPOMNIALBYM
USUNAC obiektu ( free()/release()/dealloc() gzie indziej, a u mnie
samolot[i].enabled = false - jaki znikomy koszt!) to ten samolot nie
zniknie mi z petli przetwarzania i bedzie widzalny, poruszalny przez
algorytmy sztucznej inteligencji tak jak wszystkie inne wlaczone
obiekty - tu defakto nie ma potrzeby zwalniania po prostu jest tylko
potrzeba wylaczania - tak ze ten blad to nie blad zwlnienia a
blad wlaczenia obiektu - tak jakby ktos zapomnial wylaczyc postaci
jesli trafi ja kulka, w jezykach z alokacja tez trzeba cos wylaczyc
i dodatkowo usunac a tu tylko sie wylacza - tak ze blad wylaczenia
odpowiada tamtemu bledowi wylaczenia, a nie brakowi zwolnienia pamieci
tu sie troszczy tylko o wylaczanie (tak jak i tam) a kolejny krok
zwalniania pamieci juz nie istnieje i nie mozna o nim zapomniec

co do przykladu


#include <iostream>
const int ITER=3;
#ifdef STATIC_FIR
const int N=10;
int int_storage[N];
bool empty[N]={true};
int *get(){
for(int i=0;i<N;i++){
if(empty[N]){
empty[N]=false;
return int_storage+i;
}
}
return 0;
}
void put(int *ptr){
if(ptr >= int_storage && ptr <= (int_storage+N))
empty[ptr-int_storage]=true;
}
#define spawn get
#define release put
#else
#define spawn new int
#define release delete
#endif
int main(){
for(int i=0;i<ITER;i++){
int *a=spawn();
int *b=spawn();
//licz
release(b);
b=spawn();
a=spawn();
//licz
release(a);
release(b);
}
}

to mz nie jest adekwatny (pominawszy ze wolnego miejsca nie szukam w petli
od 0 do N tylko inkrementuje 'kursor' po kazdym wstawieniu na nastepne wolne
pole co srednio o ile pamietam sprowadza caly koszt do dwu i++ na wstawienie)

przyklad nie jest calkiem adekwatny bo ja nie symuluje mallokow/free
w alokatorach tu sie mysli bardziej 'rzeczowo' (troche jak przy zabawie
klockami)

addSamolot("spitfire", 10,20,30,15); //wstawiony

albo

samolot[i].enabled = false; //zdjety

i mozna uzyskac z petli np w kolizjach tak ze nawet o ile pamietam
przy tworzeniu nie trzeba ich nigdzie skladowac itp - nie mozna pochrzanic
relacji 1-1 miedzy wskaznikiem a blokiem ramu bo tu nie ma wskaznikow -
nie trzeba ich nigdzie trzymac - dafakto sa 'zabronione' tak, ze przyklad
jest niedobry

zreszta i tak pokazuje on roznice - po przejechaniu 100 razy tej petli
w wersji z alokami bedzie 100 osieroconych zgubionych w pozaprzestrzeni
nieusuwalnych blokow ramu z ktorymi nic nie mozna zrobic, a w wersji
statycznej po prostu tablica bedzie zapelniona stoma instancjami
i ten kod mozna nawet potraktowac jako funkcjonalny choc kaprysny
(bo tworzy sie trzysta z czego dwiescie sie usuwa) sposob
tworzenia stu instancji ktore pozniej moga spokojnie hulac





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