🚀 go-pugleaf

Marek Kotowski wrote:
> 
> Mirek Prywata wrote:
> > Co do huge, to zgodze sie w zupelnosci. Natomiast jezeli chodzi o
> > graniczenia typu 32767...
> [...]

> 3. Pragne zwrocic uwage, ze w poscie wyjsciowym byl pomysl
> alokacji obszaru ok. 300K. To juz jest konstrukcja, z ktora

Niedawno ktos sie pytal o 2,5MB. Widocznie potrzebowal.

> - smiem twierdzic - duza czesc, jesli nie wiekszosc kompilatorow
> sobie nie poradzi. Co wiecej: sposob dzialania modeli huge
> jest rozny w rozych kompilatorach. Zatem stosujac taki
> model pamieci, ryzykuje sie, ze zmiana kompilatora na inny,
> takze obslugujacy model huge, moze wymagac zmian w programie.

Wiekszosc??? Chyba az tak zle to nie jest. GNU C nie ma z tym zadnego
problemu (i to zarowno w wersji UNIXowej jak i DOSowej -DJGPP). Problem
powstaje przy uzywaniu wynalazkow takich jak tryb rzeczywisty i sztywne
adresy (co IMHO jest zupelna pomylka za ktora do dzisiaj placimy, no
coz, ale kiedys 640kB to sie wydawalo tak strasznie duzo ... -z tym, ze
to temat na zupelnie inna dyskusje). BC3.1 pod Winde tez nie ma problemu
(wyzsze numerki oczywiscie tak samo). Problem tkwi chyba nie w samym
kompilatorze, tylko w systemie operacyjnym.

Za to ja widze co najmniej jedna wade uzywania malych tablic. Trzeba
kopiowac dane po kawalku zamiast jedna funkcja memcpy() , ktora jest w
standardzie.
Trzeba miec specjalne, od nowa napisane procedury do oblugi tychze. To
juz lepiej zostawic OSowi martwienie sie jak zaalokowac pamiec.

> 4. Wbrew pozorom ograniczenie rozmiaru zmiennych
> do 32767 nie jest niezyciowe. Zdarzylo mi sie kilka razy
> miec tablice wskaznikow w modelu small (male dane). Tablice
> te nie przekraczaly owego limitu 32K. Otoz zmiana modelu na
> large (duze dane) spowodowala, ze rozmiar wskaznikow
> podwoil sie i tym samym podwoila sie tablica. Wprawdzie
> przekroczyla limit 32K, ale zmiescila sie w limicie 64K,
> i w programie nie trzeba bylo nic zmieniac (chociaz stal
> sie on formalnie nieprzenosny). Gdybym w modelu small
> zwiekszyl tablice do rozmiaru 40K, mialbym juz klopoty
> z przeniesieniem jej do modelu large (linker nie
> przyjmowal obiektow wiekszych niz 64K).
>   I prawde rzeklszy, czyz male nie jest piekne? :-)

No tak ale obrazek 800x600x24bpp moze byc juz dostatecznym powodem, zeby
uzyc duzego bloku pamieci. Tym bardziej, ze nie trzeba wtedy przepisywac
jeszcze raz wszystkich funkcji do operacji na nim wykonywanym.


Poza tym wydaje mi sie, ze te wszystkie small, large, tiny,medium, etc
to wynalazki DOSowe (niech mnie ktos poprawi jesli sie myle).  I to
wlasnie one sa najbardziej nieprzenosne. 

> 5. Oczywiscie sa aplikacje szczegolne, gdzie alokowanie
> duzych obszarow pamieci jest konieczne. To inna sprawa.
> Akurat w poscie wyjsciowym w tym watku takiej sytuacji
> prawdopodobnie nie bylo. A zasady dobrego stylu nakazuja
> - poprawie sie: zalecaja :-) - by w miare mozliwosci
> unikac stosowania konstrukcji nieprzenosnych.

Co do tego to sie chyba zgadzamy. Przy czym ja twierdze, ze wpisanie w
funkcji malloc zbyt duzego bloku spowoduje najwyzej zwrocenie NULL (z
dalszymi konsekwencjami dla programu) i nie grozi niczym powazniejszym.
Dopiero wtedy nalezy sie zastanowic co zmienic (moze kompilator), zeby
dzialalo. Czasem po prostu nie warto sie meczyc z malutkimi kawalkami
pamieci.


No i jeszcze jedna sprawa. Gdy rozmiar pamieci peceta byl 640kB, to 32kB
stanowily 1/20 calej pamieci w komputerze. Teraz srednia ilosc RAMu to
okolo 16MB-32MB. 1/20 z 32MB to okolo 1,5MB.
No i oczywiscie nie doliczam roznego rodzaju swapow.


							pozdrawiam
								Mirek