🚀 go-pugleaf

Cze��
Odpowiadam na zarzuty, postulaty i dorzucam nowe info.

1) r�wnowa�no�� deklaracji
>A)    KlasaObiekt�w a[10];
>B)    x = new KlasaObiekt�w[10];

Napisa�em jasno, �e nie s� r�wnowa�ne.
A allokuje pami�� w bloku danych, B na stercie ( heap ).
Na stercie 'marnuje' si� troch� pami�ci bo trzeba zapami�ta� 
na niej, jakiej wielko�ci obszar usun��.
Poza tym w wielu implementacjach sterta jest 'ziarnista' - 
kwantem przydzia�u nie jest bajt ale np. paragraf ( 16 bajt�w ), 
zapami�tuje si� opr�cz rozmiary zaallokowanego obszaru tak�e inne
informacje
( np. wska�nik na pocz�tek 'poprzedniego' obszaru itp. ).
Dlatego deklaracje statyczne s� oszcz�dniejsze.

2) konstruktory i destruktory obiekt�w zadeklarowanych w tablicy 
Z konstruktorami jest o tyle �le, �e sama deklaracja wywo�a konstruktor
domy�lny 
dla ka�dego obiektu, a zindywidualizowanie ( dla ka�dego elementu inny
konstruktor ) -
to uci��liwa pisanina.
Destruktory - b�d� wykonane na pewno, i to dla ka�dego elementu. Wymaga to 
niew�tpliwie dodatkowej pami�ci, cho�by na kod, kt�ry przeleci n
utworzonych 
obiekt�w i wywo�a ich destruktory.
'Dodatkowy int'  nic specjalnie nie da - przecie� rozmiar tablicy jest
JAWNIE napisany,
i pod koniec t�umaczenia funkcji kompilator zn�w mo�e si�gn�� do tablicy
symboli 
po ten rozmiar. Nie trzeba go dodatkowo zapami�tywa�.
Niemniej s� przer�ne implementacje, i mo�liwa jest tak�e i taka, kt�ra
tego inta 
gdzie� wtyka.

W C++ 'dodatkowych' bajt�w mo�na spodziewa� si� w ilo�ci du�ej.
Do programowania kontroler�w polecam asembler :)


3) co lepsze: skrzyde�ko czy n�ka ?

>Zawsze jednak lepiej ( IMHO ) zrobi� new
>i delete ni� deklarowa� statycznie.

Moja opinia wynika z czystego 16 bitowego sk�pstwa, gdzie stos+blok danych
= 64 kb.
Obiekt zadeklarowany statycznie �yje ca�y czas i z�era zasoby, nawet je�eli

w danym przebiegu programu nie jest w og�le potrzebny.
Stos te� bywa czasami ciasny ( je�eli jest du�o napis�w w bloku danych ).
Natomiast sterty mi nigdy nie zabrak�o: potrzebuj�-bior� ( ile w danej
chwili potrzeba, a nie 
tyle, ile mi si� podczas pisania zdawa�o �e musz� mie� ), nie potrzebuj� -
zwalniam.

Je�eli chodzi o szybko�� allokacji na stercie w por�wnaniu ze stosem, to na
moim 
XT 4,77 MHz ( cztery i siedemdziesi�t siedem setnych megaherca ) nie
zauwa�y�em specjalnego 
spowolnienia, ale zawsze mia�em trudno�ci z pomiarem w strefach
pikosekundowych, wi�c 
mo�liwe, �e si� myl�.

Je�eli chodzi o komplikacj� programu ( dodatkowa instrukcja if ( allokacja
udana ) ... ),
to IMHO nie jest ona wielka.
A rozmiar programu ? Mo�e rzeczywi�cie  obni�enie rozmiaru kodu wynikowego
z 2,456,875 bajt�w do 
2,456,778 bajt�w ma swoj� warto��.
Ja osobi�cie szukam oszcz�dno�ci w innych obszarach.

Ponadto polecam r�ne biblioteczki ( np. ZFortify ) kt�re 'przechwytuj�'
new i delete.
Nowy new allokuje kilkana�cie ( np. 32 ) bajt�w wi�cej ni� ��dano, wype�nia
te bajty charakterystycznym 'wzorkiem' i oddaje wska�nik na '�rodek'
zaallokowanego obszaru ( pocz�tek plus np. 16 ).
Natomiast nowe delete sprawdza, czy charakterystyczny 'wzorek' w
dodatkowych 16 pocz�tkowych 
i w 16 ko�cowych bajtach nie uleg� zatarciu, co �wiadczy�o by o b��dach w
kodzie i przekraczaniu
dodatkowych zakres�w.
Ponadto prowadzenie listy zaallokowanych obszar�w pomo�e wskaza� na ko�cu
aplikacji 
miejsca, dla kt�rych 'zapomnieli�my' o delete do pary z 'new'.

-- 
CUL
pluton
NA...@jmk.lodz.pl