On 04/15/2011 08:35 PM, p...@p...onet.pl wrote:
>
>> No i właśnie wymyśliłeś uchwyt. To jest taki "wskaźnik", który mapujesz raz
>> przy użyciu open, a potem używasz w innych wywołaniach. U ciebie akurat
>> jest o tyle gorzej, że dochodzi jeszcze jeden, zupełnie zbędny poziom
>> odniesienia.
>
> mowie, jestem zmeczony i mam troche rzeczy do zrobienia totez nie
> moge wdawac sie w jakies dlugie zastanowienia ale zeby zrekapitulowac
>
> nie jest tak jak to niektorzy tu wspomnieli ze jedyne co sie zyskuje
> to wiekszy koszt niz dostep przez uchwyt - bo to co sie przede
> wszystkim zyskuje to * kompletny brak uchwytow *
>
> jesli pominiemy trudnosci ze zwiekszonymi kosztami
> to wartosc tego rozwiazania polega na tym ze nie ma uchwytow (czasem
> setek uchwytow) i koniec podajesz po prostu nazwy zasobow
>
> sprawa zniesienia kosztow to druga sprawa i robi sie troche trudniej
> ale wydaje sie ze koszt jakiegos
>
> printToFile(resource "x.txt", "zzzz");
>
> wobec
>
> printToFile(h, "zzzz");
>
> nie powinien byc wiekszy bo zasadniczo w pierwszym wypadku mozna zrobic
> 'automatycznie' rzecz podobna do tego co robi sie recznie w drugim wypadku
> (czyli rozwiazanie resourca i zapisanie adresu w pamieci)
> - sa pewne subtelnsci i trudnosci do pokonania - w wiekszosci
> wspomniane tj chodzi o to ze wyrazenie resource "x.txt"
> powinno raz rozwiazac resourca a ozostale razy zwrocic adres - chyba
> zeby zrobic z tego wewnetrzny mechanizm i np wyrazenie
> resourceid "a.txt" powinno robic za nowy typ typu resourceid 'rejestrowany'
> przy pierwszym uzyciu - cos w tym stylu

Taaak... Załóżmy, że w dwóch miejscach w programie czytasz ten sam plik.
W przypadku FILE, każdy z nich ma swój bufor, zapamiętaną swoją pozycję
odczytu i różne inne rzeczy. Gdzie w Twojej bez uchwytowej propozycji te
rzeczy są trzymane?

JD