🚀 go-pugleaf

Maciej Malinowski <mmalinow@willow.iie.pz.zgora.pl> wrote:
> W jaki sposob mozna zarezerwowac pamiec pod zmienna o wilkosci ok. 300kB
> ( a dokladnie 640x480 b) ?
> Model pamieci Small. Zastosowanie funkcji malloc, farmalloc, new nie
> daje rezultatow. Zwracaja wartosc null.

O ile pamietam, to przy modelu small można mieć tylko 64k danych.

--

Pozdrawiam

                                                Madej

Maciej Malinowski wrote:
> 
> W jaki sposob mozna zarezerwowac pamiec pod zmienna o wilkosci ok. 300kB
> ( a dokladnie 640x480 b) ?
> Model pamieci Small. Zastosowanie funkcji malloc, farmalloc, new nie
> daje rezultatow. Zwracaja wartosc null.

char huge * zmienna = new char huge [300000l];

Pozdrawiam
Darek
D.Michalek@bsb.com.pl

Maciej Malinowski wrote:
> 
> W jaki sposob mozna zarezerwowac pamiec pod zmienna o wilkosci ok. 300kB
> ( a dokladnie 640x480 b) ?

  Duze obszary pamieci sa duzym zlem. :-)
  Zycie uczy, ze zazwyczaj w przypadkach, gdy dane wymagaja
duzej ilosci pamieci, mozna je zorganizowac w mniejsze
obszary, latwiejsze do obslugi.
  Nie wiem, na czym polega aplikacja, o ktorej mowa, ale
- tak na rybke :-) - dlaczego nie mozna tego zorganizowac
w postaci tablicy 640 wskaznikow na obszary po 480 bajtow
kazdy?

  Pozdrawiam

  Marek Kotowski

Maciej Malinowski <mmalinow@willow.iie.pz.zgora.pl> napisa³(a) w artykule <34C4F3AB.C34902CC@willow.iie.pz.zgora.pl>...
> W jaki sposob mozna zarezerwowac pamiec pod zmienna o wilkosci ok. 300kB
> ( a dokladnie 640x480 b) ?
> Model pamieci Small. Zastosowanie funkcji malloc, farmalloc, new nie
> daje rezultatow. Zwracaja wartosc null.
>  W miare mozliwosci prosilbym o odpowiedzi na moj adres.
> Z gory dziekuje za pomoc.
>                                             Maciej Malinowski
> 

Oto fragment helpa z BC 3.1: 

 Remarks:
farmalloc allocates a block of memory nbytes bytes long from the far heap.

NOTE: For allocating from the far heap:
  _ all available RAM can be allocated.
  _ blocks larger than 64K can be allocated.
  _ far pointers are used to access the
    allocated blocks.


Mo¿e:

 1) WskaŸnik, pod którym zapamiêta³eœ adres tego bloku by³ "krótki" (near)? Najlepiej
     ¿eby by³ huge, bo far "zawija" siê na granicy segmentów).

lub

 2) W BC 3.1 jest parametr Options/Debugger/Program heap size - ma znaczenie, jeœli
     "debagujesz" program spod IDE. Standardowo jest ustawione w³aœnie na 64 Kb.

On Wed, 21 Jan 1998 10:24:25 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>Maciej Malinowski wrote:
>> 
>> W jaki sposob mozna zarezerwowac pamiec pod zmienna o wilkosci ok. 300kB
>> ( a dokladnie 640x480 b) ?
>
>  Duze obszary pamieci sa duzym zlem. :-)
>  Zycie uczy, ze zazwyczaj w przypadkach, gdy dane wymagaja
>duzej ilosci pamieci, mozna je zorganizowac w mniejsze
>obszary, latwiejsze do obslugi.
>  Nie wiem, na czym polega aplikacja, o ktorej mowa, ale
>- tak na rybke :-) - dlaczego nie mozna tego zorganizowac
>w postaci tablicy 640 wskaznikow na obszary po 480 bajtow
>kazdy?

 Chocby po to, zeby rysujac kreske nie przeladowywac co kolumne
wskaznika. To juz lepiej by bylo 480 wskaznikow na obszary po 640
bajtow :)

milosz danielewski

Marek Kotowski wrote:
> 
> Maciej Malinowski wrote:
> >
> > W jaki sposob mozna zarezerwowac pamiec pod zmienna o wilkosci ok. 300kB
> > ( a dokladnie 640x480 b) ?
> 
>   Duze obszary pamieci sa duzym zlem. :-)
>   Zycie uczy, ze zazwyczaj w przypadkach, gdy dane wymagaja
> duzej ilosci pamieci, mozna je zorganizowac w mniejsze
> obszary, latwiejsze do obslugi.
>   Nie wiem, na czym polega aplikacja, o ktorej mowa, ale
> - tak na rybke :-) - dlaczego nie mozna tego zorganizowac
> w postaci tablicy 640 wskaznikow na obszary po 480 bajtow
> kazdy?

Ponadto, jezeli nie sa potrzebne jednoczesnie wszystkie dane lub
korzysta sie z nich rzadko, najlepiej je stronicowac w plikach. Wolniej,
ale mniej marnotrawnie :)

	pozdrawiam

-- 
gracjan ziółek
system administrator

milosz danielewski wrote:
> 
> On Wed, 21 Jan 1998 10:24:25 +0100, Marek Kotowski <mkot@imm.org.pl>
> >  Nie wiem, na czym polega aplikacja, o ktorej mowa, ale
> >- tak na rybke :-) - dlaczego nie mozna tego zorganizowac
> >w postaci tablicy 640 wskaznikow na obszary po 480 bajtow
> >kazdy?
> 
>  Chocby po to, zeby rysujac kreske nie przeladowywac co kolumne
> wskaznika. To juz lepiej by bylo 480 wskaznikow na obszary po 640
> bajtow :)

  Napisalem o tablicy 640 wskaznikow, bo to wydalo mi sie
naturalniejsze, gdy czytalem post wyjsciowy. Ale to oczywiscie,
bez znaczenia.

  Co do przeladowywania wskaznika. To jest jedna, czy dwa
zdania wiecej w programie. Jesli Pan dla takiej oszczednosci
chce szukac srodowiska i modeli pamieci, ktore obsluguja
duze obszary pamieci, Panska sprawa i Panski czas, takze
ten zuzyty na wyslanie postu na grupe. Rowniez Panska sprawa,
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? :-)

  Pozdrawiam

  Marek Kotowski

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

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

> 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)?

1. 32 K jest ograniczeniem nakladanym przez standard. Kompilator 
zgodny ze standardem nie ma obowiazku obslugiwac obiektow danych
wiekszych niz 32 K, i to niezaleznie, czy znajduja sie one w
pamieci dynamicznej czy statycznej. 

2. Zwiekszenie limitu 32K do 64K proponuje sie w nowym standardzie
ANSI (przynajmniej takie chodza sluchy). I pewnie autorzy 
standardu z tym sie zgodza. Tym bardziej, ze wiekszosc 
istniejacych kompilatorow akceptuje tablice o takim rozmiarze.
Ale do oficjalnego zatwierdzenia zmiany limitu uplynie jeszcze
troche czasu.

3. Pragne zwrocic uwage, ze w poscie wyjsciowym byl pomysl 
alokacji obszaru ok. 300K. To juz jest konstrukcja, z ktora
- 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.

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? :-)

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.

  Pozdrawiam

  Marek Kotowski

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

On Thu, 22 Jan 1998 17:23:01 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>Mirek Prywata wrote:
>> Co do huge, to zgodze sie w zupelnosci. Natomiast jezeli chodzi o
>> graniczenia typu 32767...
>[...]
>
>> 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)?
>3. Pragne zwrocic uwage, ze w poscie wyjsciowym byl pomysl 
>alokacji obszaru ok. 300K. To juz jest konstrukcja, z ktora
>- 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.

 Bo tego sie nie robi w zadnym huge, tylko flat i wiekszosc
kompilatorow sobie z tym poradzi.

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

 Formalnie to on byl nieprzenosny bo zakladal okreslony rozmiar
wskaznika, co bylo bledem ! Tak wiec byl nieprzenosny od poczatku a
nie po zmianie modelu.

> 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? :-)

 32KB to ma byc malo ? Proponuje poszukac na sieci programow z serii
"4KB intro" albo nawet 256 bajtowych.

milosz danielewski

Mirek Prywata wrote:
> 
> Niedawno ktos sie pytal o 2,5MB. Widocznie potrzebowal.

  Czesto bywa tak, ze ludzie tworza np. wielkie tablice, bo
nie umieja stworzyc struktury danych mniejszej. Klasyczny
przyklad to tablica dwuwymiarowa zamiast tablicy wskaznikow.

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

  Niezupelnie. Problem tkwi takze, a nawet przede wszystkim,
w kompilatorze (a takze w linkerze). To kompilator tworzy
kod wynikowy, a nie system operacyjny.

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

  Nieprawda. Modele pamieci nie sa zwiazane z DOS-em, ale z
procesorami INTEL, ktore pozwalaja stosowac adresy bliskie i
dalekie, i to zarowno dla danych jak i dla kodu. Modele takie
ma Pan takze w Windows.

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

  Tu sie nie zgadzam. Moim zdaniem jest zasadnicza roznica miedzy
przypadkiem, gdy malloc zwraca NULL, bo w systemie nie ma akurat
pamieci, a przypadkiem, gdy NULL jest wynikiem zazadania alokacji
obszaru przekraczajacego w ogole wielkosc dopuszczalna w danej
implementacji C czy srodowisku. To calkowicie rozne rzeczy (w istocie
drugi przypadek mozna traktowac jako blad w programie).
  Jesli chce Pan alokowac odpowiednio duze obszary pamieci, musi sie
Pan upewnic w dokumentacji kompilatora, ze jest to mozliwe i przy
jakich warunkach.

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

  Mowa byla o jezyku C i jego standardzie. Autorzy standardu nie moga
myslec o konkretnych komputerach.

  Pozdrawiam

  Marek Kotowski

milosz danielewski wrote:
>  Formalnie to on byl nieprzenosny bo zakladal okreslony rozmiar
> wskaznika, co bylo bledem ! Tak wiec byl nieprzenosny od poczatku a
> nie po zmianie modelu.

  W definicji np.

  char *Tablica[16000];

nie ma zadnych zalozen co do rozmiaru wskaznika. Rzecz w tym,
ze nigdy nie kompiluje sie programu w srodowisku abstrakcyjnym.
Zawsze musi Pan zakladac (wiedziec), jaki jest rozmiar np.
wskaznika. Jesli Pan to pominie i np. zdefiniuje zbyt duza
tablice, to przywola Pana do porzadku kompilator i/lub linker.

  Marek Kotowski

Mam wra¿enie, ¿e przyk³ada Pan zbyt du¿¹ wagê do formalnych standardów.
Rozumiem, ¿e program napisany dok³adnie w standardzie ANSI skompiluje siê
wszêdzie, ale:

 1) Standardy bior¹ siê z "¿ycia" a nie odwrotnie. Operowanie na wskaŸnikach
     32-bitowych w p³askim modelu pamiêci jest dzisiaj standardem de facto, bo

 2) procesory i systemy 32-bitowe s¹ dzisiaj tak¿e standardem (w domu i w biurze,
     a co dopiero w oœrodkach obliczeniowych)

 3) Dlatego pisanie w œcis³ym ANSI jest nieco "akademickie" - powoduje
     niepotrzebne wydatkowanie energii na rzeczy, które s¹ obs³ugiwane
     przez sprzêt oraz system operacyjny. A jednym z podstawowych postulatów
     efektywnego programowania, jest wykorzystanie tego, co ktoœ ju¿ wczeœniej
     napisa³ (w tym przypadku autorzy OSów).

-----------------------------------------
Jaroslaw Kucypera
mailto:jark@insert.com.pl
-----------------------------------------

Jarek Kucypera wrote:
> 
> Mam wra¿enie, ¿e przyk³ada Pan zbyt du¿¹ wagê do formalnych standardów.

  Przyjmuje to za komplement, nie za zarzut. :-)

>  1) Standardy bior¹ siê z "¿ycia" a nie odwrotnie. 

  Good point, jak mowia Anglicy. :-) Zatem moze trzymanie sie standardu
jest jednak zyciowe. W koncu on tez wzial sie z zycia.

> Operowanie na wskaŸnikach
>      32-bitowych w p³askim modelu pamiêci jest dzisiaj standardem de facto, bo

  Rozmiar wskaznika na ogol nie ma znaczenia w programie. Mysle (ale
nie bede sie upieral), ze dla wiekszosci aplikacji pisanych w C
nie jest istotne, czy wskaznik ma 2 czy 4 bajty. 

> 
>  2) procesory i systemy 32-bitowe s¹ dzisiaj tak¿e standardem (w domu i w biurze,
>      a co dopiero w oœrodkach obliczeniowych)

  Jezyk C nie jest na zaden konkretny procesor. To jest jezyk 
programowania ogolnego zastosowania. Natomiast bez watpienia
jest to jezyk zywy i zmienia sie, jak kazdy zreszta, ktory
jest uzywany. Istniejace procesory moga miec wplyw na zwiekszanie
pewnych limitow w jezyku, zwlaszcza minimalmych zakresow zmiennych,
np. calkowitych. 

> 
>  3) Dlatego pisanie w œcis³ym ANSI jest nieco "akademickie" - powoduje
>      niepotrzebne wydatkowanie energii na rzeczy, które s¹ obs³ugiwane
>      przez sprzêt oraz system operacyjny. A jednym z podstawowych postulatów
>      efektywnego programowania, jest wykorzystanie tego, co ktoœ ju¿ wczeœniej
>      napisa³ (w tym przypadku autorzy OSów).

   Nikt nie pisze w "scislym ANSI", chociazby z powodu funkcji
   bibliotecznych (w C dla Windows inaczej tez nazywa sie funkcja 
   main). To oczywiste. Ale jesli nie ma potrzeby, nie nalezy pisac
   kodu nieprzenosnego. Nigdy nie wiadomo, czy danego fragmentu
   programu nie trzeba bedzie wykorzystac w innym programie pisanym
   na inny kompilator czy komputer.


   Pozdrawiam

   Marek Kotowski

Marek Kotowski <mkot@imm.org.pl> napisa³(a) w artykule <34C89233.435C@imm.org.pl>...
> Jarek Kucypera wrote:
> > 
> > Mam wra¿enie, ¿e przyk³ada Pan zbyt du¿¹ wagê do formalnych standardów.
> 
>   Przyjmuje to za komplement, nie za zarzut. :-)

To by³o raczej stwierdzenie ni¿ zarzut :)

> 
> >  1) Standardy bior¹ siê z "¿ycia" a nie odwrotnie. 
> 
>   Good point, jak mowia Anglicy. :-) Zatem moze trzymanie sie standardu
> jest jednak zyciowe. W koncu on tez wzial sie z zycia.

Mia³em na myœli to, ¿e standardy formalne zostaj¹ "w tyle", zawsze najpierw
ugruntowywuje siê standard "de facto" a póŸniej formalny. Co jest z reszt¹ ca³kiem
zrozumia³e. Zatem trzymanie siê standardu formalnego  mo¿e odcinaæ od aktualnych mo¿liwoœci
(np. mo¿e sk³aniaæ do zabawy z 32kb kawa³kami, kiedy mo¿na bez obaw zaalokowaæ
sobie jedne blok kilkumegabajtowy).

> 
> > Operowanie na wskaŸnikach
> >      32-bitowych w p³askim modelu pamiêci jest dzisiaj standardem de facto, bo
> 
>   Rozmiar wskaznika na ogol nie ma znaczenia w programie. Mysle (ale
> nie bede sie upieral), ze dla wiekszosci aplikacji pisanych w C
> nie jest istotne, czy wskaznik ma 2 czy 4 bajty. 

Otó¿ ma: liczba 16-bitowa pozwala zaadresowaæ 64 kb, 32-bitowa nieco wiêcej.
 
>    Nikt nie pisze w "scislym ANSI", chociazby z powodu funkcji
>    bibliotecznych (w C dla Windows inaczej tez nazywa sie funkcja 
>    main). To oczywiste. Ale jesli nie ma potrzeby, nie nalezy pisac
>    kodu nieprzenosnego. 

Otó¿ w³aœniê sugerujê, ¿e pe³ne wykorzystanie 32 bitów praktycznie jest dzisiaj przenoœne
"Praktycznie" - tzn. miêdzy platformami 32-bitowymi, które, zaryzykuje stwierdzenie, ju¿ 
dominuj¹.


-----------------------------------------
Jaroslaw Kucypera
mailto:jark@insert.com.pl
-----------------------------------------

: Mia?em na my?li to, ?e standardy formalne zostaj? "w tyle", zawsze najpierw
: ugruntowywuje si? standard "de facto" a p??niej formalny. Co jest z reszt? ca?kiem
Kolego Jarosławie powszechnie uznanym standardem jest kodowanie polskich
znaków zgodnie z normą ISO-8859-2, myślę że warto to uznać i w kolejnych
listach na temat standardów to uwzględnić :) 

--
Jarek Libert <libja@pg.gda.pl>
Computer Center, Technical University of Gdansk, Poland

Jarek Kucypera wrote:
> 
> Mia³em na myœli to, ¿e standardy formalne zostaj¹ "w tyle", zawsze najpierw
> ugruntowywuje siê standard "de facto" a póŸniej formalny. Co jest z reszt¹ ca³kiem
> zrozumia³e. Zatem trzymanie siê standardu formalnego  mo¿e odcinaæ od aktualnych mo¿liwoœci
> (np. mo¿e sk³aniaæ do zabawy z 32kb kawa³kami, kiedy mo¿na bez obaw zaalokowaæ
> sobie jedne blok kilkumegabajtowy).

  To oczywiste. Tylko zabawy bywaja do czasu. Jak Pan pisze
duzy projekt programistyczny, ktory ma chodzic w kilku roznych
srodowiskach, w tym takze w DOS-ie, bo jest jeszcze popularny,
i program moze liczyc na zbyt wsrod uzytkownikow DOS-u (a zatem
Panska firma miec z tego dodatkowe pieniadze :-)), inaczej Pan
rzecz traktuje.

> >   Rozmiar wskaznika na ogol nie ma znaczenia w programie. Mysle (ale
> > nie bede sie upieral), ze dla wiekszosci aplikacji pisanych w C
> > nie jest istotne, czy wskaznik ma 2 czy 4 bajty.
> 
> Otó¿ ma: liczba 16-bitowa pozwala zaadresowaæ 64 kb, 32-bitowa nieco wiêcej.

  To tez oczywiste. Ale jak Pan adresuje pamiec, definiujac zmienna
lokalna char *p, to czy Pan mysli o wielkosci wskaznika? Nie. Poza
tym wiekszosc kodu najczesciej uzywa wskaznikow do adresowania 
malych obszarow. I to mialem na mysli.

> 
> Otó¿ w³aœniê sugerujê, ¿e pe³ne wykorzystanie 32 bitów praktycznie jest dzisiaj przenoœne
> "Praktycznie" - tzn. miêdzy platformami 32-bitowymi, które, zaryzykuje stwierdzenie, ju¿
> dominuj¹.
> 

  To prawda, ze dominuja. Jak Pan pisze kod dla okreslonej
grupy maszyn, to on dziala tylko na tych maszynach i na ich
systemach operacyjnych. I oczywiscie kod, ktory wymaga 
maszyny 32-bitowej, jest nieprzenosny na maszyny 16-bitowe.
W gruncie rzeczy chodzi tez o zasade stylistyczna. Nie wiem,
czy widzial Pan kiedys standardy kodowania obowiazujace w
firmach produkujacych oporgramowanie. Jednym z podstawowych
zalecen ogolnych jest czesto, by pisac kod przenosnie, a 
to co nieprzenosne, obudowywac (tworzyc fuinkcje posredniczace).
Najwyrazniej pisznie kodu przenosnego im sie oplaca. Moga
go latwiej uzyc w innych programach. Kod przenosny na ogol
tez zawiera mniej bledow, bo nie uzywa nietypowych i
niebezpiecznych konstrukcji.

  Pozdrawiam

  Marek Kotowski

On Fri, 23 Jan 1998 12:10:41 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>milosz danielewski wrote:
>>  Formalnie to on byl nieprzenosny bo zakladal okreslony rozmiar
>> wskaznika, co bylo bledem ! Tak wiec byl nieprzenosny od poczatku a
>> nie po zmianie modelu.
>
>  W definicji np.
>
>  char *Tablica[16000];
>
>nie ma zadnych zalozen co do rozmiaru wskaznika. Rzecz w tym,
>ze nigdy nie kompiluje sie programu w srodowisku abstrakcyjnym.
>Zawsze musi Pan zakladac (wiedziec), jaki jest rozmiar np.
>wskaznika. Jesli Pan to pominie i np. zdefiniuje zbyt duza
>tablice, to przywola Pana do porzadku kompilator i/lub linker.

 W odpowiedzi zacytuje twoje wlasne slowa:
"  Mowa byla o jezyku C i jego standardzie. Autorzy standardu nie moga
myslec o konkretnych komputerach."
 Z wszystkich twoich wczesniejszych wywodow niezbicie wynika, ze
program przenosny i zgodny ze standardem nie moze poslugiwac sie
statycznymi tablicami zlozonymi z innych elementow niz char.

milosz danielewski

On Fri, 23 Jan 1998 17:32:08 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>> Otóż właśnię sugeruję, że pełne wykorzystanie 32 bitów praktycznie jest dzisiaj przenośne
>> "Praktycznie" - tzn. między platformami 32-bitowymi, które, zaryzykuje stwierdzenie, już
>> dominują.
>> 
>
>  To prawda, ze dominuja. Jak Pan pisze kod dla okreslonej
>grupy maszyn, to on dziala tylko na tych maszynach i na ich
>systemach operacyjnych. I oczywiscie kod, ktory wymaga 
>maszyny 32-bitowej, jest nieprzenosny na maszyny 16-bitowe.
>W gruncie rzeczy chodzi tez o zasade stylistyczna. Nie wiem,
>czy widzial Pan kiedys standardy kodowania obowiazujace w
>firmach produkujacych oporgramowanie. Jednym z podstawowych
>zalecen ogolnych jest czesto, by pisac kod przenosnie, a 
>to co nieprzenosne, obudowywac (tworzyc fuinkcje posredniczace).
>Najwyrazniej pisznie kodu przenosnego im sie oplaca. Moga
>go latwiej uzyc w innych programach. Kod przenosny na ogol
>tez zawiera mniej bledow, bo nie uzywa nietypowych i
>niebezpiecznych konstrukcji.

 Przenosnosc w _wystarczajacym_ stopniu zapewnia samo C. Oczywiscie
program nie jest przenosny ale latwy do portowania. Zbytnie kladzenie
nacisku na przenosnosc to marnotrawstwo czasu i pieniedzy. Nawet
piszac zgodnie ze standardem, program ktory bedzie probowal alokowac
32KB pamieci na b. popularnym procesorze 51, nie zadziala bo do
dyspozycji mamy 256 calej pamieci RAM. Wiec na co mi ta teoretyczna
przenosnosc, skoro w praktyce i tak bede musial program napisac od
nowa ?



>
>  Pozdrawiam
>
>  Marek Kotowski

milosz danielewski

milosz danielewski wrote:
>  Z wszystkich twoich wczesniejszych wywodow niezbicie wynika, ze
> program przenosny i zgodny ze standardem nie moze poslugiwac sie
> statycznymi tablicami zlozonymi z innych elementow niz char.
> 

  Prosze mi podac przynajmniej jeden cytat z moich
wypowiedzi, z ktorego wynika - niekoniecznie niezbicie - ze
program przenosny i zgodny ze standardem nie moze 
miec tablic statycznych innego typu niz char.

  Marek Kotowski

milosz danielewski wrote:
>  Przenosnosc w _wystarczajacym_ stopniu zapewnia samo C. 

  Calkowita nieprawda.
  Mozna napisac kod poprawny w C, nawet w standardzie (tylko
standardowe slowa kluczowe i standardowe funkcje biblioteczne),
ktory nie bedzie przenosny do innych komputerow/kompilatorow, bo np.
uzywa nieprzenosnie unii, zaklada okreslony znak zmiennej
znakowej (char), zaklada pakowanie lub nie struktur, zaklada
okreslony rozmiar i sposob traktowania struktur bitowych, przyjmuje
okreslony porzadek obliczen (efekty uboczne) tam, gdzie
jest on nieokreslony, bazuje na okreslonym uporzadkowaniu
bajtow w slowie czy w podwojnym slowie. 
  Wystarczy?

> Oczywiscie
> program nie jest przenosny ale latwy do portowania. Zbytnie kladzenie
> nacisku na przenosnosc to marnotrawstwo czasu i pieniedzy. 

  Znowu nieprawda. Jest dokladnie odwrotnie. Oczywiscie,
w kazdym powazniejszym programie sa fragmenty nieprzenosne.
Ale dobry programista zazwyczaj je odpowiednio obudowuje.

> Nawet
> piszac zgodnie ze standardem, program ktory bedzie probowal alokowac
> 32KB pamieci na b. popularnym procesorze 51, nie zadziala bo do
> dyspozycji mamy 256 calej pamieci RAM. Wiec na co mi ta teoretyczna
> przenosnosc, skoro w praktyce i tak bede musial program napisac od
> nowa ?

  Cala dyskusja toczy sie wokol duzych obszarow pamieci.
To wcale nie jest powazny problem przy przenoszeniu programow w C.

  Marek Kotowski

On Sat, 24 Jan 1998, Marek Kotowski wrote:

> >  Przenosnosc w _wystarczajacym_ stopniu zapewnia samo C. 
> 
>   Calkowita nieprawda.
>   Mozna napisac kod poprawny w C, nawet w standardzie (tylko
> standardowe slowa kluczowe i standardowe funkcje biblioteczne),
> ktory nie bedzie przenosny do innych komputerow/kompilatorow, bo np.
> uzywa nieprzenosnie unii, zaklada okreslony znak zmiennej
> znakowej (char), zaklada pakowanie lub nie struktur, zaklada
> okreslony rozmiar i sposob traktowania struktur bitowych, przyjmuje
> okreslony porzadek obliczen (efekty uboczne) tam, gdzie
> jest on nieokreslony, bazuje na okreslonym uporzadkowaniu
> bajtow w slowie czy w podwojnym slowie. 
>   Wystarczy?

Nie zgodzę się z taką definicją przenośności. Przenośność nie musi
_uniemożliwiać_ napisania programu, który na różnych platformach różnie
się wykona. IMHO do przenośności języka wystarczy, żeby dało się w nim
pisać przenośne programy bez istotnej straty możliwości i wygody (i żeby
było jasno udokumentowane, które konstrukcje są przenośne).

Oczywiście im więcej konstrukcji zachowuje się tak samo na różnych
platformach, tym lepiej.

Stwierdzę nawet, że _nie da_ się napisać idealnie przenośnego języka
(który zapewniałby pewne minimum możliwości). Otóż w Unixach końce linii
plików tekstowych są zapisywane inaczej niż w DOSie. W obu systemach nie
ma formalnego rozróżnienia plików tekstowych i binarnych. Czy jeśli
język pozwala utworzyć plik tekstowy i pozwala odczytać plik binarny, to
jest automatycznie nieprzenośny?

Z innej dziedziny: Twierdzę, że HTML jest przenośny. Mimo że w różnych
przeglądarkach i w różnych trybach graficznych wygląda różnie. Istnieją
różne rozszerzenia HTMLa konkretnych przeglądarek - one są nieprzenośne,
ale nikt nie zmusza do ich stosowania. Używając standardowego HTMLa
można tworzyć strony, które w różnych warunkach będą różnie wyglądały
(nie da się inaczej!), ale każdy wygląd jest równie "poprawny" i HTML
jako taki jest przenośny.

>   Znowu nieprawda. Jest dokladnie odwrotnie. Oczywiscie,
> w kazdym powazniejszym programie sa fragmenty nieprzenosne.
> Ale dobry programista zazwyczaj je odpowiednio obudowuje.

Z tym się zgadzam. Z reguły im więcej przenośności tym lepiej.

-- 
                                 QRCZAK
    __("<              Marcin Kowalczyk
    \__/              qrczak@knm.org.pl
     ^^      http://qrczak.home.ml.org/

> On Sat, 24 Jan 1998, Marek Kotowski wrote:
>
> >  Przenosnosc w _wystarczajacym_ stopniu zapewnia samo C.

   Ja bardzo przepraszam, ze sie wtracam, ale mi chodzilo tylko odpowiedz
jak zarezerwowac obszar pamiecio wielkosci ok 300 kb. Wcale nie twierdzilem,
ze kod programu ma byc przenaszalny w jakikolwiek sposob.

                                                                 Maciej
Malinowski

On Sat, 24 Jan 1998 15:13:18 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>milosz danielewski wrote:
>>  Z wszystkich twoich wczesniejszych wywodow niezbicie wynika, ze
>> program przenosny i zgodny ze standardem nie moze poslugiwac sie
>> statycznymi tablicami zlozonymi z innych elementow niz char.
>> 
>
>  Prosze mi podac przynajmniej jeden cytat z moich
>wypowiedzi, z ktorego wynika - niekoniecznie niezbicie - ze
>program przenosny i zgodny ze standardem nie moze 
>miec tablic statycznych innego typu niz char.

 Masz racje, musze sie poprawic. Wg. twoich twierdzen, mozna
wnioskowac, ze zaden program zawierajacy tablice nie jest zgodny ze
standardem. Poniewaz nie mozemy robic zalozen odnosnie rozmiaru
elementu ergo: nie mozemy deklarowac tablic i miec pewnosc, ze beda
mniejsze niz 32KB.

milosz danielewski

On Sat, 24 Jan 1998 15:26:02 +0100, Marek Kotowski <mkot@imm.org.pl>
wrote:

>milosz danielewski wrote:
>>  Przenosnosc w _wystarczajacym_ stopniu zapewnia samo C. 
>
>  Calkowita nieprawda.
>  Mozna napisac kod poprawny w C, nawet w standardzie (tylko
>standardowe slowa kluczowe i standardowe funkcje biblioteczne),
>ktory nie bedzie przenosny do innych komputerow/kompilatorow, bo np.
>uzywa nieprzenosnie unii, zaklada okreslony znak zmiennej
>znakowej (char), zaklada pakowanie lub nie struktur, zaklada
>okreslony rozmiar i sposob traktowania struktur bitowych, przyjmuje
>okreslony porzadek obliczen (efekty uboczne) tam, gdzie
>jest on nieokreslony, bazuje na okreslonym uporzadkowaniu
>bajtow w slowie czy w podwojnym slowie. 
>  Wystarczy?

 Sprytne cytowanie, zmieniajace kontekst mojej wypowiedzi, nie zmienia
faktu, ze mialem na mysli co innego. _Wyraznie_ w nastepnym zdaniu
napisalem, ze: "Oczywiscie program nie jest przenosny ale latwy do
portowania". Z wiekszosci wymienionych przez ciebie cech kompilatora (
char ze znakiem lub bez, pakowanie struktur etc.) dobry programista
_nie_ korzysta bo i po co ?

>> Oczywiscie
>> program nie jest przenosny ale latwy do portowania. Zbytnie kladzenie
>> nacisku na przenosnosc to marnotrawstwo czasu i pieniedzy. 
>
>  Znowu nieprawda. Jest dokladnie odwrotnie. Oczywiscie,
>w kazdym powazniejszym programie sa fragmenty nieprzenosne.
>Ale dobry programista zazwyczaj je odpowiednio obudowuje.

 Widze, ze mimo wszystko sie ze mna zgadzasz. Prosciej/szybciej/taniej
jest napisac kilka #ifdef niz ze wszelka cene walczyc o pelna
przenosnosc. 

>> Nawet
>> piszac zgodnie ze standardem, program ktory bedzie probowal alokowac
>> 32KB pamieci na b. popularnym procesorze 51, nie zadziala bo do
>> dyspozycji mamy 256 calej pamieci RAM. Wiec na co mi ta teoretyczna
>> przenosnosc, skoro w praktyce i tak bede musial program napisac od
>> nowa ?
>
>  Cala dyskusja toczy sie wokol duzych obszarow pamieci.
>To wcale nie jest powazny problem przy przenoszeniu programow w C.

 W skali platformy 51, 32KB pamieci to _bardzo_ duzy obszar. Chcialem
ponadto zauwazyc, ze to ty rozpoczales dyskusje twierdzac, ze
przydzialy duzych obszarow to powazny problem przy przenoszeniu
programow w C. Przeczysz sam sobie.

milosz danielewski

milosz danielewski wrote:
>  Sprytne cytowanie, zmieniajace kontekst mojej wypowiedzi, nie zmienia
> faktu, ze mialem na mysli co innego. _Wyraznie_ w nastepnym zdaniu
> napisalem, ze: "Oczywiscie program nie jest przenosny ale latwy do
> portowania". Z wiekszosci wymienionych przez ciebie cech kompilatora (
> char ze znakiem lub bez, pakowanie struktur etc.) dobry programista
> _nie_ korzysta bo i po co ?
> 

  Tu tez sie nie moge zgodzic. Prosze Pana, problem nie polega na
tym, czy programista chce korzystac, czy nie. On korzysta sila
rzeczy. Albowiem duza czesc spraw, o ktorych pisalem, jest z definicji
zalezna od implementacji jezyka. Nie moze Pan nie korzystac z tych
"cech kompilatora", jesli Pan chce uzywac kompilatora. Jeden 
kompilator przyjmuje domyslne pakowanie struktur, inny nie.
Jeden ma takie zalozenia co do struktur bitowych, inny - inne.
Jeden przyjmuje domyslnie, ze zmienna typu char jest ze znakiem,
inny - nie. Cokolwiek Pan pisze w C, korzysta Pan - byc moze
nieswiadomie - z odpowiednich ustawien kompilatora.
   
> 
>  Widze, ze mimo wszystko sie ze mna zgadzasz. Prosciej/szybciej/taniej
> jest napisac kilka #ifdef niz ze wszelka cene walczyc o pelna
> przenosnosc.

  Dyrektywy #ifdef sa pozyteczne, ale jak jest ich zbyt wiele,
zaciemniaja kod. Moze byc nie wiadomo, ktore fragmenty sa
kompilowane w danym przypadku.

>  W skali platformy 51, 32KB pamieci to _bardzo_ duzy obszar. Chcialem
> ponadto zauwazyc, ze to ty rozpoczales dyskusje twierdzac, ze
> przydzialy duzych obszarow to powazny problem przy przenoszeniu
> programow w C. Przeczysz sam sobie.

  Jak Pan chce tak uznac, to sie moge zgodzic. Prawda jest,  
ze jesli jest aplikacja, ktora bazuje na wielkich obszarach
danych, to dyskusji nie ma - szuka sie platform, ktore 
pozwalaja budowac takie aplikacje. Jesli praca na wielkich
obszarach pamieci jest jedna z opcji programu, to operacje
na takich pamieciach mozna obudowac w funkcji czy w module. Innymi
slowy: wydzielic czesc nieprzenosna. Przy przenoszeniu np. na
inny komputer mozna zamienic modul na inny, inaczej obslugujacy
pamiec, moze wolniejszy, ale przeciez zapewniajacy poprawne
dzialanie programu. Robilem takie rzeczy kilka razy - to 
naturalny zabieg.

  Pozdrawiam

  Marek Kotowski

milosz danielewski wrote:
>  Sprytne cytowanie, zmieniajace kontekst mojej wypowiedzi, nie zmienia
> faktu, ze mialem na mysli co innego. _Wyraznie_ w nastepnym zdaniu
> napisalem, ze: "Oczywiscie program nie jest przenosny ale latwy do
> portowania". Z wiekszosci wymienionych przez ciebie cech kompilatora (
> char ze znakiem lub bez, pakowanie struktur etc.) dobry programista
> _nie_ korzysta bo i po co ?
> 

A czy _dobremu_programiscie_ zdazylo sie napisac procedure konwertujaca
rozne standardy 'polskich' znaczkow majac domyslnego char'a ze znakiem ?
Ubaw po pachy. A moze by tak _dobry_programista_ sprobowal jakichs zabaw
z mapami bitowymi czy czegos innego co wymaga przesuniec bitowych nie
zastanawiajac sie przy tym, czy char jest ze znakiem, czy bez. Milego
debuggowania. Albo na przyklad prosze napisac program ktory korzysta z
tego samego pliku w roznych systemach operacyjnych (np. DOS i SCO UNIX),
przy czym zapis tekstowy danych nie wchodzi w rachube z roznych wzgledow
(marketingowych powiedzmy). Chyba, ze _dobrzy_programisci_ nuie zajmuja
sie tak trywialnymi rzeczami? A, to przepraszam, wole w takim razie
pozostac _zlym_programista_.

Pozdrawiam
Pawel

Qrczak wrote:
> >   Mozna napisac kod poprawny w C, nawet w standardzie (tylko
> > standardowe slowa kluczowe i standardowe funkcje biblioteczne),
> > ktory nie bedzie przenosny do innych komputerow/kompilatorow, bo np.
> > uzywa nieprzenosnie unii, zaklada okreslony znak zmiennej
> > znakowej (char), zaklada pakowanie lub nie struktur, zaklada
> > okreslony rozmiar i sposob traktowania struktur bitowych, przyjmuje
> > okreslony porzadek obliczen (efekty uboczne) tam, gdzie
> > jest on nieokreslony, bazuje na okreslonym uporzadkowaniu
> > bajtow w slowie czy w podwojnym slowie.
> >   Wystarczy?
> 
> Nie zgodzê siê z tak± definicj± przeno¶no¶ci. Przeno¶no¶æ nie musi
> _uniemo¿liwiaæ_ napisania programu, który na ró¿nych platformach ró¿nie
> siê wykona. IMHO do przeno¶no¶ci jêzyka wystarczy, ¿eby da³o siê w nim
> pisaæ przeno¶ne programy bez istotnej straty mo¿liwo¶ci i wygody (i ¿eby
> by³o jasno udokumentowane, które konstrukcje s± przeno¶ne).
> 

  Alez tu nie ma zadnej definicji przenosnosci, a zwlaszcza,
co to jest program przenosny (to oddzielny temat). Tu jest tylko
wskazanie, ze z zasady w jezyku C sa rzeczy, ktore - ex definitione -
sa pozostawione implementacji jezyka. Kto na nich bazuje, tworzy
kod nieprzenosny (to latwiej zdefiniowac niz kod przenosny). 
Panska uwaga o "jasnym udokumentowaniu" jest sluszna 
- standard formuluje, co jest zalezne od implementacji,
co nieokreslone, a co niezdefiniowane. Kompilator, czy szerzej:
implementacja C (moze to byc np. interpreter) moze te rzeczy 
dookreslic i dodefiniowac, ale korzystanie z tego czyni program 
nieprzenosnym np. do innych kompilatorow.

  Pozdrawiam

  Marek Kotowski

Jaros/law Libert <libja@faraon.oi.pg.gda.pl> napisa³(a) w artykule <6aagkk$ojo$1@sunrise.pg.gda.pl>...

> znaków zgodnie z norm± ISO-8859-2, my¶lê ¿e warto to uznaæ i w kolejnych
> listach na temat standardów to uwzglêdniæ :) 

Zgadzam siê ... niestety u¿ywam MS Mail&News, któren  to czasami miewa odpa³y
(przynajmniej ten u mnie) i zmienia mi "ogonki" na ISO-8859-1, nie racz¹c mnie
o tym drobnym fakcie powiadomiæ ...

Marek Kotowski <mkot@imm.org.pl> napisa³(a) w artykule <34C8C608.7701@imm.org.pl>...
> Jarek Kucypera wrote:

>   To oczywiste. Tylko zabawy bywaja do czasu. Jak Pan pisze
> duzy projekt programistyczny, ktory ma chodzic w kilku roznych
> srodowiskach, w tym takze w DOS-ie, bo jest jeszcze popularny,
> i program moze liczyc na zbyt wsrod uzytkownikow DOS-u (a zatem
> Panska firma miec z tego dodatkowe pieniadze :-)), inaczej Pan
> rzecz traktuje.

Teza prawdziwa, tylko za³o¿enie ("w tym tak¿e w DOS-ie") dobrane na 
potrzeby tezy.
Otó¿ ja ca³y czas piszê o aplikacjach 32-bitowych i do takich zawê¿y³em
ow¹ "przenoœnoœæ praktyczn¹".
 
>   To tez oczywiste. Ale jak Pan adresuje pamiec, definiujac zmienna
> lokalna char *p, to czy Pan mysli o wielkosci wskaznika? Nie.

Myœlê, bo s¹ to problemy równowa¿ne. Jeœli chcê mieæ du¿e bloki,
to muszê mieæ du¿e wskaŸniki. Jeœli mam du¿e wskaŸniki, to mam du¿e
bloki.

> Poza
> tym wiekszosc kodu najczesciej uzywa wskaznikow do adresowania 
> malych obszarow. I to mialem na mysli.

Ale akurat omawiany problem dotyczy du¿ych obszarów.
 
> > 
> > Otó¿ w³aœniê sugerujê, ¿e pe³ne wykorzystanie 32 bitów praktycznie jest dzisiaj przenoœne
> > "Praktycznie" - tzn. miêdzy platformami 32-bitowymi, które, zaryzykuje stwierdzenie, ju¿
> > dominuj¹.
> > 
> 
>   To prawda, ze dominuja. Jak Pan pisze kod dla okreslonej
> grupy maszyn, to on dziala tylko na tych maszynach i na ich
> systemach operacyjnych. I oczywiscie kod, ktory wymaga 
> maszyny 32-bitowej, jest nieprzenosny na maszyny 16-bitowe.
> W gruncie rzeczy chodzi tez o zasade stylistyczna. Nie wiem,
> czy widzial Pan kiedys standardy kodowania obowiazujace w
> firmach produkujacych oporgramowanie.

Akurat tak zarabiam na ¿ycie

> Jednym z podstawowych
> zalecen ogolnych jest czesto, by pisac kod przenosnie, a 
> to co nieprzenosne, obudowywac (tworzyc fuinkcje posredniczace).
> Najwyrazniej pisznie kodu przenosnego im sie oplaca. Moga
> go latwiej uzyc w innych programach. Kod przenosny na ogol
> tez zawiera mniej bledow, bo nie uzywa nietypowych i
> niebezpiecznych konstrukcji.

Trochê zmieniamy temat dyskusji ... Nie wiem, czy jest dzisiaj sens
tworzenia nowych aplikacji w œrodowisku 16-bitowym. Dlatego
tworzenie kodu uniwersalnego (16 i 32) mo¿e byæ nieop³acalne.

Generalnie zalety przenoœnoœci kodu pozostaj¹ oczywiœcie poza dyskusj¹. 
Lecz nie zawsze op³aca siê "wpuszczaæ parê" w prznoœnoœæ biblioteki pisanej
pod Unix'a, której nikt nie bêdzie chcia³ uzywaæ pod DOS'em, bo czas
to pieni¹dz.  No, chyba ¿e dla przyjemnoœci ...

-----------------------------------------
Jaroslaw Kucypera
mailto:jark@insert.com.pl
-----------------------------------------

milosz danielewski wrote:
> >  Prosze mi podac przynajmniej jeden cytat z moich
> >wypowiedzi, z ktorego wynika - niekoniecznie niezbicie - ze
> >program przenosny i zgodny ze standardem nie moze
> >miec tablic statycznych innego typu niz char.
> 
>  Masz racje, musze sie poprawic. Wg. twoich twierdzen, mozna
> wnioskowac, ze zaden program zawierajacy tablice nie jest zgodny ze
> standardem. Poniewaz nie mozemy robic zalozen odnosnie rozmiaru
> elementu ergo: nie mozemy deklarowac tablic i miec pewnosc, ze beda
> mniejsze niz 32KB.

  Ten post jest tak sformulowany, ze nie wiadomo - przynajmniej ja 
nie wiem - czy to jest przyznanie, ze Pan nie mial racji, czy tez
inaczej sformulowany ten sam zarzut (swoja droga, to sztuka tak
pisac :-)). Przyjmuje pierwsze zdanie za prawdziwe (pierwsza
odpowiedz sie liczy :-)).

  Pozdrawiam

  Marek Kotowski


PS. Dla jasnosci: zgodnie ze standardem nie sa przenosne obiekty,
    takie, ze sizeof(obiekt)>32K. Scislej: kompilator takich obiektow
    nie musi obslugiwac i z tego powodu nie bedzie niezgodny ze
    standardem.

On Mon, 26 Jan 1998 10:42:14 +0100, Pawel Piotrowski
<pietras@sopot.lex.pl> wrote:

>> Z wiekszosci wymienionych przez ciebie cech kompilatora (
>> char ze znakiem lub bez, pakowanie struktur etc.) dobry programista
>> _nie_ korzysta bo i po co ?
>> 
>
>A czy _dobremu_programiscie_ zdazylo sie napisac procedure konwertujaca
>rozne standardy 'polskich' znaczkow majac domyslnego char'a ze znakiem ?

 Dobry programista robi tak:
#define byte unsigned char

>Albo na przyklad prosze napisac program ktory korzysta z
>tego samego pliku w roznych systemach operacyjnych (np. DOS i SCO UNIX),
>przy czym zapis tekstowy danych nie wchodzi w rachube z roznych wzgledow
>(marketingowych powiedzmy).

 Slaby przyklad - DOS i SCO sa na ta sama platforme wiec bajty w
slowie sa w tej samej kolejnosci. Rozumiem jednak intencje, w
przypadku little-, big-endian albo czytamy z pliku po bajcie, albo
stosujemy #ifdef. Nalezy to jednak traktowac jako zlo konieczne a nie
rzecz, ktora sie wykorzystuje.

 Obie wymienione powyzej rzeczy nie sa nawet w polowie tak uciazliwe
jak domyslne pakowanie struktur, na ktorym zdecydowanie latwiej sie
poslizgnac.

>Pozdrawiam

pozdrowienia od _dobrych_programistow dla _zlych_programistow !

milosz danielewski

milosz danielewski wrote:
> 
> On Mon, 26 Jan 1998 10:42:14 +0100, Pawel Piotrowski
> <pietras@sopot.lex.pl> wrote:
> 
> >> Z wiekszosci wymienionych przez ciebie cech kompilatora (
> >> char ze znakiem lub bez, pakowanie struktur etc.) dobry programista
> >> _nie_ korzysta bo i po co ?
> >>
> >
> >A czy _dobremu_programiscie_ zdazylo sie napisac procedure konwertujaca
> >rozne standardy 'polskich' znaczkow majac domyslnego char'a ze znakiem ?
> 
>  Dobry programista robi tak:
> #define byte unsigned char

To ja nie rozumiem. To czy korzysta z char ze znakiem czy bez , czy tez
nie. Bo to co widze to makro dla preprocesora, ktore zmieni napisy
'byte' na 'unsigned char'. A to chyba jest wykorzystanie char ze znakiem
lub bez. Ogolnie z Twojego (jeszcze poprzedniego) listu zrozumialem, ze
postulujesz nie przejmowanie sie tego typu  rzeczami jak znak char. Po
prostu piszesz 'char' i program ma dzialac. A to nieprawda, na co
podalem przyklady.

>  Slaby przyklad - DOS i SCO sa na ta sama platforme wiec bajty w
> slowie sa w tej samej kolejnosci. Rozumiem jednak intencje, w
> przypadku little-, big-endian albo czytamy z pliku po bajcie, albo
> stosujemy #ifdef. Nalezy to jednak traktowac jako zlo konieczne a nie
> rzecz, ktora sie wykorzystuje.
> 
>  Obie wymienione powyzej rzeczy nie sa nawet w polowie tak uciazliwe
> jak domyslne pakowanie struktur, na ktorym zdecydowanie latwiej sie
> poslizgnac.

Przyklad ani silny, ani slaby, wziety z zycia. Program skompilowany pod
16 bit DOS, upakowanie struktur do bajta. Struktury 'na zywca ' czytane
z pliku. Program w SCO ma czytac te same dane (bo nikt nie bedzie
tloczyl osobnego CD dla tej platformy (zbyt mala ilosc klientow)).
Program skompilowany z domyslnymi parametrami ( a wiec zgodnie z Twoim
postulatem nie przejmowania sie cechami kompilatora w rodzaju pakowania
struktur) pakuje struktury do 4 bajtow. I nie ma wyjscia, trzeba sie
zaczac interesowac ww. cechami kompilatora, nawet ryzykujac, ze sie
zostanie _zlym_programista_. Oczywiscie zgadzam sie, ze w przypadku
przenoszenia danych na inne platformy - te z 'big endian' sprawy sie
jeszcze bardziej komplikuja, z mozliwoscia upakowania danych do bajta na
tych platformach tez roznie bywa.

Tak wiec, o ile rozumiem intencje, to sugerujesz ze ustawiemie
kompilatorowi opcji aby wszystkie char traktowal bez znaku jest w zlym
stylu, pisanie 'unsigned char' jest w dobrym. Podobnie z pakowaniem
struktur ( te akurat mozna przestawiac przy pomocy #pragm). Tylko , ze w
obydwu przypadkach korzystasz z tego samego mechanizmu, a w dodatku przy
kompilacji w C++ wywolanie np. jakiejkolwiek funkcji z tak przekazanym
parametrem, zadeklarowanym jako 'unsigned char' generuja warning (mowie
tu o BC5 i wlaczeniu pelnego 'warningowania'). Tak wiec
_dobry_programista_ naraza sie kilkadziesiat nic nie znaczacych (tzn.
nie szkodliwych) warningow, miedzy ktorymi moze sie ukryc jakies powazne
ostrzezenie.

Konczac ten przudlugi list - uwazam ze nie da sie _w_pelni_swiadomie_
programowac, nie korzystajac z takic cech kompilatora o ktoryc tu mowa
(i wielu innych o ktorych tu nie bylo mowy).I owszem, ma to zwiazek z
byciem  dobrym lub zlym programista - albo sie wie co sie robi, albo
nie.

Pozdrawiam
Pawel

Pawel Piotrowski wrote:
 
> Tak wiec, o ile rozumiem intencje, to sugerujesz ze ustawiemie
> kompilatorowi opcji aby wszystkie char traktowal bez znaku jest w zlym
> stylu, pisanie 'unsigned char' jest w dobrym. Podobnie z pakowaniem
> struktur ( te akurat mozna przestawiac przy pomocy #pragm). Tylko , ze w
> obydwu przypadkach korzystasz z tego samego mechanizmu, a w dodatku przy
> kompilacji w C++ wywolanie np. jakiejkolwiek funkcji z tak przekazanym
> parametrem, zadeklarowanym jako 'unsigned char' generuja warning (mowie
> tu o BC5 i wlaczeniu pelnego 'warningowania'). 

Tu autopoprawka. Mialem na mysli funkcje bibliotrczne, przyjmujace
parametry char, char * itd., cztli wszystkie printf,sprintf,
strcat,strcpy idt. itp. Funkcje ktore sam zadeklarujesz w ten sposob nie
beda generowac warningow.

Pozdrawiam
Pawel

Marek Kotowski <mkot@imm.org.pl> wrote:
: 3. Pragne zwrocic uwage, ze w poscie wyjsciowym byl pomysl 
: alokacji obszaru ok. 300K. To juz jest konstrukcja, z ktora
: - 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.
Mozliwe. Ale nie wszystkie komputery maja takie problemy z obsluga pamieci.

: 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? :-)

Prawde rzeklszy, to blaszak wlasnie jest jedynym liczacym sie dzisiaj 
komputerem, gdzie w programie moga wystapic 16-bitowe wskazniki. Moim zdaniem
dobre to bylo ( i to tez nie do konca ) w Atari 65 XE, no ale cos poczac jak 
sie ma takie obciazenia dziedziczne. Wszyscy maja ten problem, a rozwiazaniem
moze byc tylko wyrzucenie go w cholere (zartowalem).
Rzeczywiscie, male jest piekne, a juz na pewno bardzo efektywne.

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

No... roznie jest z ta przenosnoscia. W wymienionym przykladzie akurat
lepiej bylo przydzic pamiec na 480 wskaznikow, a kazdemu pamiec na 640
bajtow. Jezeli jednak mial to byc bufor dla ekranu, to nie bedzie to
specjalnie efektywne.

-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

Maciej Malinowski <mmalinow@willow.iie.pz.zgora.pl> wrote:
: W jaki sposob mozna zarezerwowac pamiec pod zmienna o wilkosci ok. 300kB
: ( a dokladnie 640x480 b) ?
: Model pamieci Small. Zastosowanie funkcji malloc, farmalloc, new nie
: daje rezultatow. Zwracaja wartosc null.

Nie da sie. Masz dwa wyjscia:

1. Przydzielac pamiec w blokach po 64k i napisac wlasne funkcje, ktore
beda dawaly dostep do odpowiedniego elementu tablicy, odpowiednio go
przeliczajac.

2. Zmienic kompilator. Uzywaj WatCom'a lub gcc (DJGPP). Juz one sie postaraja
przydzielic ci tyle pamieci (i to obsluzyc, nawet kosztem wolniejszego
dostepu).

Pozdrawiam, 

-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

Mirek Prywata <mpry@fuw.edu.pl> wrote:
: Co do huge, to zgodze sie w zupelnosci. Natomiast jezeli chodzi o
: graniczenia typu 32767...
: 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.

Jak to sie dzialo, ze w WatComie kazalem sobie przydzielic pamiec na
tablice wielkosci 4MB i .... przydzielil!

: 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)?

Przepraszam, ale pierwsze slysze, zeby ANSI wtrynial sie do ilosci
przydzielanej pamieci. Wspomniane 4MB na pewno przydzieli mi rowniez DJGPP.
Ale nie Borland C++ 3.1. Tak wiec to nie jest chyba sprawa ANSI, ale
tego zlomu, na ktory sie kompiluje program.

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

Albo zastosowac kompilacje warunkowa.
No ale powiedzmy sobie szczerze: jak programista pisze duzy program, to
raczej z gory okresla, na jakie systemy bedzie to pisal. Dla innych trzeba
go dostosowac (sam pamietam, jak kompilowalem ROM-a 2.4 (Rivers Of Mud) pod
solka (trzeba bylo wyciac odniesienia do SO_DONTLINGER, bo tego nie ma w SYSV).

Pozdrawiam,

-- 
.---.     .   . - Michal Malecki <mmalecki@technologist.com>/The things that
\___  ,-. | , |- ,-. ,-  mUd: zly.mud.org.pl 4000.         /can't destroy you
    \ |-' |<  |  | | |   uRl: www.kis.p.lodz.pl/~sektor   /make you
`---' `-' ' ` `' `-' '   pGp: sektor@zly.kis.p.lodz.pl   /stronger...

On 27 Jan 1998, Michal Malecki wrote:

> Maciej Malinowski <mmalinow@willow.iie.pz.zgora.pl> wrote:
> : W jaki sposob mozna zarezerwowac pamiec pod zmienna o wilkosci ok. 300kB
> : ( a dokladnie 640x480 b) ?
> : Model pamieci Small. Zastosowanie funkcji malloc, farmalloc, new nie
> : daje rezultatow. Zwracaja wartosc null.

Nie doczytalem kompilatora, pewnie nie pomoge autorowi. Ale moze
zainteresuje niektorych, ze jak sie pisze dla 16bitowego DPMI 
(16bitowy tryb chroniony powtarzam) to mozna skorzystac z uslug
DPMI, tam byla taka funkcja - AllocHugeMemBlock czy jakos tak, nie 
pamietam. Napisanie funkcji dostepu do takich blokow bylo bardzo proste -
wystarczylo zwiekszac wartosc segmentu o stala SelectorInc (tak sie
nazywala w BP7.0). I niestraszne 16bitowe rejestry.

-------------------------------------.
Codematic                            |            
 code@beta.cku.pwr.wroc.pl           |
 mmochol@elka.pw.edu.pl              |
http://home.elka.pw.edu.pl/~mmochol  |
-------------------------------------'

Michal Malecki wrote:
[...]
> 
> : Czy nie jest tez tak, ze zgodnie z ANSI ostatnio zmieniono 32kB na 64kB?
> 
> Przepraszam, ale pierwsze slysze, zeby ANSI wtrynial sie do ilosci
> przydzielanej pamieci. [...]

Wiedz, ze siê wtrynia ;))) RTFM - trudno uwierzyc, ale tak jest.
						pozdrawiam
									Mire