🚀 go-pugleaf

Dnia Thu, 22 Nov 2007 00:38:21 +0100, Marcin ?Qrczak? Kowalczyk skrobie:
> Dnia 21-11-2007, Śr o godzinie 21:19 +0000, Sektor van Skijlen pisze:

> > WSZYSTKIE języki skryptowe mają takie właśnie "wsparcie językowe" do tzw.
> > list, bo jest to w tych językach podstawowy i niemalże jedyny zbiornik.
> > Z drugiej strony, poza językami funkcjonalnymi trudno znaleźć języki ogólnego
> > przeznaczenia z najpopularniejszych, które nie są skryptowe i mają takie listy
> > w języku.

> Które języki *nie mają* składni w formie wyrażenia do tworzenia listy
> lub tablicy o elementach danych podanymi wyrażeniami? Przychodzą mi do
> głowy tylko Pascal, C i C++. Oraz Smalltalk, który ma wygodną składnię
> tylko w przypadku tablicy literałów.

Oraz Java, C# i Fortran. Reszta języków, przy pominięciu skryptowych i
funkcjonalnych, posiada mniej, niż 10% rynku (zaryzykowałbym nawet mniej niż
2%).

> > Co oznacza, że po prostu zebrała się pewna ekipa i połączyła 5 "najlepszych"
> > dialektów Lispa w jedno. I tak powstała kolejna odmiana Lispa. Sam fakt, że
> > zatwierdził to ANSI nie świadczy jeszcze o tym, że nagle wszyscy użytkownicy
> > Lispa nagle przestawili się na "nowy standard".

> Nie nagle, ale rzeczywiście się przestawili. Common Lisp, Scheme i Emacs
> Lisp to są jedyne liczące się bazowe definicje Lispa. Współcześnie
> rozwijane implementacje Lispa bazują na tych standardach, a liczba
> implementacji jest spora. Oczywiście z reguły dodają do bazowego języka
> coś od siebie.

I ile czasu zajęło im to przestawienie się? Dwa lata? Jeśli tak, to może to
oznaczać tylko, że istniejący "code base" był na tyle niewielki. W przypadku
samego C++ czegoś takiego sobie nie wyobrażam, a o Javie to już nie wspomnę.

> > A to w Javie nie przelewki, bo tam znacznie większa ilość błędnych sytuacji
> > jest sygnalizowana wyjątkami, niż w C++. Efekt tego przykładowo jest taki,
> > że jak w C++ mogę sobie zrobić (tak, wiem, że to POSIX, ale chodzi mi o
> > praktykę):
> > 
> > sleep( 10 );
> > 
> > to w Javie trzeba zrobić:
> > 
> > try { Thread.sleep( 10 ); } catch ( InterruptedException e ) {}

> Wcale nie trzeba, jeśli metoda, w której to się znajduje, deklaruje,
> że może rzucać InterruptedException. To, że wyjątek jest checked, nie
> oznacza, że trzeba go od razu łapać (oczywiście może nie być wyjścia,
> jeśli interfejs naszego kontekstu został wcześniej ustalony i nas
> ogranicza).

Qrczak, czemu ty musisz na siłę być takim skończonym teoretykiem!?
I to mówi gościu, który zarabiał jakąkolwiek kasę na pisaniu w Javie?

Jeśli nie przechwycisz w tym miejscu, tak jak napisałem, to musisz wtedy
zadeklarować propagację InterruptedException na całą metodę. To jednak
oznacza, że w takim razie metoda ją wołająca też musi albo wyjątek obsłużyć,
albo zadeklarować propagację (jeśli jest takich kilka, to każda z nich). W
którymś momencie dotrzesz do metody typu MojaKlasa.main, czy jakiejś metody
Springa wołającej twoją metodę i w tym momencie zadeklarować propagacji po
prostu NIE MOŻESZ, bo nikt ci już tego wyjątku wyżej nie obsłuży.

W praktyce to oznacza, że w którymś momencie MUSISZ po prostu najzwyczajniej w
świecie obsłużyć ten wyjątek i nie ma od tego ucieczki. A najlepiej jest ten
wyjątek obsłużyć w momencie do tego najlepszym. Jeśli więc problem zgłoszony
przez InterruptedException nam nie przeszkadza, to powinniśmy go wyłapać jak
najszybciej.

W przypadku sleep akurat powinna istnieć co najwyżej wersja typu "trySleep",
która co najwyżej zwróci ilość czasu rzeczywiście przespanego, tyle że jeśli
funkcji nie przerwano, to zawsze zwróci swój argument. Albo taką wersję, która
sygnalizuje przerwanie przez wartość zwracaną. Jeśli w danym przypadku nie
interesuje mnie, czy sleep czasem nie został przerwany (lub wiem, że nikt go
nie przerwie z jakichś przyczyn - i to jest właśnie jedna z istotniejszych wad
ścisłych wyjątków), to chciałbym o tym nie być informowany. Po co się w takim
przypadku wymusza na mnie zrobienie obsługi tego wyjątku, nawet jeśli ta
obsługa miałaby być psuta?

> Mam rozumieć, że lepiej, kiedy sprzątanie przez wątek po jego przerwaniu

Stop! Nie mówimy tutaj o przerwaniu wyjątku. Mówiłem o zrobieniu sleep. To, że
w Javie funkcja sleep() jest metodą klasy Thread to tylko taka jej specyfika.

> obsługuje się makrami pthread_cleanup_push i pthread_cleanup_pop (którym
> przekazuje się wskaźnik na funkcję z argumentem typu void * i wartość
> tego argumentu), a to, czy przerwanie wątku w ogóle spowoduje wykonanie
> jakichś destruktorów czy funkcji obsługi wyjątku, jest dobrą wolą danej
> kombinacji implementacji C++ i POSIX? :-)

Te makra wynikają tylko i wyłącznie z faktu, że język C nie potrafi w
"normalny sposób" sprzątać po przerwaniu. Dlatego trzeba robić makra z
ukrytymi w środku klamerkami, żeby spowodować błąd w razie czego.

W przypadku C++ trzeba to po prostu robić inaczej. No sory, skoro używamy makr
na obejście braku określonej właściwości, to w języku, któremy tych
właściwości nie brakuje, trzeba to robić inaczej.

Wiem o tym, bo nadziałem się na to ostatnio, jak się okazało, że w C++
pthread_cancel() praktycznie nie da się używać poprawnie.

> Swoją drogą niemal wszystkie języki traktują asynchroniczne sygnały
> i przerywanie wątków po macoszemu. Właściwie jedynym językiem, który
> robi to poprawnie, jest Kogut (według mojego subiektywnego odczucia,
> jak można robić to poprawnie).

Qrczak, jaki masz tutaj asynchroniczny sygnał w przypadku Thread.sleep()? Ten
sygnał jest typowo synchroniczny - w praktyce. Bo jeśli mówimy o normalnym
przerwaniu wykonywania się wątku, to w takim razie powinien on teoretycznie
wystąpić w dowolnym momencie. Nie tylko jak się wykonuje sleep(). A skoro tak,
to nie powinno się go zgłaszać jako jawny wyjątek spod sleep().

> > Natomiast "łatwe języki" zwykle dają złudzenie łatwości tematu w przypadku
> > trudnych zagadnień. Jednym z takich trudnych zagadnień jest wielowątkowość.

> Dawałyby takie złudzenie gdyby ułatwiały projekt, który z pewnych
> subtelnych powodów jest niepoprawny, w porównaniu do poprawnego
> projektu, który miałby trudniej z winy języka. Ale nie przypominam
> sobie takich cech różnych języków, więc nie wiem, co masz na myśli.

Same wątki w Javie już wystarczą. Nadużywa się ich, zamiast zrobić to samo na
włóknach.


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"