🚀 go-pugleaf

Marek Kotowski wrote:
> 
> jest to, ze program ze wskaznikami np. huge jest programem
> nieprzenosnym, i to podwojnie, bo uzywa huge i operuje na
> obiektach pamieci wiekszych niz 32767, co zgodnie ze
> standardem, a prawde rzeklszy i z praktyka, jest konstrukcja
> nieprzenosna (proponowane przeze mnie rozwiazanie jest
> oczywiscie przenosne).
>   Moze zreszta sie czepiam. W koncu kto dzis dba o pisanie
> przenosnego kodu? :-)

Co do huge, to zgodze sie w zupelnosci. Natomiast jezeli chodzi o
graniczenia typu 32767...
Policzmy ile to jest, wezmy zmienne double (czyli 8 bajtow - zalezy od
maszyny, ale generalnie nie bedzie to mniej niz tyle). Teraz sprawdzmy
jaka tablice mozemy w takim kawalku zmiesci:
2^15:2^3= 2^12 okolo 4000

Powiedzmy, ze interesuje nas FFT, no to wtedy w takiej tablicy musimy
zmiescic obok siebie Re i Im, czyli wychodzi 2048. Jak na moj gust, to w
zastosowaniach numerycznych to jest __strasznie__  __malo__. Mozna
oczywiscie skladac taka wieksza tablice z mniejszych, i na takim
smiesznym obiekcie przeprowadzac dzialania, ale to jest juz IMHO
rzezbienie w ....., no i ile bedzie trwalo odwolywanie sie do elementow
tablicy.

Przy dzisiejszych wielkosciach RAMu, dbalosc o to, by pojedyncze bloki
byly mniejsze niz 32kB uwazam za pewna przesade.
Czy nie jest tez tak, ze zgodnie z ANSI ostatnio zmieniono 32kB na 64kB?
I czy w ANSI ogranczenie to dotyczy tylko tablic statycznych (caly moj
wywyod dotyczy tylko tablic dynamicznych)?

Tak wiec powiedzialbym w ten sposob: przenosnosc -TAK, ale nie za
wszelka  cene. Poza tym jezeli system nie bedzie w stanie dac tyle RAMu,
to poinformuje o tym program. Tym bardziej, ze i tak taki program bedzie
trzeba najpierw skompilowac i sam proces kompilacji trzeba wczesniej
dostosowac do konkretnego OSa.


							pozdrawiam
								Mirek