🚀 go-pugleaf

Solaris wrote:
> Chyba faktycznie grupa już umarła. Nic nowego. Modlić się, żeby
> przyszły na nią jeszcze jakieś sensowne posty (tylko nie zaliczeniowe
> programy) ;-)

Już za miecha rok akademicki ;-).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Spójrzcie na poniższy programik, potem powiedzcie, co powinno się 
wypisać. A potem uruchomcie to w BP7 i zobaczcie, co się faktycznie 
wypisuje. Uruchomcie w FP i porównajcie.

Gdzie jest błąd?



Type

   PFIrstClass = ^TFIrstClass;
   TFIrstClass = object
                   X: INteger;
                   Constructor init;
                   constructor init2;
                   destructor done;
                   procedure wypiszmnie;virtual;
                 end;

   PSecondClass = ^TSecondClass;
   TSecondClass = object(TFIrstClass)
                   procedure wypiszmnie;virtual;
                  end;


   PThirdCLass = ^TThirdCLass;
   TThirdCLass = object(TSecondClass)
                   Z: integer;
                   Constructor init;
                   procedure wypiszmnie;virtual;
                 end;


Constructor TFIrstClass.init;
begin
   X := 1;
end;

Constructor TFIrstClass.init2;
begin
   Self.init;
end;



destructor TFIrstClass.done;
begin
end;


Constructor TThirdClass.init;
begin
   if not Inherited Init2
   then
     Fail;

   Z := 1;
end;

procedure TFirstClass.wypiszmnie;
begin
   Writeln('Pierwsza');
end;

procedure TSecondClass.wypiszmnie;
begin
   Writeln('Druga');
end;


procedure TThirdClass.wypiszmnie;
begin
   Writeln('Trzecia');
end;


var
   P: PFirstClass;
begin
   P := New(PThirdClass, Init);
   P^.WypiszMnie;
   Dispose(P, Done);
end.

Andrzej Grażyński wrote:
> Constructor TFIrstClass.init2;
> begin
>   Self.init;  end;


Powinno się wypisać trzecia, wypisuje się pierwsza.
Zgaduje, że c-tor TFirstClass.Init nadpisuje VMT z
bliżej mi nieznanego powodu? A trudno znależć
dokument analogiczny do ISO 14882 w kontekście
C++ ale dla Object Pascala, więc trudno mi się
czymś sensownym podeprzeć w tej kwestii =].

P.S. Za cholere nie mogę się doszukać czym jest
         call do Fail, i dlaczego można oczekiwać od
         c-tora zwrócenia bool'a ;). Ale ja jestem "zbyt
        nowe pokolenie" ;).

Przy czym wydaje mi się, że Fail to jakiś odpowiednik
throw/raise żeby wymusić destrukcję obiektu który
"nie umiał się zainicjalizować" ;).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Andrzej Grażyński wrote:
>> Constructor TFIrstClass.init2;
>> begin
>>   Self.init;  end;
> 
> 
> Powinno się wypisać trzecia, wypisuje się pierwsza.
> Zgaduje, że c-tor TFirstClass.Init nadpisuje VMT z
> bliżej mi nieznanego powodu? A trudno znależć
> dokument analogiczny do ISO 14882 w kontekście
> C++ ale dla Object Pascala, więc trudno mi się
> czymś sensownym podeprzeć w tej kwestii =].
> 
> P.S. Za cholere nie mogę się doszukać czym jest
>         call do Fail, i dlaczego można oczekiwać od
>         c-tora zwrócenia bool'a ;). Ale ja jestem "zbyt
>        nowe pokolenie" ;).
> 
> Przy czym wydaje mi się, że Fail to jakiś odpowiednik
> throw/raise żeby wymusić destrukcję obiektu który
> "nie umiał się zainicjalizować" ;).
> 

Przy wywołaniu:  obiekt.konstruktor  lub inherited konstruktor:

Jeżeli w konstruktorze wykona się Fail, to kończy on pracę i zwraca 
FALSE. Jeśli skończy pracę normalnie, zwraca TRUE.

Przy wywołaniu

wskaźnik_obiektu := New(Typ wsk., Konstruktor (...));

jeśli w konstruktorze wykona się Fail, to funkcja New zwróci NIL.







A propos oryginalnej zagadki, błąd kompilatora jest tutaj:



Constructor TFirstClass.init2;
begin
   Self.init;  <---
end;


To wywołanie nie powinno ruszać pola VMT link, a nadpisuje je typem 
TFirstClass.

Andrzej Grażyński wrote:
> Przy wywołaniu:  obiekt.konstruktor  lub inherited konstruktor:
>
> Jeżeli w konstruktorze wykona się Fail, to kończy on pracę i zwraca
> FALSE. Jeśli skończy pracę normalnie, zwraca TRUE.
>
> Przy wywołaniu
>
> wskaźnik_obiektu := New(Typ wsk., Konstruktor (...));
>
> jeśli w konstruktorze wykona się Fail, to funkcja New zwróci NIL.

A myślalem że wiem o Object Pascalu wszystko :).

> A propos oryginalnej zagadki, błąd kompilatora jest tutaj:
>
> Constructor TFirstClass.init2;
> begin
>   Self.init;  <---
> end;
>
>
> To wywołanie nie powinno ruszać pola VMT link, a nadpisuje je typem
> TFirstClass.


Czyli włąściwie zgadłem =].

P.S. Panie Andrzeju, proszę kontynuować z podobnymi zagadkami :).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Andrzej Grażyński wrote:
>> Przy wywołaniu:  obiekt.konstruktor  lub inherited konstruktor:
>>
>> Jeżeli w konstruktorze wykona się Fail, to kończy on pracę i zwraca
>> FALSE. Jeśli skończy pracę normalnie, zwraca TRUE.
>>
>> Przy wywołaniu
>>
>> wskaźnik_obiektu := New(Typ wsk., Konstruktor (...));
>>
>> jeśli w konstruktorze wykona się Fail, to funkcja New zwróci NIL.
> 
> A myślalem że wiem o Object Pascalu wszystko :).
> 
>> A propos oryginalnej zagadki, błąd kompilatora jest tutaj:
>>
>> Constructor TFirstClass.init2;
>> begin
>>   Self.init;  <---
>> end;
>>
>>
>> To wywołanie nie powinno ruszać pola VMT link, a nadpisuje je typem
>> TFirstClass.
> 
> 
> Czyli włąściwie zgadłem =].
> 
> P.S. Panie Andrzeju, proszę kontynuować z podobnymi zagadkami :).
> 

No dobrze:


{ BP 7 }
Function HighOfPackedString(const X:array of char):Word;
begin
   HighOfPackedString := High(X);
end;

Ile to będzie:

HighOfPackedString('A');

HighOfPackedString('');


Oczywiście łatwo to sprawdzić, ale przed uruchomieniem spróbuj 
odpowiedzieć na wyczucie.

Andrzej Grażyński wrote:
> No dobrze:
>
>
> { BP 7 }
> Function HighOfPackedString(const X:array of char):Word;
> begin
>   HighOfPackedString := High(X);
> end;
>
> Ile to będzie:
>
> HighOfPackedString('A');
>
> HighOfPackedString('');
>
>
> Oczywiście łatwo to sprawdzić, ale przed uruchomieniem spróbuj
> odpowiedzieć na wyczucie.


Logicznie, odpowiednio 0 i -1, żeby odpowiednio był "jeden
znak" i "zero znaków". Czy istotne jest BP7? Ponieważ nie
posiadam takowego.

Sprawdzając w fpc - dostaje 0 i 0.. hm, to impikuje, że
pusty string ma tak jakby jeden znak. Mogę się mylić.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Andrzej Grażyński wrote:
>> No dobrze:
>>
>>
>> { BP 7 }
>> Function HighOfPackedString(const X:array of char):Word;
>> begin
>>   HighOfPackedString := High(X);
>> end;
>>
>> Ile to będzie:
>>
>> HighOfPackedString('A');
>>
>> HighOfPackedString('');
>>
>>
>> Oczywiście łatwo to sprawdzić, ale przed uruchomieniem spróbuj
>> odpowiedzieć na wyczucie.
> 
> 
> Logicznie, odpowiednio 0 i -1, żeby odpowiednio był "jeden
> znak" i "zero znaków". Czy istotne jest BP7? Ponieważ nie
> posiadam takowego.
> 
> Sprawdzając w fpc - dostaje 0 i 0.. hm, to impikuje, że
> pusty string ma tak jakby jeden znak. Mogę się mylić.
> 
W BP wartości High i Low nie mogą być ujemne (są typu WORD). Nie ma 
zesztą takiej potrzeby, po nie da się skonstruować pustej 
(zero-elementowej) tablicy. Z tym jednym wyjątkiem (pusty łancuch jako 
substytut array of char). Trudno sobie z tym poradzić w sposób spójny 
(skoro ma nie byc pustych tablic) i dlatego projektanci BP musieli 
zastosować obejście zasad w ten sposób, że pusty łańcuch, zastępujący 
parametr (open) array of char, traktowany jest tak jak jednoznakowy 
łancuch zawierający znak #0. Ta cecha jest udokumentowanaw w "Language 
guide".

A skoro tak było w BP, to dla zachowania kompatybilności przeszło na 
następne wcielenia Pascala.

Solaris pisze:
> Chyba faktycznie grupa już umarła. Nic nowego. Modlić się, żeby przyszły na nią
> jeszcze jakieś sensowne posty (tylko nie zaliczeniowe programy) ;-)
> 
Prowokacyjne pytanie:

Dlaczego typ Comp zaliczony został do zmiennopozycyjnych, skoro 
strukturalnie jest to 64-bitowy signed int?

{ BP 7 }

Rozwiązanie 1:

Procedure MyProc(X:PChar);
begin
   ...
end;



...

MyProc('TAKI SOBIE STRING');


================================


Rozwiązanie 2:

Procedure MyProc(const X:String);
begin
   ...
end;



...

MyProc('TAKI SOBIE STRING');

===========================

Rozwiązanie 1 ma pewną wadę w stosunku do Rozwiązania 2. Jaką ? 
Odpowiedź poniżej (nie każę zgadywać, bo rzecz dość ciekawa).

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

W Rozwiązaniu 1 string 'TAKI SOBIE STRING' trzymany jest w segmencie 
danych, w którym w BP każdy bajt jest na wagę złota (bo jest max 64K na 
całą app).


W Rozwiązaniu 2 string 'TAKI SOBIE STRING' trzymany jest w segmencie 
kodu. Co prawda każdy segment kodu jest też max 64K, ale aplikacja może 
zawierać wiele takich segmentów.


Umieszczanie w segmencie danych stringów zastępujących parametry PChar 
było konieczne dla prawidłowego działania programów z nakładkami. Dla 
kompatybilności jednak jest ono stosowane przez kompilator zarówno w 
nienakładkowanych programach trybu Real, jak i w trybie Protected.

Andrzej Grażyński wrote:

> Solaris pisze:
>> Chyba faktycznie grupa już umarła. Nic nowego. Modlić się, żeby przyszły
>> na nią jeszcze jakieś sensowne posty (tylko nie zaliczeniowe programy)
>> ;-)
>> 
> Prowokacyjne pytanie:
> 
> Dlaczego typ Comp zaliczony został do zmiennopozycyjnych, skoro
> strukturalnie jest to 64-bitowy signed int?

ja nie mam zielonego pojecia, ale jesli miałbym strzelać to obstawiałbym, że
ze względu na jego rozmiar, obliczeń na nim dokonuje koprocesor.

-- 
Michał Walenciak,   gg: 3729519,  poczta: Kicer86@
http://kicer.elsat.net.pl                 gmail.com

Andrzej Grażyński wrote:
> Solaris pisze:
>> Chyba faktycznie grupa już umarła. Nic nowego. Modlić się, żeby
>> przyszły na nią jeszcze jakieś sensowne posty (tylko nie
>> zaliczeniowe programy) ;-)
> Prowokacyjne pytanie:
>
> Dlaczego typ Comp zaliczony został do zmiennopozycyjnych, skoro
> strukturalnie jest to 64-bitowy signed int?


http://xona.com/2006/07/29.html

Akapit:
Why Is comp Considered A Floating Point?

Czyli mówiąc wprost - bo reprezentacja comp jest bardzo
zbliżona do typów zmiennoprzecinkowych, znak, mantysa
i wykładnik ;).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Andrzej Grażyński wrote:
>> Solaris pisze:
>>> Chyba faktycznie grupa już umarła. Nic nowego. Modlić się, żeby
>>> przyszły na nią jeszcze jakieś sensowne posty (tylko nie
>>> zaliczeniowe programy) ;-)
>> Prowokacyjne pytanie:
>>
>> Dlaczego typ Comp zaliczony został do zmiennopozycyjnych, skoro
>> strukturalnie jest to 64-bitowy signed int?
> 
> 
> http://xona.com/2006/07/29.html
> 
> Akapit:
> Why Is comp Considered A Floating Point?
> 
> Czyli mówiąc wprost - bo reprezentacja comp jest bardzo
> zbliżona do typów zmiennoprzecinkowych, znak, mantysa
> i wykładnik ;).
> 

Comp NIE jest złozony ze znaku, mantysy i wykładnika. Jest 64-bitowym 
integerem zapisywanym w uzupełnieniu do 2. W przeciwieństwie do Single, 
Double i Extended, gdzie znak, wykładnik i mantysa są ściśle rozdzielone.

Andrzej Grażyński wrote:
>> Czyli mówiąc wprost - bo reprezentacja comp jest bardzo
>> zbliżona do typów zmiennoprzecinkowych, znak, mantysa
>> i wykładnik ;).
>>
>
> Comp NIE jest złozony ze znaku, mantysy i wykładnika. Jest 64-bitowym
> integerem zapisywanym w uzupełnieniu do 2. W przeciwieństwie do
> Single, Double i Extended, gdzie znak, wykładnik i mantysa są ściśle
> rozdzielone.


Argh, nie doczytałem całości artykułu.

W takim razie przychylam sie do wersji Kicera. Z drugiej strony nie wiem
jak są wykonywane te obliczenia, konwersja na real'a, użycie FPU,
konwersja i obcięcie spowrotem do 64 bitów integerowych ;)?

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Andrzej Grażyński wrote:
>>> Czyli mówiąc wprost - bo reprezentacja comp jest bardzo
>>> zbliżona do typów zmiennoprzecinkowych, znak, mantysa
>>> i wykładnik ;).
>>>
>>
>> Comp NIE jest złozony ze znaku, mantysy i wykładnika. Jest 64-bitowym
>> integerem zapisywanym w uzupełnieniu do 2. W przeciwieństwie do
>> Single, Double i Extended, gdzie znak, wykładnik i mantysa są ściśle
>> rozdzielone.
> 
> 
> Argh, nie doczytałem całości artykułu.
> 
> W takim razie przychylam sie do wersji Kicera. Z drugiej strony nie wiem
> jak są wykonywane te obliczenia, konwersja na real'a, użycie FPU,
> konwersja i obcięcie spowrotem do 64 bitów integerowych ;)?
> 

Obliczenia wykonywane są w stałoprzecinkowej arytmetyce 64-bitowej. 
Oczywiście w rejestrach koprocesora wszystkie dane przechowywane są w 
formacie Extended i konwersja, o której piszesz faktycznie zachodzi, ale 
użytkownik nie musi o tym wiedzieć, bo używa instrukcji 
STAŁOPRZECINKOWYCH. Poniższa funkcja wylicza resztę z dzielenia dwóch 
Comp'ów:

{ BP 7 }
Function CompModulo(C1,C2:Comp):Comp;
var
   C3, C4: Comp;
begin
   asm
     fild C2
     fild C1
     fprem
     fistp C3
     fistp C4
     fwait
   end;
   CompModulo := C3;
end;

Dlaczego obiekty w Pascalu (i klasy w Delphi/FP) nie mogą być 
deklarowane lokalnie w procedurach/funkcjach, a tylko na poziomie 
globalnym? Arbitralna decyzja projektantów czy jakaś rzeczywista bariera?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Podpowiedź: są rzeczywiste bariery, i to co najmniej dwie.

Andrzej Grażyński wrote:
> Dlaczego obiekty w Pascalu (i klasy w Delphi/FP) nie mogą być
> deklarowane lokalnie w procedurach/funkcjach, a tylko na poziomie
> globalnym? Arbitralna decyzja projektantów czy jakaś rzeczywista
> bariera?


Ja, szczerze mówiąc, oczekuję Pana rozwiązania zagadki, bo nie
mogę znależć żadnych potencjalnych barier. Czy to coś
internal'owego?

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Andrzej Grażyński wrote:
>> Dlaczego obiekty w Pascalu (i klasy w Delphi/FP) nie mogą być
>> deklarowane lokalnie w procedurach/funkcjach, a tylko na poziomie
>> globalnym? Arbitralna decyzja projektantów czy jakaś rzeczywista
>> bariera?
> 
> 
> Ja, szczerze mówiąc, oczekuję Pana rozwiązania zagadki, bo nie
> mogę znależć żadnych potencjalnych barier. Czy to coś
> internal'owego?
> 
Podpowiedzi:

1. Co można by powiedzieć o metodach obiektów deklarowanych lokalnie?

2. Co można by powiedzieć o tablicach VMT obiektów deklarowanych lokalnie?

Andrzej Grażyński wrote:
> 1. Co można by powiedzieć o metodach obiektów deklarowanych lokalnie?

Ża są lokalne względem scope'u zmiennych outer metody, i lokalne względem
pól obiektu, czyli tak jakby, podwójnie lokalne(?). Błądzę w ciemnościach
po omacku, żeby nie skłamać.

> 2. Co można by powiedzieć o tablicach VMT obiektów deklarowanych
> lokalnie?


Tutaj podejrzewam jakichś internalowy myk z zajętymi rejestrami
zarezerwowanymi na przekazanie adresu instancji obiektu / VMT
albo coś w ten ton, ale tak samo jak  powyżej, ciemność, szczerze
mówiąc :). Przejrzenie pobieżne asma nic mi nie dało. Przjerzenie
google tez. Zbyt niskopoziomowe problemy to są dla
mnie, chyba... :-/.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Andrzej Grażyński wrote:
>> 1. Co można by powiedzieć o metodach obiektów deklarowanych lokalnie?
> 
> Ża są lokalne względem scope'u zmiennych outer metody, i lokalne względem
> pól obiektu, czyli tak jakby, podwójnie lokalne(?). Błądzę w ciemnościach
> po omacku, żeby nie skłamać.
napisalem o tym, bo osobiście z tą tematyką jestem związany emocjonalnie.



Metody obiektó lokalnych musiałyby byc procedurami/funkcjami 
ZAGNIEŻDZONYMI. Sposób wywoływania takich procedur nie da się pogodzić 
ze sposobem wywoływania metod wirtualnych (rozpatrz przykład, gdy obiekt 
macierzysty jest globalny, a dziedziczący  niego - lokalny i mają metodę 
wirtualną).

Osobiście miałem kiedyś pomysł, jak to rozwiązać, akurat wtedy powstawał 
TP 5.5 i wprowadzano obiekty do Turbo Pascala, a ja byłem w ścisłym 
kontakcie (jako jeden z tysięcy entuzjastów) z autorami. Po długich 
dyskusjach główny Guru Turbo Pascala zdecydował, że będzie za trudne i 
że za mało czasu itd. itp.





> 
>> 2. Co można by powiedzieć o tablicach VMT obiektów deklarowanych
>> lokalnie?
> 
> 
> Tutaj podejrzewam jakichś internalowy myk z zajętymi rejestrami
> zarezerwowanymi na przekazanie adresu instancji obiektu / VMT
> albo coś w ten ton, ale tak samo jak  powyżej, ciemność, szczerze
> mówiąc :). 

Chodzi o to, że zestaw tabel VMT ustalony jest już na etapie kompilacji. 
W BP to jest konieczne, bo VMT są w segmencie DS, a tego nie można 
ruszyć po uruhcomieniu programu, bo jest absolutnie ustalony.

Gdyby można było dynamicznie powoływać unicestwiać deklaracje, trzeba by 
było dynamicznie tworzyć i unicestwiać tablice VMT. Moje opinia z czasów 
tworzenia TP  5.5, że upychanie tablic VMT w segmencie ograniczonym do 
64K jest szalone (jako niezmienne powinny być w statycznym segmencie 
kodu (lub kilku segmentach), tworzonym ad hoc) została zwyczajnie olana. 
Bo gdyby wyszło na moje, pole VMT Link musiałoby mieć 4 bajty, a to 
rzekomo marnotrawstwo.

I jak pojawił się BP 7.0 z trybem protected i pamięci na stercie można 
było wycisnąć co najmniej 32 MB (w XP, w Win98 udało mi się przydzielić 
na raty prawie 512 MB - ok. 8K segmentów po 64K.) to wszystko rozbija 
się o segment DS, który dalej może mieć  tylko 64K i w którym siedzą 
wszystkie VMT. Na szczęście w Delphi tego problemu juz nie ma.













Przejrzenie pobieżne asma nic mi nie dało. Przjerzenie
> google tez. Zbyt niskopoziomowe problemy to są dla
> mnie, chyba... :-/.
> 

Andrzej Grażyński wrote:
> Chodzi o to, że zestaw tabel VMT ustalony jest już na etapie
> kompilacji. W BP to jest konieczne, bo VMT są w segmencie DS, a tego
> nie można ruszyć po uruhcomieniu programu, bo jest absolutnie
> ustalony.


Nie rozumiem powodu dla którego VMT lokalnych typów obiektowych
nie mógłby trafić do globalnego obszaru VMT.. oprócz oczywiście
kwestii zaśmiecania designersko-pierwotnie względnie małego
segmentu DS.

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Andrzej Grażyński wrote:
>> Chodzi o to, że zestaw tabel VMT ustalony jest już na etapie
>> kompilacji. W BP to jest konieczne, bo VMT są w segmencie DS, a tego
>> nie można ruszyć po uruhcomieniu programu, bo jest absolutnie
>> ustalony.
> 
> 
> Nie rozumiem powodu dla którego VMT lokalnych typów obiektowych
> nie mógłby trafić do globalnego obszaru VMT.. oprócz oczywiście
> kwestii zaśmiecania designersko-pierwotnie względnie małego
> segmentu DS.
> 
Teoretycznie masz rację. Ale: 100 lokalnych obiektów, z których w danym 
czasie zdefiniowany będzie tylko 1. 99 tablic VMT bezproduktywnie 
zajmuje miejsce. Choć prawdę mówiąc dziś programista MUSIAŁBY tak zrobić 
deklarując wszystkie obiekty jako globalne.

I do dziś nie rozumiem: skoro tablice VMT są niezmienne, czemu nie 
wepchano ich w kod, jak stringów i setów? Pewnie tylko dlatego, żeby 
można tablicę VMT identyfikować wyłącznie przez offset. Szkoda im było 
tych dwóch bajtów w VMTLink, a Getmem/New/Konstruktor i tak zaokrąglało 
do ośmiu (w BP7 protected do czterech).

Andrzej Grażyński wrote:
>> Nie rozumiem powodu dla którego VMT lokalnych typów obiektowych
>> nie mógłby trafić do globalnego obszaru VMT.. oprócz oczywiście
>> kwestii zaśmiecania designersko-pierwotnie względnie małego
>> segmentu DS.
>>
> Teoretycznie masz rację. Ale: 100 lokalnych obiektów, z których w
> danym czasie zdefiniowany będzie tylko 1. 99 tablic VMT
> bezproduktywnie zajmuje miejsce. Choć prawdę mówiąc dziś programista
> MUSIAŁBY tak zrobić deklarując wszystkie obiekty jako globalne.

To jest nadal, powiedzmy 100 * 10 (powiedzmy średnio tyle entriesów
jest w VMT) * 2 = 2kb - to nie jest jakaś powalająca zajętość
64kb DS'a. [względnie].

Pozatym, jak Pan wspomniał, jeżeli lokalnych obiektów nie można
deklarować, to i tak kończymy na zaśmiecaniu globalnej przestrzeni
VMT deklarując te typy globalnymi.

> I do dziś nie rozumiem: skoro tablice VMT są niezmienne, czemu nie
> wepchano ich w kod, jak stringów i setów? Pewnie tylko dlatego, żeby
> można tablicę VMT identyfikować wyłącznie przez offset. Szkoda im było
> tych dwóch bajtów w VMTLink, a Getmem/New/Konstruktor i tak
> zaokrąglało do ośmiu (w BP7 protected do czterech).


Czyli jak? Zaoszczędzili na dwóch bajtach adresu, biorać sam offset
w DS, dorzucając wyrównanie VMTów do 8b w przestrzeni DS? W
cudzysłowiu marnując te kilka bajtów
 bajtów?
Bzdura ;).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Andrzej Grażyński wrote:
>>> Nie rozumiem powodu dla którego VMT lokalnych typów obiektowych
>>> nie mógłby trafić do globalnego obszaru VMT.. oprócz oczywiście
>>> kwestii zaśmiecania designersko-pierwotnie względnie małego
>>> segmentu DS.
>>>
>> Teoretycznie masz rację. Ale: 100 lokalnych obiektów, z których w
>> danym czasie zdefiniowany będzie tylko 1. 99 tablic VMT
>> bezproduktywnie zajmuje miejsce. Choć prawdę mówiąc dziś programista
>> MUSIAŁBY tak zrobić deklarując wszystkie obiekty jako globalne.
> 
> To jest nadal, powiedzmy 100 * 10 (powiedzmy średnio tyle entriesów
> jest w VMT) * 2 = 2kb - to nie jest jakaś powalająca zajętość
> 64kb DS'a. [względnie].
> 
> Pozatym, jak Pan wspomniał, jeżeli lokalnych obiektów nie można
> deklarować, to i tak kończymy na zaśmiecaniu globalnej przestrzeni
> VMT deklarując te typy globalnymi.
> 
>> I do dziś nie rozumiem: skoro tablice VMT są niezmienne, czemu nie
>> wepchano ich w kod, jak stringów i setów? Pewnie tylko dlatego, żeby
>> można tablicę VMT identyfikować wyłącznie przez offset. Szkoda im było
>> tych dwóch bajtów w VMTLink, a Getmem/New/Konstruktor i tak
>> zaokrąglało do ośmiu (w BP7 protected do czterech).
> 
> 
> Czyli jak? Zaoszczędzili na dwóch bajtach adresu, biorać sam offset
> w DS, dorzucając wyrównanie VMTów do 8b w przestrzeni DS? W
> cudzysłowiu marnując te kilka bajtów
> bajtów?
> Bzdura ;).
> 
Myślenie było takie: dla danej klasy VMT jest jedna, a instancji mogą 
być tysiące. I dlatego trzeba oszczędzać każdy bajt na instancjach. 
Całej pamięci było wtedy raptem 640K.
No ale w powietrzu krążyła już nieoficjalnie specyfikacja DPMI, z 
perspektywą 16MB pamięci fizycznej i 8K*64K = 512MB pamięci (wirtualnej) 
na stercie. I dzisiaj (bo po 15 latach kilka moich systemów Turbo 
Pascalowych ma się bardzo dobrze i są dobudowywane nowe funkcje) mam te 
512M (prawie), ale segment DS jest bliski granicy.

Wtedy nikt nie myslał o DPMI, wtedy trzeba było zrobić nową wersję TP. 
No i były już nakładki (od wersji 5.0, obiekty pojawiły się w 5.5).

No właśnie: czytam sobie plik tekstowy. WYkonałem właśnie kolejny Readln 
i wiersz, który przeczytałem, ma coś ciekawego i chciałbym póżniej do 
niego szybko wrócić. W przypadku plików "File" oraz "File of" robi się 
to oczywiście przez FilePos i Seek. Przydałyby się takie funkcje 
(TextFilePos i TextSeek) dla pliku Text:

var
   F: Text;
   S: String;
   BookmarkPos: Longint;


.....


BookmarkPos := TextFilePos(F);
Readln(F, S);



if not WarteZapamietania(S) then
begin
   BookMarkPos := -1;
end;

....


if BookmarkPos >= 0 then
begin
   TextSeek(F, BoookmarkPos);
   Readln(F, S);  { i mam z powrotem ten sam wiersz }
end;

.......



NO I PYTANIE:

Dlaczego takich funkcji TextSeek i TextFilePos nie ma w standardowej 
bibliotece Turbo Pascala i jak można ten brak uzupełnić w BP7?

Dnia Wed, 24 Sep 2008 08:50:24 +0200, jakże pięknego
Andrzej Grażyński <grazynsk@petex.com.pl> wystukał co zawarte poniżej:

: No właśnie: czytam sobie plik tekstowy. WYkonałem właśnie kolejny Readln 
: i wiersz, który przeczytałem, ma coś ciekawego i chciałbym póżniej do 
: niego szybko wrócić. W przypadku plików "File" oraz "File of" robi się 
: to oczywiście przez FilePos i Seek. Przydałyby się takie funkcje 
: (TextFilePos i TextSeek) dla pliku Text:
...
: 
: NO I PYTANIE:

: Dlaczego takich funkcji TextSeek i TextFilePos nie ma w standardowej 
: bibliotece Turbo Pascala i jak można ten brak uzupełnić w BP7?

Dopisać sobie? ;) A dlaczgo ich nie ma... trzeba zapytać autorów ;)


-- 
Home: admin.idns.pl (fajek.sytes.net)
Linux registered user: 408584
Contact: GG#44450, propionate#wp.pl
19:16:28 -!- Platyna Erroneous Nickname 

Andrzej Grażyński wrote:
> Dlaczego takich funkcji TextSeek i TextFilePos nie ma w standardowej
> bibliotece Turbo Pascala i jak można ten brak uzupełnić w BP7?


Bo Input i Output są Text'ami, i trudno sobie wyobrazić skakanie
po standardowym we/wy.

Teraz sobie nie przypominam detali, ale jakoś się da z tego co
pamiętam dostać do underlying file-handle'a, być może czymś
w stylu absolute. I wtedy Seek/FilePos robią się wykonalne ;).

-- 
Pozdrawiam,
Łukasz 'Maly' Ostrowski.
http://maly.nemo.pl/ 

Łukasz 'Maly' Ostrowski pisze:
> Andrzej Grażyński wrote:
>> Dlaczego takich funkcji TextSeek i TextFilePos nie ma w standardowej
>> bibliotece Turbo Pascala i jak można ten brak uzupełnić w BP7?
> 
> 
> Bo Input i Output są Text'ami, i trudno sobie wyobrazić skakanie
> po standardowym we/wy.
> 
> Teraz sobie nie przypominam detali, ale jakoś się da z tego co
> pamiętam dostać do underlying file-handle'a, być może czymś
> w stylu absolute. I wtedy Seek/FilePos robią się wykonalne ;).
> 

Zapomniałeś jeszcze o wewnętrznym buforowaniu.

Poniższe funkcje sprawdziłem w BP7:


Function TextFilePos ( var F : Text ) : Longint ;
assembler;
Asm
    CMP  InOutRes,0
    JNE  @@Done
    LES  DI,F
    MOV  BX,ES:[DI].TextRec.Handle
    MOV  AX,$4201
    XOR  CX,CX
    XOR  DX,DX
    INT  $21
    JNC  @@OK
    MOV  InOutRes,AX
    SBB  AX,AX
    CWD
    JMP  @@Done
@@OK:
    MOV  BX,ES:[DI].TextRec.BufEnd
    SUB  BX,ES:[DI].TextRec.BufPos
    SUB  AX,BX
    SBB  DX,0
@@Done:
End;

Procedure TextSeek ( Var F : Text ; N : Longint );
Assembler;
Asm
    CMP  InOutRes,0
    JNE  @@Done
    LES  DI,F
    MOV  BX,ES:[DI].TextRec.Handle
    MOV  AX,$4200
    MOV  CX,N.Word[2]
    MOV  DX,N.Word[0]
    INT  $21
    JNC  @@OK
    MOV  InOutRes,AX
@@OK:
    MOV  ES:[DI].TextRec.BufEnd,0
    MOV  ES:[DI].TextRec.BufPos,0
@@Done:
End;

Łatwo sobie z tym problemem poradzić. W klasie, z której dziedziczą 
wszystki klasy programu, należy dopisać konstruktor:


constructor <klasa bazowa>.RecoverType;
begin
   { dokładnie tak, żadnej treści }
end;


A potem, na końcu własnego konstruktora, dopisac po prostu RecoverType:


constructor <klasa pochodna>.<nazwa konstruktora>....
begin

    ....


      tu można dowolnie nawydziwiać z dziedziczonymi konstruktorami itd, 
itp.

    ...

    RecoverType;
end;



Działa bez zarzutu.

BP7.

Oto przykład funkcji zwracającej string:

Function BezSpacji(const S:String):String;
var
   X: String;
   i, K: byte;

begin
   K := 0;
   For i := 1 to Length(S) do
   begin
     if S[i] <> ' ' then
     begin
       Inc(K);
       X[K] := S[i];
     end;
   end;

   Byte(X[0]) := K;

   BezSpacji := X;   { <---- }
end;

albo tak:

Function BezSpacji(S:String):String;
var
   i, K: byte;

begin
   K := 0;
   For i := 1 to Length(S) do
   begin
     if S[i] <> ' ' then
     begin
       Inc(K);
       S[K] := S[i];
     end;
   end;

   Byte(S[0]) := K;

   BezSpacji := S; { <---- }
end;


W obu przypadkach wynik tworzony jest w zmiennej pośredniej, po czym 
zmienna ta kopiowana jest do wyniku.

A czy da się operować BEZPOŚREDNIO NA WYNIKU? - w Delphi służy do tego 
zmienna Result.

Może nie wszyscy wiedzą, że w BP7 zmienna Result też jest, choć może w 
trochę innej formie i trochę inaczej się jej używa:


Function BezSpacji(const S:String):String;
var
   i, K: byte;
   pS: ^String;
begin
   asm
     LES DI,@Result
     MOV pS.WORD[0],DI
     MOV pS.WORD[2],ES
   end;

   { Teraz w pS jest wskazanie na wynik }

   K := 0;
   For i := 1 to Length(S) do
   begin
     if S[i] <> ' ' then
     begin
       Inc(K);
       pS^[K] := S[i];
     end;
   end;

   Byte(pS^[0]) := K;

end;

Oszczędzamy 256 bajtów na stosie i czas kopiowania stringa.

Już było, ale nie szkodzi powtórzyć:

czym się róznią konstrukcje:

var
   i, a, b: integer;

{1}

for i := a to b do
begin
   { jakaś sekwencja }
end;


{2}

i := a;

while i <= b do
begin
   { ta sama sekwencja }
   inc(i);
end;

Dnia 18.10.2008 Andrzej Grażyński <grazynsk@petex.com.pl> napisał/a:
> Już było, ale nie szkodzi powtórzyć:
>
> czym się róznią konstrukcje:
>
> var
>    i, a, b: integer;
>
> {1}
>
> for i := a to b do
> begin
>    { jakaś sekwencja }
> end;
>
>
> {2}
>
> i := a;
>
> while i <= b do
> begin
>    { ta sama sekwencja }
>    inc(i);
> end;

Tym, że w drugim przypadku wpadamy w pętlę nieskończoną dla b = 32767?

-- 
Daniel 'Nathell' Janus, moveat@nathell.korpus.pl, http://korpus.pl/~nathell
Nothing smells more like a slaughterhouse than a graduate seminar.
   -- Leonard Cohen, "The Favourite Game"

Dnia Sat, 18 Oct 2008 12:31:24 +0200, Andrzej Grażyński napisał(a):

> Już było, ale nie szkodzi powtórzyć:
> 
> czym się róznią konstrukcje:
> 
> var
>    i, a, b: integer;
> 
> {1}
> 
> for i := a to b do
> begin
>    { jakaś sekwencja }
> end;
> 
> {2}
> 
> i := a;
> 
> while i <= b do
> begin
>    { ta sama sekwencja }
>    inc(i);
> end;

W normalnych zastosowaniach się nie różnią.
Zresztą nie wiem, czy semantyka fora nie jest
definiowana przez takiego while'a (no może
z dokładnością do środowiska zmiennych).

-- 
ŁK (2008-10-19 17:53:44)

Łukasz Kalbarczyk pisze:
> Dnia Sat, 18 Oct 2008 12:31:24 +0200, Andrzej Grażyński napisał(a):
> 
>> Już było, ale nie szkodzi powtórzyć:
>>
>> czym się róznią konstrukcje:
>>
>> var
>>    i, a, b: integer;
>>
>> {1}
>>
>> for i := a to b do
>> begin
>>    { jakaś sekwencja }
>> end;
>>
>> {2}
>>
>> i := a;
>>
>> while i <= b do
>> begin
>>    { ta sama sekwencja }
>>    inc(i);
>> end;
> 
> W normalnych zastosowaniach się nie różnią.
> Zresztą nie wiem, czy semantyka fora nie jest
> definiowana przez takiego while'a (no może
> z dokładnością do środowiska zmiennych).
> 


Różnią się i to zasadniczo.

W pętli for wartość graniczna wyliczana jest tylko raz. Poniższa pętla 
obróci się tylko 10 razy:

b := 10;

for i := 1 to b do
begin
   Inc(b);
end;

a poniższa obracać się będzie w nieskończoność.

i := 1;
b := 10;

while i <= b do
begin
   inc(i);
   inc(b);
end;


albo to - zobacz, co zostanie wypisane:

i := 10;

for i := i to i+i do
begin
   Writeln(i);
end;


a potem - co zostanie wypisane w poniższym przykładzie:

i := 10;

while i <= i+i do
begin
   writeln(i);
   Inc(i);
end;

Dnia Sun, 19 Oct 2008 20:05:01 +0200, Andrzej Grażyński napisał(a):

> Łukasz Kalbarczyk pisze:
>> Dnia Sat, 18 Oct 2008 12:31:24 +0200, Andrzej Grażyński napisał(a):
>> 
>>> Już było, ale nie szkodzi powtórzyć:
>>>
>>> czym się róznią konstrukcje:
>>>
>>> var
>>>    i, a, b: integer;
>>>
>>> {1}
>>>
>>> for i := a to b do
>>> begin
>>>    { jakaś sekwencja }
>>> end;
>>>
>>> {2}
>>>
>>> i := a;
>>>
>>> while i <= b do
>>> begin
>>>    { ta sama sekwencja }
>>>    inc(i);
>>> end;
>> 
>> W normalnych zastosowaniach się nie różnią.
>> Zresztą nie wiem, czy semantyka fora nie jest
>> definiowana przez takiego while'a (no może
>> z dokładnością do środowiska zmiennych).
>> 
> 
> Różnią się i to zasadniczo.
> 
> W pętli for wartość graniczna wyliczana jest tylko raz. Poniższa pętla 
> obróci się tylko 10 razy:
> 
> b := 10;
> 
> for i := 1 to b do
> begin
>    Inc(b);
> end;
> 
> a poniższa obracać się będzie w nieskończoność.

Serio tak jest w pascalu?

> 
> i := 1;
> b := 10;
> 
> while i <= b do
> begin
>    inc(i);
>    inc(b);
> end;
> 
> albo to - zobacz, co zostanie wypisane:
> 
> i := 10;
> 
> for i := i to i+i do
> begin
>    Writeln(i);
> end;
> 
> a potem - co zostanie wypisane w poniższym przykładzie:
> 
> i := 10;
> 
> while i <= i+i do
> begin
>    writeln(i);
>    Inc(i);
> end;

Gdzie można znaleźć semantykę fora w Pascalu?

-- 
ŁK (2008-10-21 00:41:22)

> Serio tak jest w pascalu?

Weź debugger i przekonaj się


> Gdzie można znaleźć semantykę fora w Pascalu?
Od samego początku, czyli od tzw. Pascala wzorcowego (1971) autorstwa N. 
Wirtha i Miss Jensen, wartości graniczne pętli for wyliczane są 
bezpośrednio przed jej rozpoczęciem. Czyli

i := 10;

for i := i to i+i do ..


jest równoważne

for i := 10 to 20 do ..


Z założenia bowiem w momencie rozpoczęcia pętli for znana jest już 
liczba jej obrotów. Umożliwia to kompilatorom optymalizację, na przykład 
w poniższym przykładzie

M := 2000;

for i := K to L do
begin
   if Odd(M)
   then
     M := 3*M + 1
   else
     M := M div 2;

end;

śledząc wartość zmiennej i możemy jej w ogóle nie zauważyć.

Już było, ale nie zaszkodzi znowu: wytęż wzrok i znajdź szczegół, którym 
różnią się poniższe fragmenty:

(1)

case K of

   1:
      Initialize;

   2:
      Perform;

   3:
      Terminate;

   4:
      if Tracing
      then
        NotifyThreshold
      else
        IgnoreExcess;
end;


(2)

case K of

   1:
      Initialize;

   2:
      Perform;

   3:
      Terminate;

   4:
      if Tracing
      then
        NotifyThreshold;
      else
        IgnoreExcess;
end;


W związku z powyższym, w Turbo Pascalu, wg oryginalnego projektu 
defaultowy wariant CASE miał być oznaczany słowem kluczowym OTHERWISE 
(jak w Pascalu 8000), nie ELSE, ale nie wiedzieć czemu jest jednak ELSE 
(może w haszu zabrakło miejsca na nowe słowo kluczowe? Albo autorzy bali 
się, że zabraknie w przyszłości i nie chcieli mnożyć słów kluczowych?).

Ja, w związku z powyższym, zawsze ujmuję warianty CASE w begin...end.