> On 04/15/2011 03:00 PM, fir wrote:

> > nigdy sie nad tym nie zastanawialem ale nasuwa mi sie pytanie
> > czy przypadkiem nie lepiej by bylo gdyby tych uchwytow nie bylo
> >
> > to jest oddzielna kwestia ale np co do plikow to mozna powiedziec
> > ze nazwa pliku identyfikuje plik tak ze powstaje pytanie czy zamiast
> > uzywac tych uchwytow
> >
> > h = openFile("yoman.txt");
> > printToFile(h, "jedna rzecz dzis ustalmy");
> > closeFile(h);
> >
> > nie lepiej byloby uzywac nazw
> >
> > openFile("yoman.txt");
> > printToFile("yoman.txt", "jedna rzecz dzis ustalmy");
> > closeFile("yoman.txt");
>
> W tym momencie uchwytem jest nazwa pliku. Jedyne, co "zyskałeś", to
> strata na szybkości, bo tę nazwę trzeba rozwiązywać na obiekt w systemie.
>
> JD

absolutnie nie, nazwa zastepuje uchwyt ale uchwytu nie ma,
- plik i tak ma nazwe, i w podejsciu z uchwytami jest i nazwa
i uchwyt - nowy byt ktory ma typ wartosc i rzadzace nim prawa

podobnie jak z plikami jest jak mysle z resourcami typu "ikona5.ico" albo
"bitmapa3.bmp" - koniecznosc babrania sie z tymi uchwytami to minus
skoro resource'y i tak maja swoje nazwy

to, ze musi zachodzic to tlumaczenie ze stringa na cos liczbopodobnego
to minus - ale to daloby sie jakos zalatwic, [pewnie mozna by informowac
kompilator ze ten (pseudo?) string to identyfikator resourca wiec moze sam
sobie zmapowac - lub w jakis taki sposob] nie znam sie za bardzo na
niskopoziomowym dostepie do resourcow tak ze nie moge powiedziec co
tu mozna i nalezaloby zrobic


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

wywalenie uchwytow upraszczalo by sprawe bo mozna sobie
wyobrazic sytuace gdy resourcow jest duzo jest to duzy zbior
- z uchwytami sa to dwa zbiory 1) zbior resourcow i 2) zbior uchwytow
(przy czym sam zbior uchwytow moze byc schrzaniony - to tak
apropos watku roslinnego)


--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On 04/15/2011 06:05 PM, p...@p...onet.pl wrote:
>> On 04/15/2011 03:00 PM, fir wrote:
>
>>> nigdy sie nad tym nie zastanawialem ale nasuwa mi sie pytanie
>>> czy przypadkiem nie lepiej by bylo gdyby tych uchwytow nie bylo
>>>
>>> to jest oddzielna kwestia ale np co do plikow to mozna powiedziec
>>> ze nazwa pliku identyfikuje plik tak ze powstaje pytanie czy zamiast
>>> uzywac tych uchwytow
>>>
>>> h = openFile("yoman.txt");
>>> printToFile(h, "jedna rzecz dzis ustalmy");
>>> closeFile(h);
>>>
>>> nie lepiej byloby uzywac nazw
>>>
>>> openFile("yoman.txt");
>>> printToFile("yoman.txt", "jedna rzecz dzis ustalmy");
>>> closeFile("yoman.txt");
>>
>> W tym momencie uchwytem jest nazwa pliku. Jedyne, co "zyskałeś", to
>> strata na szybkości, bo tę nazwę trzeba rozwiązywać na obiekt w systemie.
>>
>> JD
>
> absolutnie nie, nazwa zastepuje uchwyt ale uchwytu nie ma,
> - plik i tak ma nazwe, i w podejsciu z uchwytami jest i nazwa
> i uchwyt - nowy byt ktory ma typ wartosc i rzadzace nim prawa

Absolutnie tak, plik ma nazwę, która jest niczym innym jak czytelną dla
człowieka nazwą. Uchwyt do zasobu jest po prostu rozwiązaną nazwą. Zwróć
uwagę, że te Twoje metody należałoby zaimplementować w C mniej więcej tak:

void openFile(char* name)
{
FILE *f = fopen(name, "w"); // załóżmy, że taki tryb
storeInGlobalTable(name, f); // zapisz nazwę zamapowaną na FILE
}

void printToFile(char* name, char* msg)
{
fprintf(getFromGlobalTable(name), "%s", msg);
}

void closeFile(char* name)
{
fclose(getFromGlobalTable(name));
storeInGlobalTable(name, NULL);
}

Cały czas "f", będące niczym innym jak uchwytem, jest potrzebne - tyle,
że zostało zakopane niżej.

JD

PS. Jest jeszcze alternatywna implementacja:

void openFile(char* name) { }
void closeFile(char* name) { }
void printToFile(char* name, char* msg)
{
FILE* f = fopen(name, "w");
fprintf(f, "%s", msg);
fclose(f);
}

do góry

On 04/15/2011 06:10 PM, fir wrote:
> wywalenie uchwytow upraszczalo by sprawe bo mozna sobie
> wyobrazic sytuace gdy resourcow jest duzo jest to duzy zbior
> - z uchwytami sa to dwa zbiory 1) zbior resourcow i 2) zbior uchwytow
> (przy czym sam zbior uchwytow moze byc schrzaniony - to tak
> apropos watku roslinnego)

Powtarzam raz jeszcze - uchwyt daje Ci (tylko?) to, że nazwa nie musi być:

a) za każdym razem rozwiązywana na nowo
b) nie musisz trzymać zasobów niejawnie w jakiejś globalnej tablicy

JD

do góry

On Apr 15, 8:33 am, Maciej Sobczak <s...@g...com> wrote:
> On Apr 15, 9:07 am, Michal Kleczek <k...@g...com> wrote:
>
> > A kto niby nakazal stosowac OO?
>
> Problem z OO bierze się stąd, że niektóre języki *wymuszają* jego
> użycie i nawet rzeczy zupełnie nieobiektowe trzeba tak robić. W takim
> języku biblioteki do czegokolwiek są obiektowe, frameworki do
> czegokolwiek są obiektowe, itd. To promieniuje na boki i oddziałowuje
> na całą resztę, więc potem ludzie usiłują tą logikę (lub jej brak)
> stosować gdzie indziej, nawet jak nie muszą.

Mnie się wydaje, że to, co opisujesz jest dość rzadką sytuacją. Typowo
w projektach, w których główny język jest typowo obiektowo
zorientowany (Java) albo nawet taki, który nie wymusza rozwiązań
obiektowych (C++) do zadań, gdzie obiektowość nie ma zastosowania
stosuje się zwykle inne języki, jak SQL, języki skryptowe czy shella.

do góry

On 04/15/2011 06:20 PM, Jędrzej Dudkiewicz wrote:
> On 04/15/2011 06:10 PM, fir wrote:
>> wywalenie uchwytow upraszczalo by sprawe bo mozna sobie
>> wyobrazic sytuace gdy resourcow jest duzo jest to duzy zbior
>> - z uchwytami sa to dwa zbiory 1) zbior resourcow i 2) zbior uchwytow
>> (przy czym sam zbior uchwytow moze byc schrzaniony - to tak
>> apropos watku roslinnego)
>
> Powtarzam raz jeszcze - uchwyt daje Ci (tylko?) to, że nazwa nie musi być:
>
> a) za każdym razem rozwiązywana na nowo
> b) nie musisz trzymać zasobów niejawnie w jakiejś globalnej tablicy

Tfu, uchwytów, nie zasobów.

JD

do góry

W dniu 2011-04-15 15:30, f...@g...SKASUJ-TO.pl pisze:
>> W dniu 2011-04-15 15:00, fir pisze:
[...]
> w czym problem
>
> openFile("ala.txt");
>
> printToFile("ala.txt", " yo");
>
> renameFile("ala.txt", "linda.txt");
>
> printToFile("linda.txt", " man");
>
> closeFile("linda.txt");

A jak rozwiążesz sytuację, gdzie 2 wątki czytają jednocześnie ten sam
plik po kawałku?

Pozdrawiam

--
gregorius

do góry

> Absolutnie tak, plik ma nazwę, która jest niczym innym jak czytelną dla
> człowieka nazwą. Uchwyt do zasobu jest po prostu rozwiązaną nazwą. Zwróć
> uwagę, że te Twoje metody należałoby zaimplementować w C mniej więcej tak:
>
> void openFile(char* name)
> {
>     FILE *f = fopen(name, "w"); // załóżmy, że taki tryb
>     storeInGlobalTable(name, f); // zapisz nazwę zamapowaną na FILE
> }
>
> void printToFile(char* name, char* msg)
> {
>     fprintf(getFromGlobalTable(name), "%s", msg);
> }
>
> void closeFile(char* name)
> {
>     fclose(getFromGlobalTable(name));
>     storeInGlobalTable(name, NULL);
> }
>
> Cały czas "f", będące niczym innym jak uchwytem, jest potrzebne - tyle,
> że zostało zakopane niżej.


no nie calkiem, i tak nazwa pliku jest 'rozwiazywana' (czy 'mapowana')
na jakis wewnetrzny 'adres' czy cos takiego - przez fopen

to co zwraca fopen (czyli uchwyt) to niekoniecznie jest dokladnie tamten
'sprzetowy adres' - albo ten uchwyt jest czyms, co dopiero zostanie
zmapowane na tamten docelowy adres albo co najwyzej jest to jego 'kopia'

( czyli w jednym wypadku masz identyfikator uchwyt i docelowy adres
albo w drugim tylko identyfikator i docelowy adres)

jak mowie to ze trzeba uzywac stringow jest minusem, ale to mapowanie
'nazwa pliku' na 'docelowy adres'(niestety nie wiem co to jest, adres
na dysku?) i tak raz jest przeprowadzane a pozniej mozna by probowac
je wykorzystac a nie robic za kazdym razem - stringi i tak sa przekazywane
przez adres, trzeba by wiec tylko pozapewniac ze to nie sa odrebne kopie
tylko ten sam wskaznik - albo ew traktowac odrebnie taki string do opisu
resource'a inaczej niz zwykle stringi tyko jako identyfikator resource'a
(chyba lepszy pomysl, wtedy mozna by odroznic od zwyklego stringa np przez
jakies @"nazwa")

openFile(@"ala.txt");
printToFile(@"ala.txt", "yo man");
closeFile(@"ala.txt");

(ew jakos inaczej)

- robi to jak widac pewne drobne roznice ale wynika z tego
ze jest to semantycznie nieco inna rzecz - raczej da sie zrobic; bedzie
chyba nawet drobinke _szybciej_ niz z uchwytami (bo nie ma uchwytow
ktorych obsluga to maly koszt) i nie ma uchwytow - sa tylko identyfikatory





--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry

On Fri, 15 Apr 2011 15:00:42 +0200, fir wrote:

> to jest oddzielna kwestia ale np co do plikow to mozna powiedziec
> ze nazwa pliku identyfikuje plik tak ze powstaje pytanie czy zamiast
> uzywac tych uchwytow
>
> h = openFile("yoman.txt");
>
> printToFile(h, "jedna rzecz dzis ustalmy");
>
> closeFile(h, "yoman.txt");
>
>
> nie lepiej byloby uzywac nazw
>
> openFile("yoman.txt");
>
> printToFile("yoman.txt", "jedna rzecz dzis ustalmy");
>
> closeFile("yoman.txt");

To jest właśnie ten moment, w którym nie dostrzegasz, że cała obsługa
plików w uniksach jest zrobiona na modłę obiektową.

Uchwyt jest tutaj czymś abstrakcyjnym co reprezentuje pewien byt w
systemie, do którego to bytu dostajesz się w sposób taki sam, nie ważne,
jakiego tak naprawdę rodzaju jest to zasób. Dokładnie tak samo używa się
uchwytów do plików na filesystemie jak i do np. socketów i dokładnie tak
samo czyta się z nich dane itd. Inny jest tylko sposób uzyskania tego
uchwytu. Masz tutaj do czynienia z polimorfizmem i enkapsulacją (żeby tylko
wymienić te dwie cechy OOP) w czystej postaci. Tyle że zamiast dysponować
obiektem typu File, dysponujesz jego abstrakcyjnym uchwytem. A dzieje się
tak dlatego, że jest to zaimplementowane w języku, który OOP nie wspiera.

--
Pozdrawiam
Zbyszek Malec

do góry

> > w czym problem
> >
> > openFile("ala.txt");
> >
> > printToFile("ala.txt", " yo");
> >
> > renameFile("ala.txt", "linda.txt");
> >
> > printToFile("linda.txt", " man");
> >
> > closeFile("linda.txt");
>
> A jak rozwiążesz sytuację, gdzie 2 wątki czytają jednocześnie ten sam
> plik po kawałku?
>

a jak to ma wygladac? jest w tym cos szczegolnego - nigdy nie
uzywalem takiego kodu;
w tej wersji z identyfikatorami zamiast uchwytow bedzie to wygladac
tak samo tylko piszesz "identyfikator" zamiast ucHwytu

> Pozdrawiam
>
> gregorius



--
Wysłano z serwisu OnetNiusy: http://niusy.onet.pl

do góry