🚀 go-pugleaf

Dnia Wed, 14 Nov 2007 20:39:59 +0000 (UTC), Wojciech Muła napisał(a):

> Seweryn Habdank-Wojewódzki wrote:
>>> Seweryn Habdank-Wojewódzki wrote:
>>>> Pokaż mi jak pięknie Python obsłuży kodowanie np. maziovii lub UTF-16?
>>> 
>>> Do mazovii trzeba stworzyć po prostu nowy codec, zdaje się
>>> na pl.comp.lang.python ktoś parę miesięcy temu podsyłał.
>>> 
>>> UTF-16 jest wbudowany; wygląda na to, że UTF-7 ani UTF-32 nie.
>>
>> Krótko mówiąc nie wszystko jest gotowe i czasami też coś należy "from
>> scratch".
> 
> Kodowania Mazovia zdechło >10 lat temu, 
Eeeee ciągle mam wdrożenia pod mazowią ...
Jajca jak chciec to wykorzystać ;)

Jacek Czerwinski wrote:
>> Kodowania Mazovia zdechło >10 lat temu, 
> Eeeee ciągle mam wdrożenia pod mazowią ...

A to przepraszam. :)

> Jajca jak chciec to wykorzystać ;)

Przecież to zwykłe kodowanie 8-bitowe, w czym problem?

w.

Dnia Wed, 14 Nov 2007 20:47:40 +0000 (UTC), Wojciech Muła napisał(a):

> Jacek Czerwinski wrote:
>>> Kodowania Mazovia zdechło >10 lat temu, 
>> Eeeee ciągle mam wdrożenia pod mazowią ...
> 
> A to przepraszam. :)
> 
>> Jajca jak chciec to wykorzystać ;)
> 
> Przecież to zwykłe kodowanie 8-bitowe, w czym problem?

Że nic zachodniego tego nie łapie. 
Są polskie konwertery pod Win, ale najczęsciej, o ile w ogóle, konwertuję
sobie w C, mam już gotowe tablice, uruchamiam algorytmem Copy & Pejsta. 
W szczytowym okresie pamiętałem Alt-161 = ó

Wojciech Muła pisze:
> Jacek Czerwinski wrote:
>>> Kodowania Mazovia zdechło >10 lat temu, 
>> Eeeee ciągle mam wdrożenia pod mazowią ...
> 
> A to przepraszam. :)
> 
>> Jajca jak chciec to wykorzystać ;)
> 
> Przecież to zwykłe kodowanie 8-bitowe, w czym problem?
Tiaa.. Kiedyś to się pakowało do terminala eproma z mazowią, albo się w 
tajemniczy sposób zapychało fonty jak się miało wy60, i wszystko 
działało, a jak nie działało, to się babom tłumaczyło, że się nie da. A 
teraz? Trzeba putty'ego, albo inszego reflectiona konfigurować i jeszcze 
marudzą, że im się ramki krzaczą, albo funkcyjne klawisze nie działają. 
Takie czasy... ;)

Witam

Wojciech Muła wrote:

> Kodowania Mazovia zdechło >10 lat temu, a te egoztyczne
> UTF-y --- fakt, byłoby miło, gdyby były.

IMHO nie wszystko jest wstanie Py obsługiwać i bezsensu, aby obsługiwał
*wszystko*, bo to oznaczałoby, że nie ma już pracy dla koderów :-).

Przy czym jeszcze raz podkreślam nie chodzi mi o kodowanie znaków, chodzi mi
o ogólną zależność, że im dalej w las tym więcej drzew -- czyli im bardziej
zaawansowane sprawy należy zakodować to w pewnym momencie każdy język nie
ma gotowców. I wszystko piszę się "from scratch".

Np. dla mnie kluczową sprawą jest obecność algorytmów np. do dataminingu.
C++, Python, C# itd. odpadają na dzień dobry. Java coś tam ma
zaimplementowane, ale projekt jest kiepskawy więc użycie tego jest również
niewygodne.

Dalej pozostają specjalistyczne języki: R, Matlab itd. Ale nawet w tych
zaawansowanych językach, które mają mocną matematykę, piszę i piszę, bo i
tam gotowce się kończą i to dość szybko.

Z kolei R nie ma nic wspólnego z distributed computing. 

Matlab ma "megatoolboxy" do distributed computing, ma algorytmy, ma mnóstwo
ficzerów, ale ma jedną gigant wadę -- trzeba poodpalać serwery Matlaba,
trzeba pospinać to ichnim systemem połączeń, wersja 7.3 to kombinacja
programów w C i w Javie rzęzi to niemiłosiernie! Nie ma ładnych natywnych
połączeń do samego matlaba, nie ma eleganckich utilków wyciągających z
Matlaba tylko tego co potrzeba (szczególnie to leży na Unixach/Linuxie).
Pomijam już fakt, że sam język Matlaba jest kiepski. Rzeczy typowe piszę się
prosto, rzeczy nietypowe pisze się paskudnie.

Czyli tam gdzie jest matematyka nie mam tego co potrzebuję w sensie
informatycznym i wydajnościowym, tam gdzie nie ma matematyki mam ficzery
informatyczne. Tak więc dla mnie pisanie "od zera" przy wykorzystaniu
różniastych bibliotek jest rutyną, bo żaden język nie oferuje pełnego
zestawu tego co potrzebuję.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Seweryn Habdank-Wojewódzki wrote:
>>Seweryn Habdank-Wojewódzki wrote:
>>
>>>Pokaż mi jak pięknie Python obsłuży kodowanie np. maziovii lub UTF-16?
>>
>>Do mazovii trzeba stworzyć po prostu nowy codec, zdaje się
>>na pl.comp.lang.python ktoś parę miesięcy temu podsyłał.
>>
>>UTF-16 jest wbudowany; wygląda na to, że UTF-7 ani UTF-32 nie.
> 
> 
> Krótko mówiąc nie wszystko jest gotowe i czasami też coś należy "from
> scratch".
> 

Tylko że zrobienie tego w Pythonie to duuużo mniej roboty niż chrzanienie 
sie z locales z C++ (które to locales są, że tak powiem, chore).

pzdr
\SK

Witam

Sebastian Kaliszewski wrote:

>> Krótko mówiąc nie wszystko jest gotowe i czasami też coś należy "from
>> scratch".
>> 
> 
> Tylko że zrobienie tego w Pythonie to duuużo mniej roboty niż chrzanienie
> sie z locales z C++ (które to locales są, że tak powiem, chore).

Jeszcze raz napiszę. Mnie locales nie interesuje, to tylko przykład. Mam
rzeczy, które w Pythonie pisze się gorzej niż w C++. Pomijam kwestę
pamięciożerności i paru innych sprawach.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Seweryn Habdank-Wojewódzki wrote:
>>>>>W Pythonie są jedyne słuszne rozwiązania np. jedyna słuszna lista i
>>>>>nie płaczesz?
>>>>
>>>>W Pythonie mam rozwiązania bardziej elastyczne.
>>>
>>>A jaka niby elastyczność jest zaimplementowana w Pythonowej liście?
>>
>>Taka, że możesz ją podstawić czymkolwiek co "kwacze tak jak lista" i
>>będzie dobrze.
> 
> 
> To jest elastyczność algorytmów, tudzież kodu pracującego na liście a NIE
> listy. Sama lista jest zamknięta!

Tzn? Jest po pierwsze bardziej uniwersalna niż lista w C++, jest lepiej 
wpasowana do języka a w razie czego podstawienie zamiast niej czegoś 
własnego nie wpływa mi na miejsca użycia.


>>W Pythonie masz pełno "use any file-like object here and 
>>you'll be fine, use any iterable collection there, etc).
> 
> Tak, wiem, ale to nie są ficzery tych kawałków języka, tylko samego języka,
> generalnie komponenty języka Python nie są
> wytyczalne/kustomizowalne/zmienialne.
> 
> Pokaż mi jak pięknie Python obsłuży kodowanie np. maziovii lub UTF-16?

Już ci napisali. Zrobienei kodeka nie jest strasznie trudne, Zaś UTF-16 już 
jest gotowe. Spróbuj zrobić własne locales w C++, życzę udanej zabawy :)


>>To po całym chrzanieniu się w zrobieniu traitsów, localesów, itd, tego
>>stringa, który niezależnie od platformy trzyma punkty kodowe unicode w
>>jednym znaku, nie użyjesz nigdzie, poza wypisywaniem i czytaneim ze
>>strumieni, gdzie biblioteka standardowa standardowo oczekuje stringa.
> 
> Super masz 100% racji, jeden bidny string po pierwsze nie jest kontenerem
> jako takim.

Ależ jest :)

>>>>Coś mi się zdaje, że zapomniałeś o której stornie pisałeś.
>>>
>>>Cały czas pisze o 47.
>>
>>Ale w tym na co ja odpowiadałem pisałeś o zupełnie inny slajdzie.
>>Straciłeś tracking.
> 
> Nie. Cały czas piszę o tym slajdzie. Tylko raz skomentowałem 3.

Pisałeś o wielu różnych slajdach, nawet podawałeś numerki. To tu nie było w 
żadnym razie przy numerku 47.


>>>>Włąmy to są przede wszystkim na domowe pecety, chodzące pod kontrolą
>>>>softu pewnego dużego producenta pisanego głównie w C i C++.
>>>
>>>Rozumiem że mówisz o UNIX np: Linux, Solaris, AIX czy HP-UX prawda? ;-)
>>
>>Źle rozumiesz ;)
> 
> To znaczy, że dobrze rozumiem, że to nie jest wina C++, tylko prywatnych
> spraw firmy o której myślimy i która większość softu na skrobnięte w C :-D.

To jest skutek użycia języka który nie pomaga w bezpieczym pisaniu.


>>>No więc w C++ będziesz miał smart_ptr, na razie są one w boost (i nie
>>>tylko np. g++ ma już w sobie mocną wersję tr1).
>>
>>Tyle że wbrew zasadzie you don't pay for what you don't use, w każdym
>>użyciu zapłacę za sychronizację wątkową choć 95% wskazywanych obiektów
>>nigdy pomiędzy wątkami nie będzie przekazywane.
> 
> Jak masz taki projekt to tak.

To jest sytuacja jak najbardziej typowa.

>>>Tego nie potrafię ocenić z punktu widzenia języka, który powstał w
>>>latach '80, wtedy języki w ogóle oferowały mnóstwo ficzerów, w
>>>szczególności Python miał stabilną wersję i C++ miał dobry wzorzec
>>>do "skopiowania".
>>
>>Akurat dynamicznych rozwiązań wtedy było duuużo -- wszelkie Lispy i
>>Smalltalki były u szczytu.
> 
> Smalltalk może był u szczytu i może napisano w nim tak wiele softu, że teraz
> uginamy się pod dziedzictwem tego języka -- w szczególności projektanci
> Javy to smaltalkowcy, którzy nie poprawili umierającego języka tylko
> zrobili lepsze C++ -- takie ono jest lepsze, że sam mówisz o nim źle.
> 
> A Lisp, no po prostu gigant softu król wyznaczający szosy dla maluczkich.
> Jak widać mamy w tym języku popisane systemy operacyjne, aplikacje
> multimedialne, GUI, łepsajty, aplikacje bankowe, gry, ... itd.

O maszynach lispowych słyszał? Gdy wszyscy babrali się w command-line to te 
cusie miały pełnoekranowy interfejs i bajery które reszta świata odkryła 10 
lat później.

> Słowem Gigant.

No właśnie tak!


>>>>2. Jeśli weźmiesz mechanizmy dynamiczne, to tu masz kolejne, poważne
>>>>spowolnienie, w dodatku algorytm zmniejszania rozmiaru jest arbitralny
>>>
>>>A tablice to sobie możesz zmniejsza?
>>
>>Tablica jest lżejsza. Natomiast w wektorze zmiany rozmiarów są arbitralne.
>>Przy dużych danych są też parszywie powoooolne (co powiesz na zamieranie
>>programu na kilka senund sic(!) -- zupełnie jak wczesne GC z Javy 1.0) --
>>i szybkie nie będą, ale przydałąby się możliwość trochę lepszego
>>sterowania niż .reserve().
> 
> 
> Mnie to wystarczy. Tak jak Piotr przewiduję liczbę elementów osadzanych w
> kontenerze i o stosowną liczbę go powiększam. Lepszym rozwiązaniem jest
> napisanie alokatora, ale tylko raz tak poważnie podszedłem do zadania więc
> nie mam wielkiego doświadczenia w pisaniu alokatorów.

Jak potrzebowałem pożądnego rozwiązania to zrobiłe sobie sam. Mam stukturę o 
niewiadomej wielkości (a skąd mam wiedzieć ile obiektów zaraz zamierza 
utworzyć program korzystający ze Śmieciucha) która często gwałtownie rośnie. 
Wbudowany vector nie ma regulkacji tempa wzrostu a kurczenie jest w ogóle 
arbitrane (i zwykle po prostu nie występuje) -- zrobiłem sobie swój.


>>>>(a co jest dobre do wszystkiego nie jest dobre w niczym).
>>>
>>>Rozumiem, że mówisz o liście w Pythonie.
>>
>>W Pythnie zwykle nie wymagam skrajnej wydajności. Na użycie C++ musi być
>>jakieś uzasadnienie.
> 
> 
> O widzisz i tu sam się ugryzłeś w ogon :-D. Ten język jest niebezpieczny, bo
> nie traci czasu na zabezpieczenia niebezpiecznych rzeczy.

Traci czas na duperele, takie jak synchronizacja shared_ptr której nie użyję 
w 95% wypadków.

> Jeśli chcesz je
> zabezpieczyć robisz to sam i według swojego uznania eliminujesz
> niebezpieczeństwa i używasz sposobów adekwatnych do sytuacji. 
> Np. po co w aplikacji jednowątkowej mieć synchronizację wątków? 
> Albo mając aplikację wielowątkową widząc gdzie się one spotykają
> synchronizujesz dokładnie to co jest wspólne i w sposób najbardziej
> odpowiedni.


Nie mam takiej możlwości ani w przypadku wbudowanego new i delete ani w 
przypadku shared_ptr, itd...

>>>Nie. Przykładzik pokazuje kod, którego nigdy żaden n00by nie napisze.
>>>To są hakerskie triki. Jeszcze raz podkreślam przykład na stronie 47 jest
>>>extra dziwny. Żaden n00by w C++ tak kodu nie napisze -- pomijam n00by C
>>>piszący w C++.
>>
>>Problemem nie są nooby robiące program na zaliczenie. Ale ludzie
>>doświadczeni, którzy dostali nowe wyzwanie -- nauczenie się C++.
> 
> Doświadczeni, czy Legacy people(tm)? Jak mnie nauka Haskella idzie opornie,
> to nie narzekam, że język jest do bani.

Haskell jest bardzo dobrze przemyślany, ale wymaga zupełnie innego 
"mind-set" niż języki imperatywne. C++ jest po prostu nieprzemyślany.


>>>>A od kiedy uważam J za dobry język? Toż to przerośnięte, ciężkie krówsko,
>>>>typowy overdesign.
>>>
>>>Ach! Dawno nie słyszałem takiego określenia. Poproszę jeszcze o jakiś
>>>przymiot na C# i może jakiś na Haskella.
>>
>>C# to krówsko nieco w stosunku do J poprawione, ale zato nie dające
>>wygonić się poza oborę MS.
>>
>>A Hakell? Tego, że tak powiem, słabo znam. Może: "Napisany przez
>>zboczeńców dla zboczeńców" ;)
> 
> Uh! Toś przywalił.

:)

>>Mam tu na myśli pozytywne znaczenie, nacechowane podziwem. Tak jak
>>podziwiam gości którzy myślą drzewkami i dla nich lispowe S-expressions są
>>de best. 
> 
> Szkoda, że tak nie piszesz o Spiricie i MPL.

Bo Haskell jest użyteczny, tylko wymaga od użytkownia określonego 
"zboczenia". A te dwa to jest jak Perl Golf i IOCCC.

>>>>>No to mnie pouczyłeś. Np. takie numpy jest napisane oczywiście w
>>>>>Pythonie ;-).
>>>>
>>>>Chodzi o to, że Python nie cierpi tak jak C++ z powodu śmieci z C.
>>>
>>>Cierpi, czy nie cierpi to jest kwestia tego jak elegancko śmieci są
>>>upchane pod dywan.
>>
>>Raczej czy mamy klapę od silnika, aby było ciszej i jak olej pocieknie to
>>żeby został pod klapą.
> 
> 
> Widzisz mnie to nie rajcuje, że jak olej cieknie to zostaje pod klapą.

Wolisz go mieć na sobie?

> Dla
> mnie pod klapą ma być równie czyściutko jak na klapie. W szczególności, że
> jak tak każdy zacznie olewać kiedy mu cieknie, byle nie na szybę, to
> będziemy jeździć na drogach posmarowanych olejem, a od tego do wypadków na
> szeroką skalę jest tylko krok.

W silniku nie jest czysto. Jak ktoś zgubi olej to niedojedzie. Ale lepiej 
żeby od razu nie został nim oblany. A jak się chłodnica zwali to ma nie 
oblać kierowcy wrzątkeim.
C++ to taki samochód, co przy pierwszej drobnej awarii traci hamulce, 
kierownica się blokuje a na kierowcę leci gorący olej i borygo.


pzdr
\SK

Witam

Sebastian Kaliszewski wrote:

> Seweryn Habdank-Wojewódzki wrote:
>>>>>>W Pythonie są jedyne słuszne rozwiązania np. jedyna słuszna lista i
>>>>>>nie płaczesz?
>>>>>
>>>>>W Pythonie mam rozwiązania bardziej elastyczne.
>>>>
>>>>A jaka niby elastyczność jest zaimplementowana w Pythonowej liście?
>>>
>>>Taka, że możesz ją podstawić czymkolwiek co "kwacze tak jak lista" i
>>>będzie dobrze.
>> 
>> 
>> To jest elastyczność algorytmów, tudzież kodu pracującego na liście a NIE
>> listy. Sama lista jest zamknięta!
> 
> Tzn? Jest po pierwsze bardziej uniwersalna niż lista w C++

Tak.

> , jest lepiej 
> wpasowana do języka

Nie wydaje mi się, że lepiej.

> a w razie czego podstawienie zamiast niej czegoś 
> własnego nie wpływa mi na miejsca użycia.

A niby z czym w C++ masz problemy?

>>>>>Włąmy to są przede wszystkim na domowe pecety, chodzące pod kontrolą
>>>>>softu pewnego dużego producenta pisanego głównie w C i C++.
>>>>
>>>>Rozumiem że mówisz o UNIX np: Linux, Solaris, AIX czy HP-UX prawda? ;-)
>>>
>>>Źle rozumiesz ;)
>> 
>> To znaczy, że dobrze rozumiem, że to nie jest wina C++, tylko prywatnych
>> spraw firmy o której myślimy i która większość softu na skrobnięte w C
>> :-D.
> 
> To jest skutek użycia języka który nie pomaga w bezpieczym pisaniu.

Chrzanienie -- mieszanie paskudnych zwyczajów C z językiem C++. Porównaj
sobie chociażby projekt MFC i GTKMM.

Jak chcesz podawać takie przykładziki, to wejdź sobie na Active... i tam w
sekcji recips dla Pythona poszukaj sobie przykładzików. Cała ich masa jest
tak napisana, jakby ludzie pisali w BASIC dla ZX. Projektu zero. Obsługa
błędów o ile zrobiona, to na poziomie "if :".
Wieź mi tu nie zalatuj przykładami kodu powstałymi w czasie kiedy Python był
co najwyżej w umyśle GvR. A GvR i wielu innych nauczyli się na tych
programach. Sam zresztą dobrze wiesz, że tego dziurawego systemu nikt nigdy
nie przepisze od zera. Poczekam co bedą ludzie mówili o programach w
Pythonie które będą równie stare jak ten system, bo na razie to mądrale
gadają i gadają, a wielkich projektów w Pythonie jest mało.

To co już obserwuję, to kaskada zależności pomiędzy wersjami i to dotczy
kodu w górę jak i w dół.
 
>>>>No więc w C++ będziesz miał smart_ptr, na razie są one w boost (i nie
>>>>tylko np. g++ ma już w sobie mocną wersję tr1).
>>>
>>>Tyle że wbrew zasadzie you don't pay for what you don't use, w każdym
>>>użyciu zapłacę za sychronizację wątkową choć 95% wskazywanych obiektów
>>>nigdy pomiędzy wątkami nie będzie przekazywane.
>> 
>> Jak masz taki projekt to tak.
> 
> To jest sytuacja jak najbardziej typowa.

Nie wiedzę o czym mówisz. W kodzie shared_ptr z boosta nie widzę żadnej
synchronizacji, więc nie wiem o czym mówisz.

>>>>Tego nie potrafię ocenić z punktu widzenia języka, który powstał w
>>>>latach '80, wtedy języki w ogóle oferowały mnóstwo ficzerów, w
>>>>szczególności Python miał stabilną wersję i C++ miał dobry wzorzec
>>>>do "skopiowania".
>>>
>>>Akurat dynamicznych rozwiązań wtedy było duuużo -- wszelkie Lispy i
>>>Smalltalki były u szczytu.
>> 
>> Smalltalk może był u szczytu i może napisano w nim tak wiele softu, że
>> teraz uginamy się pod dziedzictwem tego języka -- w szczególności
>> projektanci Javy to smaltalkowcy, którzy nie poprawili umierającego
>> języka tylko zrobili lepsze C++ -- takie ono jest lepsze, że sam mówisz o
>> nim źle.
>> 
>> A Lisp, no po prostu gigant softu król wyznaczający szosy dla maluczkich.
>> Jak widać mamy w tym języku popisane systemy operacyjne, aplikacje
>> multimedialne, GUI, łepsajty, aplikacje bankowe, gry, ... itd.
> 
> O maszynach lispowych słyszał?

Nie.

> Gdy wszyscy babrali się w command-line to 
> te cusie miały pełnoekranowy interfejs i bajery które reszta świata
> odkryła 10 lat później.

Dziś wiele rzeczy, które są od lat w Adzie ludzie odkrywają. To samo dotyczy
C++. Szablony były dawno, a niektórzy jej odkrywają dziś.
 
>> Słowem Gigant.
> 
> No właśnie tak!

Powiedz mi dlaczego Lispa określasz mianem giganta, a C++. Przecież lispa ma
więcej odmian niż jest różnych implementacji kompilatorów C++. Przenośność
kodu jest na poziomie 0. A jednak Ty go wychwalasz. Jakaś sprzeczność.

>>>>>2. Jeśli weźmiesz mechanizmy dynamiczne, to tu masz kolejne, poważne
>>>>>spowolnienie, w dodatku algorytm zmniejszania rozmiaru jest arbitralny
>>>>
>>>>A tablice to sobie możesz zmniejsza?
>>>
>>>Tablica jest lżejsza. Natomiast w wektorze zmiany rozmiarów są
>>>arbitralne. Przy dużych danych są też parszywie powoooolne (co powiesz na
>>>zamieranie programu na kilka senund sic(!) -- zupełnie jak wczesne GC z
>>>Javy 1.0) -- i szybkie nie będą, ale przydałąby się możliwość trochę
>>>lepszego sterowania niż .reserve().
>> 
>> 
>> Mnie to wystarczy. Tak jak Piotr przewiduję liczbę elementów osadzanych w
>> kontenerze i o stosowną liczbę go powiększam. Lepszym rozwiązaniem jest
>> napisanie alokatora, ale tylko raz tak poważnie podszedłem do zadania
>> więc nie mam wielkiego doświadczenia w pisaniu alokatorów.
> 
> Jak potrzebowałem pożądnego rozwiązania to zrobiłe sobie sam. Mam stukturę
> o niewiadomej wielkości (a skąd mam wiedzieć ile obiektów zaraz zamierza
> utworzyć program korzystający ze Śmieciucha) która często gwałtownie
> rośnie. Wbudowany vector nie ma regulkacji tempa wzrostu a kurczenie jest
> w ogóle arbitrane (i zwykle po prostu nie występuje) -- zrobiłem sobie
> swój.

O jak mi przykro, że mogłeś się wykazać. A w Pythonie to takie predykcje są
robione w liście i w GC. I tak wolę C++ rozwiązania, bo są bardziej
dedykowane -- w zakresie swojego użycia są szybsze i mniej zajmują ramu.
 
>> O widzisz i tu sam się ugryzłeś w ogon :-D. Ten język jest niebezpieczny,
>> bo nie traci czasu na zabezpieczenia niebezpiecznych rzeczy.
> 
> Traci czas na duperele, takie jak synchronizacja shared_ptr której nie
> użyję w 95% wypadków.

Tak. Wiem. A synchronizacje w Pythonie nie istnieją -- podobno to jest
bezpieczny język? A w ogóle pokaż mi te synchronizacje w kodzie
boost::shared_ptr.
 
>> Np. po co w aplikacji jednowątkowej mieć synchronizację wątków?
>> Albo mając aplikację wielowątkową widząc gdzie się one spotykają
>> synchronizujesz dokładnie to co jest wspólne i w sposób najbardziej
>> odpowiedni.
> 
> Nie mam takiej możlwości ani w przypadku wbudowanego new i delete ani w
> przypadku shared_ptr, itd...

Pokaż mi odpowiedniki w Pythonie.
 
>>>>Nie. Przykładzik pokazuje kod, którego nigdy żaden n00by nie napisze.
>>>>To są hakerskie triki. Jeszcze raz podkreślam przykład na stronie 47
>>>>jest extra dziwny. Żaden n00by w C++ tak kodu nie napisze -- pomijam
>>>>n00by C piszący w C++.
>>>
>>>Problemem nie są nooby robiące program na zaliczenie. Ale ludzie
>>>doświadczeni, którzy dostali nowe wyzwanie -- nauczenie się C++.
>> 
>> Doświadczeni, czy Legacy people(tm)? Jak mnie nauka Haskella idzie
>> opornie, to nie narzekam, że język jest do bani.
> 
> Haskell jest bardzo dobrze przemyślany, ale wymaga zupełnie innego
> "mind-set" niż języki imperatywne. C++ jest po prostu nieprzemyślany.

A może jest tak, że rzeczy proste robi się w nim w dziwny sposób, a rzeczy
dziwne w prosty sposób. Jakoś nie widzę różnicy pomiędzy komplikacją
szablonów i Haskella.
 
>>>>Cierpi, czy nie cierpi to jest kwestia tego jak elegancko śmieci są
>>>>upchane pod dywan.
>>>
>>>Raczej czy mamy klapę od silnika, aby było ciszej i jak olej pocieknie to
>>>żeby został pod klapą.
>> 
>> 
>> Widzisz mnie to nie rajcuje, że jak olej cieknie to zostaje pod klapą.
> 
> Wolisz go mieć na sobie?

Dla mnie awaria to awaria. Czy na sobie to jest inna sprawa. Ale wolę
widzieć jak cieknie.
 
>> Dla
>> mnie pod klapą ma być równie czyściutko jak na klapie. W szczególności,
>> że jak tak każdy zacznie olewać kiedy mu cieknie, byle nie na szybę, to
>> będziemy jeździć na drogach posmarowanych olejem, a od tego do wypadków
>> na szeroką skalę jest tylko krok.
> 
> W silniku nie jest czysto.
> Jak ktoś zgubi olej to niedojedzie. Ale lepiej 
> żeby od razu nie został nim oblany.

Widzisz dla mnie lepiej jak zostanie oblany. Serwery mają działać długo. Jak
coś źle działa to nie zawsze tanie rozwiązanie polega ma resecie. Jak jest
jakiś bug gdzieś w aplikacyjne dla Xińskiego to sobie on może ją resetować.
Ja wolę takiego scenariusza nie rozważać. Wolę kiedy moja aplikacja u mnie
w sytuacji złego działania będzie oblewać mnie wrzącym olejem niż, żeby
serwer potem dziwnie działał. Rozumiem, że dziś miarą jakości jest marka
dyskontu spożywczego. Dawniej jak ktoś przychodził do Ciebie z reklamacją,
to jako sprzedawca (lub producent) paliłeś się ze wstydu, że zrobiłeś
badziewie.

> A jak się chłodnica zwali to ma nie 
> oblać kierowcy wrzątkeim.

To nie jest kwestia chłodnicy. To jest kwestia innych rzeczy.

> C++ to taki samochód, co przy pierwszej drobnej awarii traci hamulce,
> kierownica się blokuje a na kierowcę leci gorący olej i borygo.

Tak. To bardzo dobry język, bo low-quality koderzy dostają ciężkie baty.
Rozumiem, że dziś jest potrzeba zawodówek informatycznych -- chłopaki po SP.
nr 1023 z Pustkowia piszą łepsajty. Super nie zamierzam im zabierać chleba.
Są języki trudne i do nich trzeba podchodzić inaczej.

Zresztą Ty Sebastian nie doceniasz tego ile dało Ci C++ nawet jeśli
poparzyłeś się olejem nie raz i nie dwa razy. Pokaż mi rodowitego Py
kodera, który napisał swoje GC. 
Już Ci mówiłem jeśli za kodera jest za wiele napisane, to on potem sam nie
potrafi być twórczy. 

Np. systemy rozproszone najlepiej programują/projektują Ci co poczuli gorzki
smak C, C++ i innych języków brzydkich. Gawiedź pisząca w PHP, zazwyczaj
nie ma pojęcia o podstawowych kłopotach zarówno związanych z PHP jak i z
systemami rozproszonymi. To jest tylko przykład, ale w każdym
profesjonalnym fragmencie informatyki są takie zadania gdzie trzeba mieć
dużą wiedzę i należy posługiwać się technikami w sposób trikowy. 
Np. korzystanie z wszelakich frameworków jest zawsze nie intuicyjne i
trikowe. Nawet jeśli to jest proste (patrz tutek do Plone nie wspomnę o
EJB, który jest jak ASM w swiecie łepsajtów). Nie widzę osobiście żadnej
różnicy, trzeba się uczyć i nieustannie podnosić kwalifikacje i tyle. Jak
nie to w każdym języku szybko człowiek dołączy do Legacy People (tm).

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia 20.11.2007 Seweryn Habdank-Wojewódzki <shw_mail@wp.pl> napisał/a:

> Powiedz mi dlaczego Lispa określasz mianem giganta, a C++. Przecież lispa ma
> więcej odmian niż jest różnych implementacji kompilatorów C++. 

Tak, ale żywe są dwie odmiany (no, nie licząc emacs lisp).  Obie
ustandaryzowane, jedna nawet przez ANSI. Reszta odmian to historia.

> Przenośność kodu jest na poziomie 0. 

Nieprawda.

-- 
Daniel 'Nathell' Janus, GG #1631668, przesunmalpe@nathell.korpus.pl
   create_initial_thread(initial_function);
   lose("CATS.  CATS ARE NICE.\n");
      -- Steel Bank Common Lisp, sbcl/runtime/runtime.c:425

Witam

Daniel Janus wrote:

>> Powiedz mi dlaczego Lispa określasz mianem giganta, a C++. Przecież lispa
>> ma więcej odmian niż jest różnych implementacji kompilatorów C++.
> 
> Tak, ale żywe są dwie odmiany (no, nie licząc emacs lisp).  Obie
> ustandaryzowane, jedna nawet przez ANSI. Reszta odmian to historia.
> 
>> Przenośność kodu jest na poziomie 0.
> 
> Nieprawda.

Może i nieprawda, a może i prawda.

Ile razy brałem jakiś kurs dot. Lispa, zawsze coś nie działało. Jak dotarłem
do tego o co autorom chodzi (o którego Lispa), to inny kurs już miał co
innego na myśli (inny Lisp był omawiany). Książki dot. Lispa też tak miały.

Może teraz po kilku latach coś się zmieniło.

Pozdrawiam.

Ps. Podziwiam ekipę, która napisała Abuse.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia 20.11.2007 Seweryn Habdank-Wojewódzki <shw_mail@wp.pl> napisał/a:

>>> Przenośność kodu jest na poziomie 0.
>> 
>> Nieprawda.
>
> Może i nieprawda, a może i prawda.
>
> Ile razy brałem jakiś kurs dot. Lispa, zawsze coś nie działało. Jak dotarłem
> do tego o co autorom chodzi (o którego Lispa), to inny kurs już miał co
> innego na myśli (inny Lisp był omawiany). Książki dot. Lispa też tak miały.

Znaczy kursy/książki były do d.  Btw jakie książki dokładnie?

Polecam http://gigamonkeys.com/book/ :)

-- 
Daniel 'Nathell' Janus, GG #1631668, przesunmalpe@nathell.korpus.pl
   create_initial_thread(initial_function);
   lose("CATS.  CATS ARE NICE.\n");
      -- Steel Bank Common Lisp, sbcl/runtime/runtime.c:425

Witam

Daniel Janus wrote:

>> Ile razy brałem jakiś kurs dot. Lispa, zawsze coś nie działało. Jak
>> dotarłem do tego o co autorom chodzi (o którego Lispa), to inny kurs już
>> miał co innego na myśli (inny Lisp był omawiany). Książki dot. Lispa też
>> tak miały.
> 
> Znaczy kursy/książki były do d.  Btw jakie książki dokładnie?

Nie pamiętam kursów, bo naprawdę były lipiane, a książki to miałem w ręku
jakieś tłumaczenia na Polski wydane przez (chyba) WNT.
Tłumaczenie było dobre, tylko treść jakaś niezbyt to znaczy, aby oddać
cesarzowi co cesaskie, książki opisywały programowanie w jakimś "narzeczu"
lispa, i wobrębie tego narzecza były napisane dobrze, tylko samemu nie
potrafiłem nic napisać, bo nie wiadomo o co chodziło, potem kiedy dotarłem
do tego, które to było narzecze, okazało się, że ono jest nie kompatybilne
z innymi. I odtąd miałem paskudne wrażenienie i nie wracałem do tematu.
 
> Polecam http://gigamonkeys.com/book/ :)

Dzięki. Jeśli to jest dobre to przeczytam.

Pozdrawiam. 

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Seweryn Habdank-Wojewódzki wrote:
[ o listach]
>>, jest lepiej 
>>wpasowana do języka
> 
> Nie wydaje mi się, że lepiej.

LOL, W pythonie lista ma reprezentację w samej składni.

>>a w razie czego podstawienie zamiast niej czegoś 
>>własnego nie wpływa mi na miejsca użycia.
> 
> A niby z czym w C++ masz problemy?

W C++ niby uniwersalne kontenery uniwersalne nie są, w miarę uniwersalność 
kończy się na vector i deque oraz map i multimap.


>>>>>>Włąmy to są przede wszystkim na domowe pecety, chodzące pod kontrolą
>>>>>>softu pewnego dużego producenta pisanego głównie w C i C++.
>>>>>
>>>>>Rozumiem że mówisz o UNIX np: Linux, Solaris, AIX czy HP-UX prawda? ;-)
>>>>
>>>>Źle rozumiesz ;)
>>>
>>>To znaczy, że dobrze rozumiem, że to nie jest wina C++, tylko prywatnych
>>>spraw firmy o której myślimy i która większość softu na skrobnięte w C
>>>:-D.
>>
>>To jest skutek użycia języka który nie pomaga w bezpieczym pisaniu.
> 
> Chrzanienie -- mieszanie paskudnych zwyczajów C z językiem C++. Porównaj
> sobie chociażby projekt MFC i GTKMM.

[...]
> Wieź mi tu nie zalatuj przykładami kodu powstałymi w czasie kiedy Python był
> co najwyżej w umyśle GvR.

Języki bezpieczne znane są od ponad 45 lat. Języki w których nie ma 
podstawoych dziur w systemie typów były popularne już blisko 40 lat temu sic(!).

[...]
>>>>>No więc w C++ będziesz miał smart_ptr, na razie są one w boost (i nie
>>>>>tylko np. g++ ma już w sobie mocną wersję tr1).
>>>>
>>>>Tyle że wbrew zasadzie you don't pay for what you don't use, w każdym
>>>>użyciu zapłacę za sychronizację wątkową choć 95% wskazywanych obiektów
>>>>nigdy pomiędzy wątkami nie będzie przekazywane.
>>>
>>>Jak masz taki projekt to tak.
>>
>>To jest sytuacja jak najbardziej typowa.
> 
> Nie wiedzę o czym mówisz. W kodzie shared_ptr z boosta nie widzę żadnej
> synchronizacji, więc nie wiem o czym mówisz.

Boszsz... Spytaj Piotra Wyderskiego, to ci powie. On robił to np. dla SPARCA.

Oczywiście że synchronizacja jest -- użycie operacji atomowych to myślisz że 
co to jest? I czemu jest o 2 rzędy wielkości sic(!) wolniejsze od normalnego 
dostępu do pamięci.


>>>A Lisp, no po prostu gigant softu król wyznaczający szosy dla maluczkich.
>>>Jak widać mamy w tym języku popisane systemy operacyjne, aplikacje
>>>multimedialne, GUI, łepsajty, aplikacje bankowe, gry, ... itd.
>>
>>O maszynach lispowych słyszał?
> 
> Nie.
> 
>>Gdy wszyscy babrali się w command-line to 
>>te cusie miały pełnoekranowy interfejs i bajery które reszta świata
>>odkryła 10 lat później.
> 
> Dziś wiele rzeczy, które są od lat w Adzie ludzie odkrywają.

Ada to jest rzecz całkem nowa i młoda w porównianiu do paru innych języków.

>>>Słowem Gigant.
>>
>>No właśnie tak!
> 
> Powiedz mi dlaczego Lispa określasz mianem giganta, a C++. Przecież lispa ma
> więcej odmian niż jest różnych implementacji kompilatorów C++.

Słyszałeś o Common Lisp? CLISP?

>  Przenośność
> kodu jest na poziomie 0.

To nie jest prawda

> A jednak Ty go wychwalasz. Jakaś sprzeczność.

Ja go specjalnie nie wychwalam. Po prostu stwierdzam fakt. Różne inne języki 
nieudolnie naśladują rozwiązania w Lispie znane od 30 lat.


>>Jak potrzebowałem pożądnego rozwiązania to zrobiłe sobie sam. Mam stukturę
>>o niewiadomej wielkości (a skąd mam wiedzieć ile obiektów zaraz zamierza
>>utworzyć program korzystający ze Śmieciucha) która często gwałtownie
>>rośnie. Wbudowany vector nie ma regulkacji tempa wzrostu a kurczenie jest
>>w ogóle arbitrane (i zwykle po prostu nie występuje) -- zrobiłem sobie
>>swój.
> 
> O jak mi przykro, że mogłeś się wykazać. A w Pythonie to takie predykcje są
> robione w liście i w GC.

W Pythonie włąsny kontener zrobię łatwiej i wygodniej niż w C++.

> I tak wolę C++ rozwiązania, bo są bardziej
> dedykowane -- w zakresie swojego użycia są szybsze i mniej zajmują ramu.

Są kiepskie. Sztywne i równocześnie nadmiernie skomplikowane. I niewiedzieć 
czemu ponazywali różne rzeczy inaczej niż reszta świata.


>>>O widzisz i tu sam się ugryzłeś w ogon :-D. Ten język jest niebezpieczny,
>>>bo nie traci czasu na zabezpieczenia niebezpiecznych rzeczy.
>>
>>Traci czas na duperele, takie jak synchronizacja shared_ptr której nie
>>użyję w 95% wypadków.
> 
> 
> Tak. Wiem. A synchronizacje w Pythonie nie istnieją -- podobno to jest
> bezpieczny język?

Istnieją.

> A w ogóle pokaż mi te synchronizacje w kodzie
> boost::shared_ptr.

Seweryn, a jak myślisz, jakim cudem to działa w wielu wątkach?


>>>Np. po co w aplikacji jednowątkowej mieć synchronizację wątków?
>>>Albo mając aplikację wielowątkową widząc gdzie się one spotykają
>>>synchronizujesz dokładnie to co jest wspólne i w sposób najbardziej
>>>odpowiedni.
>>
>>Nie mam takiej możlwości ani w przypadku wbudowanego new i delete ani w
>>przypadku shared_ptr, itd...
> 
> Pokaż mi odpowiedniki w Pythonie.

Każda refeferencja do obiektu jest odpowiednikiem (bardzo bliskim!) shared_ptr.


>>>Doświadczeni, czy Legacy people(tm)? Jak mnie nauka Haskella idzie
>>>opornie, to nie narzekam, że język jest do bani.
>>
>>Haskell jest bardzo dobrze przemyślany, ale wymaga zupełnie innego
>>"mind-set" niż języki imperatywne. C++ jest po prostu nieprzemyślany.
> 
> A może jest tak, że rzeczy proste robi się w nim w dziwny sposób, a rzeczy
> dziwne w prosty sposób. Jakoś nie widzę różnicy pomiędzy komplikacją
> szablonów i Haskella.

Haskell jest starannie przemyślany i ma ogromną wyrażalność. Szablony nie są 
ani przemyślane anie nie da się w nich sensownie wyrazić żadnej konkretnej 
złożoności -- trzeba stanąć na głowie żeby zrealizować zwykły warunek.

Szablony były zresztą (czasami panicznie) łatane. Stąd takie dziwności jak 
Koenig lookup, SFiNaE itd.


>>>>>Cierpi, czy nie cierpi to jest kwestia tego jak elegancko śmieci są
>>>>>upchane pod dywan.
>>>>
>>>>Raczej czy mamy klapę od silnika, aby było ciszej i jak olej pocieknie to
>>>>żeby został pod klapą.
>>>
>>>Widzisz mnie to nie rajcuje, że jak olej cieknie to zostaje pod klapą.
>>
>>Wolisz go mieć na sobie?
> 
> Dla mnie awaria to awaria. Czy na sobie to jest inna sprawa. Ale wolę
> widzieć jak cieknie.

To użyj Javy :) W C++ aboslutnie nie widzisz.


>>>Dla
>>>mnie pod klapą ma być równie czyściutko jak na klapie. W szczególności,
>>>że jak tak każdy zacznie olewać kiedy mu cieknie, byle nie na szybę, to
>>>będziemy jeździć na drogach posmarowanych olejem, a od tego do wypadków
>>>na szeroką skalę jest tylko krok.
>>
>>W silniku nie jest czysto.
>>Jak ktoś zgubi olej to niedojedzie. Ale lepiej 
>>żeby od razu nie został nim oblany.
> 
> 
> Widzisz dla mnie lepiej jak zostanie oblany. Serwery mają działać długo. Jak
> coś źle działa to nie zawsze tanie rozwiązanie polega ma resecie.

Tanie rozwiązanie polega na jak najszybszym powiadomieniu twórców o błędzie 
i w miarę możliwości automatycznym uruchomieniu opcji zapasowej (np. restart 
instanji aplikacji, jeśli jest odpowiednio zaprojektowana to np. bez utraty 
kontekstu)


> Jak jest
> jakiś bug gdzieś w aplikacyjne dla Xińskiego to sobie on może ją resetować.
> Ja wolę takiego scenariusza nie rozważać. Wolę kiedy moja aplikacja u mnie
> w sytuacji złego działania będzie oblewać mnie wrzącym olejem niż, żeby
> serwer potem dziwnie działał. Rozumiem, że dziś miarą jakości jest marka
> dyskontu spożywczego. Dawniej jak ktoś przychodził do Ciebie z reklamacją,
> to jako sprzedawca (lub producent) paliłeś się ze wstydu, że zrobiłeś
> badziewie.

???
Jeśli już, to właśnie C++ z jego UB i heisenbugami to jest jakość dysnontu 
zpożywczego.

>>C++ to taki samochód, co przy pierwszej drobnej awarii traci hamulce,
>>kierownica się blokuje a na kierowcę leci gorący olej i borygo.
> 
> Tak. To bardzo dobry język, bo low-quality koderzy dostają ciężkie baty.

Klient ma gdzieś, czy koder dostał baty czy ucieło mu głowę czy co innego. 
Klient nie ma zamiaru bycia oblanym olejem i borygo.


> Rozumiem, że dziś jest potrzeba zawodówek informatycznych -- chłopaki po SP.
> nr 1023 z Pustkowia piszą łepsajty. Super nie zamierzam im zabierać chleba.
> Są języki trudne i do nich trzeba podchodzić inaczej.

Tylko niektóre są trudne nie przez złożoność problemów które się wnich 
rozwiązuje tylko przez brak jakiegokolwiek projektu i robienie na zasadzie 
zlepku rozmaitych, dobrych i złych, ale dla paru wariatów "sexi" pomysłów.


> Zresztą Ty Sebastian nie doceniasz tego ile dało Ci C++ nawet jeśli
> poparzyłeś się olejem nie raz i nie dwa razy. Pokaż mi rodowitego Py
> kodera, który napisał swoje GC. 
> Już Ci mówiłem jeśli za kodera jest za wiele napisane, to on potem sam nie
> potrafi być twórczy. 
> 
> Np. systemy rozproszone najlepiej programują/projektują Ci co poczuli gorzki
> smak C, C++ i innych języków brzydkich. Gawiedź pisząca w PHP, zazwyczaj
> nie ma pojęcia o podstawowych kłopotach zarówno związanych z PHP jak i z
> systemami rozproszonymi.

A może to to że gawiedź pisząca PHP to właśnie, w znacznej większości, 
gawiedź a nie specjaliści. Od specjalisty wymagam znajomości Podstawowych
Kłopotów (powinieneś na to dac (tm) :) ) związanych z systemami 
rozproszonymi, współbieżnymi, z algorytmiką, bazami danych, systemami 
operacyjnymi, rachunkiem prawdopodibieństwa, teorią mnogości, analizą i 
algebrą. Ot takie mam drobne wymagania dla kogoś kto uważa się za specjalistę.

Kiedyś uczestniczyłem we flejmie bodaj na p.c.programming, gdzie jakiś facet 
  wypisywał jak to jego 16-letni syn kasuje wszystkich tych specjalistów i 
jak jest de best programmer i w ogóle (bodaj kontekst dotyczył tego po co te 
studia czy też czemu "oni" tyle pieniędzy chcą za "duperel" -- nie 
pamiętam). Zapytałem czy jego syn mógłby mi łaskawie sprowadzić prostą bazę 
(projekt bazy) do 3. postaci normalnej. Odpowiedzi nie dostałem :)

Cóż, każdy Polak zna się na medycynie, ekonomii i architekturze, a jego syn 
na informatyce ;)

[...]
pzdr
\SK

Witam

Sebastian Kaliszewski wrote:

>>>a w razie czego podstawienie zamiast niej czegoś
>>>własnego nie wpływa mi na miejsca użycia.
>> 
>> A niby z czym w C++ masz problemy?
> 
> W C++ niby uniwersalne kontenery uniwersalne nie są, w miarę uniwersalność
> kończy się na vector i deque oraz map i multimap.

No i?
 
>> Wieź mi tu nie zalatuj przykładami kodu powstałymi w czasie kiedy Python
>> był co najwyżej w umyśle GvR.
> 
> Języki bezpieczne znane są od ponad 45 lat. Języki w których nie ma
> podstawoych dziur w systemie typów były popularne już blisko 40 lat temu
> sic(!).

Tak i gdyby wtedy informatyka bazowała tylko na nich to do dziś byśmy mieli
tylko maszyny do pisania. Niebezpieczne języki pozwoliły wejść na orbitę
szybkości. A gdyby nie te niebezpieczne języki, to dziś nie miałbyś tych
niby lepszych bezpiecznych języków nowej generacji. Python w ogóle by nie
istniał, bo jego reference implementation stoi po pachy w C.
 
> [...]
>>>>>>No więc w C++ będziesz miał smart_ptr, na razie są one w boost (i nie
>>>>>>tylko np. g++ ma już w sobie mocną wersję tr1).
>>>>>
>>>>>Tyle że wbrew zasadzie you don't pay for what you don't use, w każdym
>>>>>użyciu zapłacę za sychronizację wątkową choć 95% wskazywanych obiektów
>>>>>nigdy pomiędzy wątkami nie będzie przekazywane.
>>>>
>>>>Jak masz taki projekt to tak.
>>>
>>>To jest sytuacja jak najbardziej typowa.
>> 
>> Nie wiedzę o czym mówisz. W kodzie shared_ptr z boosta nie widzę żadnej
>> synchronizacji, więc nie wiem o czym mówisz.
> 
> Boszsz... Spytaj Piotra Wyderskiego, to ci powie. On robił to np. dla
> SPARCA.
> 
> Oczywiście że synchronizacja jest -- użycie operacji atomowych to myślisz
> że co to jest? I czemu jest o 2 rzędy wielkości sic(!) wolniejsze od
> normalnego dostępu do pamięci.

O tak? A czy Piotr nie wspomniał, że w wersji MT?

I czy nie możesz mieć swojej banalnej implementacji bez tej synchronizacji?

Tak na marginesie nie wspomniałeś, że języki te lepsze to są natkane
synchronizacją synchronizacji a w nich też są synchronizacje. Które są nie
używane w 95% procentach, czyż nie?
 
>>>>A Lisp, no po prostu gigant softu król wyznaczający szosy dla
>>>>maluczkich. Jak widać mamy w tym języku popisane systemy operacyjne,
>>>>aplikacje multimedialne, GUI, łepsajty, aplikacje bankowe, gry, ... itd.
>>>
>>>O maszynach lispowych słyszał?
>> 
>> Nie.
>> 
>>>Gdy wszyscy babrali się w command-line to
>>>te cusie miały pełnoekranowy interfejs i bajery które reszta świata
>>>odkryła 10 lat później.
>> 
>> Dziś wiele rzeczy, które są od lat w Adzie ludzie odkrywają.
> 
> Ada to jest rzecz całkem nowa i młoda w porównianiu do paru innych
> języków.

Ale ja nie słyszę o tych jezykach, nie widzę ofert pracy, nie widzę
projektów (a już w mojej działce to w ogóle). Proszę oświeć mnie, bedę
wdzięczny.
 
>>>>Słowem Gigant.
>>>
>>>No właśnie tak!
>> 
>> Powiedz mi dlaczego Lispa określasz mianem giganta, a C++. Przecież lispa
>> ma więcej odmian niż jest różnych implementacji kompilatorów C++.
> 
> Słyszałeś o Common Lisp? CLISP?

Już tak.
 
>> A jednak Ty go wychwalasz. Jakaś sprzeczność.
> 
> Ja go specjalnie nie wychwalam. Po prostu stwierdzam fakt. Różne inne
> języki nieudolnie naśladują rozwiązania w Lispie znane od 30 lat.

No naśladują i co z tego? Python też niby jest ten tego ten trochę
funkcyjny. Mnie się to trochę podoba, a Ci co są "zboczeni" powiedzą, że to
jest kicha i dziadostwo.

> W Pythonie włąsny kontener zrobię łatwiej i wygodniej niż w C++.

I jest równie wydajny i zajmuje równie mało ramu, co?
 
>> I tak wolę C++ rozwiązania, bo są bardziej
>> dedykowane -- w zakresie swojego użycia są szybsze i mniej zajmują ramu.
> 
> Są kiepskie. Sztywne i równocześnie nadmiernie skomplikowane. I
> niewiedzieć czemu ponazywali różne rzeczy inaczej niż reszta świata.

Co np?
 
>>>Traci czas na duperele, takie jak synchronizacja shared_ptr której nie
>>>użyję w 95% wypadków.
>> 
>> 
>> Tak. Wiem. A synchronizacje w Pythonie nie istnieją -- podobno to jest
>> bezpieczny język?
> 
> Istnieją.

No więc właśnie one SĄ jest dzikie mnóstwo i często nie są w ogóle
wykorzystane, chyba że GC generuje jakiś nadmierny ruch.
 
>> A w ogóle pokaż mi te synchronizacje w kodzie
>> boost::shared_ptr.
> 
> Seweryn, a jak myślisz, jakim cudem to działa w wielu wątkach?

Działa na wielu wątkach, a ja myślałem, że C++ nie wpiera wątków?

Ile lat potrzebujesz aby napisać (skopiować) swojego shared_ptr, bez tej
nieszczęsnej synchronizacji? 

A ja i tak nie widzę gdzie w pliku boost/shared_ptr.hpp jest synchronizacja,
poproszę o pomoc publiczności.

C++0x ma wspomniane tak, że czytanie jest nie blokowane, tylko zmiany są
blokowane. Rozdział 2.11 Peter Becker  C++ STL Extensions + dyskusje na
boost. Ale To jest TR1, możesz użyć nie synchronizowanego również.

Zresztą, nie kapuję Twojego płaczu, kiedyś płakałeś, że nic nie jest
synchronizowane, teraz płączesz, że tr1::shared_ptr jest synchronizowany.
Nie rozumiem o co chodzi?
 
>>>>Np. po co w aplikacji jednowątkowej mieć synchronizację wątków?
>>>>Albo mając aplikację wielowątkową widząc gdzie się one spotykają
>>>>synchronizujesz dokładnie to co jest wspólne i w sposób najbardziej
>>>>odpowiedni.
>>>
>>>Nie mam takiej możlwości ani w przypadku wbudowanego new i delete ani w
>>>przypadku shared_ptr, itd...
>> 
>> Pokaż mi odpowiedniki w Pythonie.
> 
> Każda refeferencja do obiektu jest odpowiednikiem (bardzo bliskim!)
> shared_ptr.

I jak myślisz czy tam jest synchronizacja?
 
> Haskell jest starannie przemyślany i ma ogromną wyrażalność. Szablony nie
> są ani przemyślane anie nie da się w nich sensownie wyrazić żadnej
> konkretnej złożoności -- trzeba stanąć na głowie żeby zrealizować zwykły
> warunek.
> 
> Szablony były zresztą (czasami panicznie) łatane. Stąd takie dziwności jak
> Koenig lookup, SFiNaE itd.

Z czego SFINAE przynosi korzyści.
 
>>>>>>Cierpi, czy nie cierpi to jest kwestia tego jak elegancko śmieci są
>>>>>>upchane pod dywan.
>>>>>
>>>>>Raczej czy mamy klapę od silnika, aby było ciszej i jak olej pocieknie
>>>>>to żeby został pod klapą.
>>>>
>>>>Widzisz mnie to nie rajcuje, że jak olej cieknie to zostaje pod klapą.
>>>
>>>Wolisz go mieć na sobie?
>> 
>> Dla mnie awaria to awaria. Czy na sobie to jest inna sprawa. Ale wolę
>> widzieć jak cieknie.
> 
> To użyj Javy :) W C++ aboslutnie nie widzisz.

Java jest dla "niewyrażalna", że się tak wyrażę. A dokładniej chodzi mi np.
o erasure paskudnie to oddziałuje na kod. nieustanne łatanie jest
nieporównywalnie brzydkie z brzydkością MPL i Spiryt. A dalej tam gdzie ma
być dynamiczna to już wolę Py. No i ten cholerny wszędobylski XML nic nie
piszesz w J, tylko piszesz w XML, to po co w ogóle pisać w J.
 
>>>>Dla
>>>>mnie pod klapą ma być równie czyściutko jak na klapie. W szczególności,
>>>>że jak tak każdy zacznie olewać kiedy mu cieknie, byle nie na szybę, to
>>>>będziemy jeździć na drogach posmarowanych olejem, a od tego do wypadków
>>>>na szeroką skalę jest tylko krok.
>>>
>>>W silniku nie jest czysto.
>>>Jak ktoś zgubi olej to niedojedzie. Ale lepiej
>>>żeby od razu nie został nim oblany.
>> 
>> 
>> Widzisz dla mnie lepiej jak zostanie oblany. Serwery mają działać długo.
>> Jak coś źle działa to nie zawsze tanie rozwiązanie polega ma resecie.
> 
> Tanie rozwiązanie polega na jak najszybszym powiadomieniu twórców o
> błędzie i w miarę możliwości automatycznym uruchomieniu opcji zapasowej
> (np. restart instanji aplikacji, jeśli jest odpowiednio zaprojektowana to
> np. bez utraty kontekstu)

No i? Przykładem takich wymagań są bazy danych. Nie widzę żadnej napisanej w
językach lepszych. Większość jest pisana w C/C++. Relacyjne zazwyczaj w C,
obiektowe mieszają C i C++.

> Jeśli już, to właśnie C++ z jego UB i heisenbugami to jest jakość dysnontu
> zpożywczego.

A zyskiem jest wydajność? Hę? Nie ma nic za darmo dobrze o tym wiesz.
 
>>>C++ to taki samochód, co przy pierwszej drobnej awarii traci hamulce,
>>>kierownica się blokuje a na kierowcę leci gorący olej i borygo.
>> 
>> Tak. To bardzo dobry język, bo low-quality koderzy dostają ciężkie baty.
> 
> Klient ma gdzieś, czy koder dostał baty czy ucieło mu głowę czy co innego.
> Klient nie ma zamiaru bycia oblanym olejem i borygo.

O tak! Klient nie używa bazydanych innej niż napisanej w C/C++. Klient
płacze jak mu okienka wolno działają, już o grach nie wspomnę.
Pokaż mi w czym są napisane najpopularniejsze programy jak nie w C/C++?
Jest oczywiście cała masa softu w J, jako frontendy do baz danych
(napisanych w tych kulawych językach).
 
> Tylko niektóre są trudne nie przez złożoność problemów które się wnich
> rozwiązuje tylko przez brak jakiegokolwiek projektu i robienie na zasadzie
> zlepku rozmaitych, dobrych i złych, ale dla paru wariatów "sexi" pomysłów.

No tak, sexi to są recity w Pythonie na "ActiveState".
 
> A może to to że gawiedź pisząca PHP to właśnie, w znacznej większości,
> gawiedź a nie specjaliści. 

Ale wśród języków bezpiecznych takiej gawiedzi jest masa, bo oni czują się
tam bezpiecznie.

> Od specjalisty wymagam znajomości Podstawowych 
> Kłopotów (powinieneś na to dac (tm) :) ) związanych z systemami
> rozproszonymi, współbieżnymi, z algorytmiką, bazami danych, systemami
> operacyjnymi, rachunkiem prawdopodibieństwa, teorią mnogości, analizą i
> algebrą. 

O widzisz. Zaczynamy rozprawiać sensownie. Jak za Ciebie wszystko zostałby
rozwiązane, to czego byś się nauczył? I co byś umiał. Mam nieraz do
czynienia ze studentami, co kupują to i owo. Potem przychodzi ćwiczenie i
co oni robią? Chodzą po ścianach. 

Oni nie wierzą we własne siły, nie zastanawiają się, czy potrafią zrozumieć
problem, czy potrafią zapisać to co wiedzą na papierze i potem czy to da
się przelać na projekt. Wszystko zawsze kupowali (mieli podane na tacy).
Ktoś kto dotknął tego i owego brudnego i trudnego wie co umie, wie czego nie
umie. 
Dawałem studentom projekty na "6.0" Ci co skoczyli, aby pokonać trudności
dziś robią w projektach na 6.0, Ci co nie mieli ochoty pokonać żadnej
trudności i kupowali zaliczenie od qmpli może i zarabiają XXXXPLN, ale na
pewno nie robią zawodowych projektów na 6.0.

> Ot takie mam drobne wymagania dla kogoś kto uważa się za
> specjalistę.

Czy mogę dorzucić swoje wymagania? Może stworzymy "incredible-coder"?

I tak uważam, że nie doceniasz tego, że znasz C++ i jego paskudniaczki.

Czasami widuję dzieci bawiące się. Te które budują z klocków drewnianych i
pokonują siły grawitacji i zmagają się z równowagą, aby konstrukcje stały i
trzymały się, uczą się cierpliwości i poznawania sił fizyki. Uczą się tez
precyzji. A przecież klocki drewniane mają wadę nie mają "łączników".

Starsze dzieci bawią się Lego, budują wspaniałe pojazdy kosmiczne,
projektują konstrukcje robotów, łodzi, maszyn budowlanych itd.
Uczą się z małych gotowych, ale atomowych składników kreować wyimaginowaną
rzeczywistość. Znają zasady w świecie Lego, ale wiedzą, że mało ich
ogranicza -- chyba że wyobraźnia.

Ostatnia ekipa, to Bionicle + gotowe samochody. Co oni robią, uczą się
walczyć i hałasują bez przerwy. Kto ryczy głośniej ma mocniejszy silnik,
kto wrzeszczy donośniej ma większą "biomoc" i może powalić
wszystkich "bio"-przeciwników. Mają gotowce. Łatwo uzyskane "idealne"
konstrukcje.

A potem kogo zatrudniasz w pracy? Tych co "bio"-ryczą, czy tych co wyją
syrenami swoich gotowych pojazdów?

Klient może wymaga gotowca, ale gotowiec tworzą ludzie, którzy jak nie
potrafią budować, zmagać się ze swoim umysłem to gotowiec co najwyżej
kupią.

To nazywa się handel a nie informatyka. I w handlu też musisz być kreatywny,
ale na inny sposób.

A dorosli to jak dzieci. Tyle, że są bardziej dumni i leniwi. Nie chcą się
uczyć chcą mieć wszystko gotowe. Niestety tylko trud i pokonywanie
niedoskonałości potrafi uczyć. Gotowce nikogo nigdy niczego nie nauczą i
nienauczyły (chyba, że praktykujesz reverse engineering, ale nie o tym
mowa).

> Zapytałem czy jego syn mógłby mi łaskawie sprowadzić prostą 
> bazę (projekt bazy) do 3. postaci normalnej. Odpowiedzi nie dostałem :)

Nie zaskoczyłeś mnie wcale :-).
 
> Cóż, każdy Polak zna się na medycynie, ekonomii i architekturze, a jego
> syn na informatyce ;)

Przyznaję się, że nie jestem informatykiem, ani ekonomistą, ani
architektem :-). 

I szanuję C++, bo pozwala mi zrobić wszystko co potrzeba i jeszcze zmusza
mnie do nauki tego czego nie umiem. Zresztą trudność C++, powoduje, że np.
Py nie jest trudny, Java prosta. Przyznaję Haskell mi się odbija czkawką,
ale może to kwestia dobrej papierowej książki.

Dzielę ludzi na tych co piszą 500 stron raportu w Wordzie mozolnie klikając
i na tych co mają skrypt generujący kod dla np. Latexa. Jeśli Worda uczysz
się w 5 minut, to Latexa w 60 minut, ale 500 stron klikasz 2 tygodnie, a
skrypt piszesz 30 minut.

Wszyscy używają Worda, ale są tacy co używają latexa, który ma brzydkie
błędy i jak coś źle napiszesz, to wypisuje, że nie wie o czym mówisz.

Pozdrawiam.


-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia Wed, 21 Nov 2007 14:45:24 +0100, Sebastian Kaliszewski skrobie:
> Seweryn Habdank-Wojewódzki wrote:
> [ o listach]
> >>, jest lepiej 
> >>wpasowana do języka
> > 
> > Nie wydaje mi się, że lepiej.

> LOL, W pythonie lista ma reprezentację w samej składni.

I to ma niby świadczyć o lepszym wpasowaniu do języka?

Oj, Sebastian... gdybym cię nie znał, to bym myślał jeszcze, że mówisz
poważnie :)

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.

> >>a w razie czego podstawienie zamiast niej czegoś 
> >>własnego nie wpływa mi na miejsca użycia.
> > 
> > A niby z czym w C++ masz problemy?

> W C++ niby uniwersalne kontenery uniwersalne nie są, w miarę uniwersalność 
> kończy się na vector i deque oraz map i multimap.

Bo mniej więcej na tym kończą się kontenery w C++. Do vector i deque dorzuć
jeszcze list, do map i multimap dorzuć set i multiset i masz komplet.

Poza tym nie wiem, dlaczego właściwie uważasz, że vector jest bardziej
uniwersalny, niż list. To prawda, że vector nadaje się do tzw. "większości
zastosowań", ale ma jedną bardzo paskudną wadę: unieważnienie iteratorów
następuje tam po każdej modyfikacji liczebności zbiornika. Miałem właśnie
ostatnio taki przypadek, że musiałem trzymać iteratory do elementów, żeby je
móc szybko usuwać.

Podpowiesz mi może, jakiego rozwiązania powinienem użyć w Pythonie?

> > Wieź mi tu nie zalatuj przykładami kodu powstałymi w czasie kiedy Python był
> > co najwyżej w umyśle GvR.

> Języki bezpieczne znane są od ponad 45 lat. Języki w których nie ma 
> podstawoych dziur w systemie typów były popularne już blisko 40 lat temu sic(!).

A są nadal?

Powiedz, o które języki ci chodzi, to będziemy przynajmniej wiedzieli, na czym
stoimy.

> >>>A Lisp, no po prostu gigant softu król wyznaczający szosy dla maluczkich.
> >>>Jak widać mamy w tym języku popisane systemy operacyjne, aplikacje
> >>>multimedialne, GUI, łepsajty, aplikacje bankowe, gry, ... itd.
> >>
> >>O maszynach lispowych słyszał?
> > 
> > Nie.
> > 
> >>Gdy wszyscy babrali się w command-line to 
> >>te cusie miały pełnoekranowy interfejs i bajery które reszta świata
> >>odkryła 10 lat później.
> > 
> > Dziś wiele rzeczy, które są od lat w Adzie ludzie odkrywają.

> Ada to jest rzecz całkem nowa i młoda w porównianiu do paru innych języków.

A może byś tak napisał coś do rzeczy, zamiast rzucać sloganami?

> >>>Słowem Gigant.
> >>
> >>No właśnie tak!
> > 
> > Powiedz mi dlaczego Lispa określasz mianem giganta, a C++. Przecież lispa ma
> > więcej odmian niż jest różnych implementacji kompilatorów C++.

> Słyszałeś o Common Lisp? CLISP?

Owszem, jest to jedna z odmian Lispa, z ponad 10 łącznie. Cytując za
Wikipedią:

Common Lisp (1984), as described by Common Lisp: The Language (CLTL) . a
consolidation of several divergent attempts (ZetaLisp, Spice Lisp, NIL, and
S-1 Lisp) to create successor dialects[6] to MACLISP, with substantive
influences from the Scheme language as well. This version of Common Lisp was
available for a wide range of platforms and was accepted by many as a de facto
standard[7] until the publication of ANSI Common Lisp (ANSI X3.226-1994).

Podczas gdy oryginalna specyfikacja Lispa pochodzi z roku 1958.

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 mam co prawda żadnych
informacji ntt., ale już sam fakt, jak długo dogorywał ARM C++ (a i nadal
pewnie nie zdechł do końca) pozwala mi wątpić, jakoby istniał jakikolwiek
"wspólny i jedyny standard Lispa".

Sam C++, od czasów ARM, dorobił się dialektów raptem trzech (w porywach). A i
tak nie ma to tu specjalnie mówić o dialektach, biorąc pod uwagę, że chodzi tu
właściwie o rozszerzenia Borlanda i Microsoftu (rozszerzeń gcc nie liczę, bo w
ostatnich wersjach rozpirzyli wszystkie rozszerzenia na cztery wiatry).

> >  Przenośność
> > kodu jest na poziomie 0.

> To nie jest prawda

Czyżby?

> > A jednak Ty go wychwalasz. Jakaś sprzeczność.

> Ja go specjalnie nie wychwalam. Po prostu stwierdzam fakt. Różne inne języki 
> nieudolnie naśladują rozwiązania w Lispie znane od 30 lat.

Po prostu tłumaczą te ficzery na "ludzki język" :)

> >>Jak potrzebowałem pożądnego rozwiązania to zrobiłe sobie sam. Mam stukturę
> >>o niewiadomej wielkości (a skąd mam wiedzieć ile obiektów zaraz zamierza
> >>utworzyć program korzystający ze Śmieciucha) która często gwałtownie
> >>rośnie. Wbudowany vector nie ma regulkacji tempa wzrostu a kurczenie jest
> >>w ogóle arbitrane (i zwykle po prostu nie występuje) -- zrobiłem sobie
> >>swój.
> > 
> > O jak mi przykro, że mogłeś się wykazać. A w Pythonie to takie predykcje są
> > robione w liście i w GC.

> W Pythonie włąsny kontener zrobię łatwiej i wygodniej niż w C++.

To ja poproszę o przykład - tak jak wyżej opisałem std::list.

> > I tak wolę C++ rozwiązania, bo są bardziej
> > dedykowane -- w zakresie swojego użycia są szybsze i mniej zajmują ramu.

> Są kiepskie. Sztywne i równocześnie nadmiernie skomplikowane. I niewiedzieć 
> czemu ponazywali różne rzeczy inaczej niż reszta świata.

Co nazywasz "resztą świata" - Javę, czy Lispa?

> >>>Doświadczeni, czy Legacy people(tm)? Jak mnie nauka Haskella idzie
> >>>opornie, to nie narzekam, że język jest do bani.
> >>
> >>Haskell jest bardzo dobrze przemyślany, ale wymaga zupełnie innego
> >>"mind-set" niż języki imperatywne. C++ jest po prostu nieprzemyślany.
> > 
> > A może jest tak, że rzeczy proste robi się w nim w dziwny sposób, a rzeczy
> > dziwne w prosty sposób. Jakoś nie widzę różnicy pomiędzy komplikacją
> > szablonów i Haskella.

> Haskell jest starannie przemyślany i ma ogromną wyrażalność. Szablony nie są 
> ani przemyślane anie nie da się w nich sensownie wyrazić żadnej konkretnej 
> złożoności -- trzeba stanąć na głowie żeby zrealizować zwykły warunek.

> Szablony były zresztą (czasami panicznie) łatane. Stąd takie dziwności jak 
> Koenig lookup, SFiNaE itd.

Koenig lookup jest tylko uporządkowaniem spraw, a SFiNaE było od samego
początku podstawą funkcjonowania szablonów w C++.

Można oczywiście kwestionować sensowność "ograniczania przez użycie" oraz
sensowność sposobu pracy komitetu, który wysysa sobie z palca reguły języka,
do których potem producenci kompilatorów muszą wyharatać implementacje (bo
jakby goście wcześniej zauważyli te spaghetti-messages, to może losy wzorców
potoczyłyby się inaczej). Ale na ówczesny stan wiedzy rozwiązanie wydawało się
najlepsze.

Ale jeśli wydaje ci się, że języki, których standardy są robione równolegle z
referencyjną implementacją, nie posiadają idiotyzmów, to jesteś w błędzie.

Właśnie ostatnio się o tym przekonałem. Java, jako jedyny język z grupy
Java/C#/C++, posiada ścisłe wyjątki.

Efekt jest taki, że zamiast skupić się w trakcie "dewelopmentu" na tym, żeby
przynajmniej działał optymistyczny scenariusz, a wszelki "error handling"
odłożyć na później, pierwsza rzecz, z którą muszę walczyć, żeby mi się
kompilował kod, to z zaprogramowaniem polityki obsługi błędnych sytuacji przez
wyjątki. Zazwyczaj efekt jest tego taki, że polityka obsługi błędów jest
odwalona na kolanie i zrobiona na łapu-capu, bo chciałbym jak najszybciej,
najtańszym kosztem otrzymać wreszcie coś, co mogę sprawdzić, czy zechce
działać.

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 ) {}

I tu właśnie nasuwa się pomału sugestia, dlaczego ścisłe wyjątki są głupim
rozwiązaniem: po prostu, w większości normalnej pracy dany wyjątek nie ma
szansy wystąpić. Jeśli, dajmy na to, jakaś funkcja przyjmuje liczby całkowite
i dla ujemnych rzuca StupidValueException, to po cholerę mam robić try/catch,
skoro wywołuję ją z abs(value) ?

Sam nawet byłem kiedyś zwolennikiem ścisłych wyjątków - wydawało mi się, że
zrobienie ścisłych wyjątków pomogłoby statycznie wyeliminować "unexpected
exception", a także zrobić jakiś sensowny użytek z ograniczeń na wyjątki.
Nadal uważam, że pomysł jest wart rozważenia, ale do tematu należy podchodzić
cholernie ostrożnie. A właściwie to jedyną sensowną formę sprawdzanych
wyjątków widziałbym w postaci dodatkowego narzędzia, które wykonuje dokładne
śledzenie wyjątków i wskazuje, gdzie może wystąpić nieoczekiwane zwinięcie
przez wyjątek. Nawet już są narzędzia, które to robią, tylko po prostu jedynym
dodatkiem byłaby możliwość używania tej informacji przez kompilator w celu
zoptymalizowania kodu (eliminacji zbędnych sprawdzeń w czasie wykonywania).

Gdyby używać takiego narzędzia, można by się bawić w ograniczenia na wyjątki.
Jeśli to narzędzie byłoby wystarczająco wiarygodne, wtedy można by W RAZIE
CHCIEJSTWA (a w razie niechciejstwa nie) używać organiczeń na wyjątki i
przechwytywać je w odpowiednich miejscach. Często nawet w wielu API ma sens
posiadanie osobno funkcji rzucającej wyjątek i nie rzucającej wyjątku, czy
nawet posiadanie funkcji, która przejmie wszystkie wyjątki i ewentualnie
zwróci wartość błędu.

A co jeszcze ciekawsze, nie wszystkie wyjątki w Javie wymagają jawnej obsługi.
Czyli - ścisłe, ale nie do końca?

Ja wiem - ścisłe do końca nie miałyby w ogóle sensu, bo wtedy każde jedno
głupie odwołanie się do dowolnego wskaźnika na obiekt należałoby obwarować
łapaniem np. NullPointerException. Ale to nie powoduje bynajmniej, że te
ścisłe nie do końca wyjątki mają tego sensu więcej.

I to jest ficzer, który mocno utrudnia życie, nie sądzę żeby przyczyniał się
do zwiększenia jakości developmentu, a zmienić go już nie będzie można. A do
wzorców w C++ definiowanie ograniczeń dodać można.

I która z tych pomyłek jest bardziej spektakularna?

> > Jak jest
> > jakiś bug gdzieś w aplikacyjne dla Xińskiego to sobie on może ją resetować.
> > Ja wolę takiego scenariusza nie rozważać. Wolę kiedy moja aplikacja u mnie
> > w sytuacji złego działania będzie oblewać mnie wrzącym olejem niż, żeby
> > serwer potem dziwnie działał. Rozumiem, że dziś miarą jakości jest marka
> > dyskontu spożywczego. Dawniej jak ktoś przychodził do Ciebie z reklamacją,
> > to jako sprzedawca (lub producent) paliłeś się ze wstydu, że zrobiłeś
> > badziewie.

> ???
> Jeśli już, to właśnie C++ z jego UB i heisenbugami to jest jakość dysnontu 
> zpożywczego.

z pożywczego, czy bez, heisenbugi zdarzają się tak samo w C++, jak i w Javie.
A ja robię właśnie aplikację, której część jest w Javie (GWT), część w C++ i
część w Tcl-u i mogę powiedzieć jedno: jak na razie najbardziej męczy mnie
Java - ale to pewnie dlatego, że Javę najmniej znam. Moje pierwsze wrażenia są
takie: nigdy niczego nie można być pewnym na 100% :)

(przy okazji - część w C++ to w miarę uniwersalny agent zdalnie uruchamianych
aplikacji; osiągnęła aktualnie jakość przedprodukcyjną - czytaj trzeba
pousuwać zbędne printy do cerr i zmienić sposób logowania pracy - i w trakcie
jej developmentu nie napotkałem do tej pory ani jednego UB, ani SIGSEGV.
Faktem jest jednak, że nie chodzi pod Cygwinem, bo jest jakiś problem z
pthreads:)

> >>C++ to taki samochód, co przy pierwszej drobnej awarii traci hamulce,
> >>kierownica się blokuje a na kierowcę leci gorący olej i borygo.
> > 
> > Tak. To bardzo dobry język, bo low-quality koderzy dostają ciężkie baty.

> Klient ma gdzieś, czy koder dostał baty czy ucieło mu głowę czy co innego. 
> Klient nie ma zamiaru bycia oblanym olejem i borygo.

Moment - może najpierw zastanówmy się, o czym w ogóle rozmawiamy.

Czy rozmawiamy o języku, który przed każdą operacją wykonuje 10 sprawdzeń, czy
na pewno tak, czy o platformie wykonania, która potrafi wszelkie tego typu
wycieki odpowiednio "zamaskować"?

> > Rozumiem, że dziś jest potrzeba zawodówek informatycznych -- chłopaki po SP.
> > nr 1023 z Pustkowia piszą łepsajty. Super nie zamierzam im zabierać chleba.
> > Są języki trudne i do nich trzeba podchodzić inaczej.

> Tylko niektóre są trudne nie przez złożoność problemów które się wnich 
> rozwiązuje tylko przez brak jakiegokolwiek projektu i robienie na zasadzie 
> zlepku rozmaitych, dobrych i złych, ale dla paru wariatów "sexi" pomysłów.

Zgadza się - ale na te zwykle są gotowe rozwiązania, tylko wystarczy się
rozejrzeć.

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

> > Zresztą Ty Sebastian nie doceniasz tego ile dało Ci C++ nawet jeśli
> > poparzyłeś się olejem nie raz i nie dwa razy. Pokaż mi rodowitego Py
> > kodera, który napisał swoje GC. 
> > Już Ci mówiłem jeśli za kodera jest za wiele napisane, to on potem sam nie
> > potrafi być twórczy. 
> > 
> > Np. systemy rozproszone najlepiej programują/projektują Ci co poczuli gorzki
> > smak C, C++ i innych języków brzydkich. Gawiedź pisząca w PHP, zazwyczaj
> > nie ma pojęcia o podstawowych kłopotach zarówno związanych z PHP jak i z
> > systemami rozproszonymi.

> A może to to że gawiedź pisząca PHP to właśnie, w znacznej większości, 
> gawiedź a nie specjaliści. Od specjalisty wymagam znajomości Podstawowych
> Kłopotów (powinieneś na to dac (tm) :) ) związanych z systemami 
> rozproszonymi, współbieżnymi, z algorytmiką, bazami danych, systemami 
> operacyjnymi, rachunkiem prawdopodibieństwa, teorią mnogości, analizą i 
> algebrą. Ot takie mam drobne wymagania dla kogoś kto uważa się za specjalistę.

No i słusznie. Ale tak się akurat składa, że Języki Przemysłowo-Biznesowe(tm)
są w większości chwytane przez tych, którzy o powyższych sprawach nie mają
bladego pojęcia.

> Kiedyś uczestniczyłem we flejmie bodaj na p.c.programming, gdzie jakiś facet 
>   wypisywał jak to jego 16-letni syn kasuje wszystkich tych specjalistów i 
> jak jest de best programmer i w ogóle (bodaj kontekst dotyczył tego po co te 
> studia czy też czemu "oni" tyle pieniędzy chcą za "duperel" -- nie 
> pamiętam). Zapytałem czy jego syn mógłby mi łaskawie sprowadzić prostą bazę 
> (projekt bazy) do 3. postaci normalnej. Odpowiedzi nie dostałem :)

> Cóż, każdy Polak zna się na medycynie, ekonomii i architekturze, a jego syn 
> na informatyce ;)

Nieważne, kto strzela gole, ważne kto jest sędzią :)


-- 
//  _    ___         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"

Witam

Sektor van Skijlen wrote:

> Ale jeśli wydaje ci się, że języki, których standardy są robione
> równolegle z referencyjną implementacją, nie posiadają idiotyzmów, to
> jesteś w błędzie.
 
C++0x powoli dorabia sobie reference implementation w postaci gcc 4.3 :-).
To dla tych co narzekają, że komitet wymyśli coś czego nie da się
zaimplementować.

> Efekt jest taki, że zamiast skupić się w trakcie "dewelopmentu" na tym,
> żeby przynajmniej działał optymistyczny scenariusz, a wszelki "error
> handling" odłożyć na później, pierwsza rzecz, z którą muszę walczyć, żeby
> mi się kompilował kod, to z zaprogramowaniem polityki obsługi błędnych
> sytuacji przez wyjątki. Zazwyczaj efekt jest tego taki, że polityka
> obsługi błędów jest odwalona na kolanie i zrobiona na łapu-capu, bo
> chciałbym jak najszybciej, najtańszym kosztem otrzymać wreszcie coś, co
> mogę sprawdzić, czy zechce działać.

He, he. A kto potem wraca, aby zrobić refaktoring? Jak "działa" to lepiej
pisać nowe ficzery niż poprawiać politykę obsługi blędów, czy nie ;-)? 

> Nawet już są narzędzia, które to robią,

Jakie?

> A co jeszcze ciekawsze, nie wszystkie wyjątki w Javie wymagają jawnej
> obsługi. Czyli - ścisłe, ale nie do końca?

Może zarzucić jakimś krótkim kodem? Z tego co pamiętam to rzutowania na zły
typ powodują paskudne skutki (NullPointerException).
 
> z pożywczego, czy bez, heisenbugi zdarzają się tak samo w C++, jak i w
> Javie.

{Do Sebastiana}

A tak przyokazji według Wikipedii heisenbugi również są związane z "race
conditions". Rozumiem, że np. w Lispie i Pythonie nie można zrobić "race
condition", czy się mylę? 

Moim faworytem jest Logo to jest naprawdę bezpieczny język.

> No i słusznie. Ale tak się akurat składa, że Języki
> Przemysłowo-Biznesowe(tm) są w większości chwytane przez tych, którzy o
> powyższych sprawach nie mają bladego pojęcia.

Tak, ale to jest złe.

Pozdrawiam. 

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

>> A co jeszcze ciekawsze, nie wszystkie wyjątki w Javie wymagają jawnej
>> obsługi. Czyli - ścisłe, ale nie do końca?
> 
> Może zarzucić jakimś krótkim kodem? Z tego co pamiętam to rzutowania na
> zły typ powodują paskudne skutki (NullPointerException).
> 

Wyrzuca ClassCastException.
NullPointerException to jak próbujesz wykonać metodę na NULL'u.

Generalnie struktura tego jest taka:

                       +-----------+
                       | Throwable |
                       +-----------+
                             ^^
                    /--------/\-----\
                   /                 \
              +-------+          +-----------+
              | Error |          | Exception |
              +-------+          +-----------+
                 ^                  ^      ^
               Wiele klas      Wiele klas  \
                                       +------------------+
                                       | RuntimeException |
                                       +------------------+
                                               ^
                                            Wiele klas
Wyrzucić można dowolne Throwable. Wyłapać można tylko Exception a 
'zignorować' (czyli nie wyłapywać i nie oznaczać metody, że wyrzuca 
wyjątki) można RuntimeException. Tak - logiczne ;)

Co ciekawę z tego co pamiętam Exception jest odpowiednikiem 
std::runtime_exception - ale głowy nie dam.
 
>> z pożywczego, czy bez, heisenbugi zdarzają się tak samo w C++, jak i w
>> Javie.
> 
> {Do Sebastiana}
> 
> A tak przyokazji według Wikipedii heisenbugi również są związane z "race
> conditions". Rozumiem, że np. w Lispie i Pythonie nie można zrobić "race
> condition", czy się mylę?
> 

Python chyba nie ale funkcje w Lispie teoretycznie nie mają efektów 
uboczych więc nie powinno być problemu (praktyka jest inna np. z I/O, ale 
w założeniach chyba nie ma race conditions). 

> Moim faworytem jest Logo to jest naprawdę bezpieczny język.
>

Nie wymawiaj tej nazwy. Musiałem się tego uczyć jak już znałęm C. 
Męczarnia - w dodatku IMHO zupełnie dla mnie nieprzydatna. Strasznie 
sprofanowany LISP.
 
Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

Dnia Wed, 21 Nov 2007 23:00:26 +0100
Seweryn Habdank-Wojewódzki <shw_mail@wp.pl> napisał(a):

> Moim faworytem jest Logo to jest naprawdę bezpieczny język.
Nie wiem czy śledziłeś wątek z p.c.programming 'Logo :-)'. W
skrócie poczepiali się błędów w implementacjach logo jak:
? define (10 10)
Segmentation fault

i Piotr Dembiński zamknął stwierdzeniem, że ten język parsuje się
trudno... choć pewnie do C i C++ mu daleko.

Po prawdzie -- logo nie znam. Za swojego faworyta w konkurencji
bezpiecznych języków uznałbym chyba LUA. 


Pozdrawiam. 
-- 
Tomasz bla Fortuna
jid: bla(at)af.gliwice.pl
pgp: 0x90746E79 @ pgp.mit.edu
www: http://bla.thera.be

On Wed, 21 Nov 2007 22:13:13 +0100, Seweryn Habdank-Wojewódzki wrote:

> No i? Przykładem takich wymagań są bazy danych. Nie widzę żadnej
> napisanej w językach lepszych. Większość jest pisana w C/C++. Relacyjne
> zazwyczaj w C, obiektowe mieszają C i C++.

db4o?

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

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.

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

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

Mam rozumieć, że lepiej, kiedy sprzątanie przez wątek po jego przerwaniu
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? :-)

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

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

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Witam

Maciej Piechotka wrote:

> On Wed, 21 Nov 2007 22:13:13 +0100, Seweryn Habdank-Wojewódzki wrote:
> 
>> No i? Przykładem takich wymagań są bazy danych. Nie widzę żadnej
>> napisanej w językach lepszych. Większość jest pisana w C/C++. Relacyjne
>> zazwyczaj w C, obiektowe mieszają C i C++.
> 
> db4o?

Nie tylko. Orient, EyEDB. Są też komercyjne ODBMS, ale co do nich nie mam
pewności w jakim stopniu są pisane w C++. Na 100% w jakimś są pisane, bo
część z nich ma eleganckie bindery do C++. 
W szczególności coś o czym kiedyś pisałem -- rozproszona referencja do
obiektu wygląda jakoś tak mocno C++ np. d_ref<>.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

On Thu, 22 Nov 2007 00:38:21 +0100, Marcin ‘Qrczak’ Kowalczyk wrote:

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

C i C++ są dokładnie na poziomie Javy i C#:
int getInt() {
        static int i = 0;
        return i++;
}

void test() {
        int i[] = {getInt(), getInt(), getInt()};
}

C++0x nawet prześcignie Javę ;)

Pozdrawiam

PS.
Tak - wiem, że kolejność lidzb jest nieustalona...
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

Witam

Maciej Piechotka wrote:

>> Moim faworytem jest Logo to jest naprawdę bezpieczny język.
>>
> 
> Nie wymawiaj tej nazwy. Musiałem się tego uczyć jak już znałęm C.
> Męczarnia - w dodatku IMHO zupełnie dla mnie nieprzydatna. Strasznie
> sprofanowany LISP.

Dla mnie to była bardzo dobra zabawa z dzieciństwa :-D. A dziś ten język
mniej więcej można używać do ploterów tnących (CNC).

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia Wed, 21 Nov 2007 23:00:26 +0100, Seweryn Habdank-Wojewódzki skrobie:
> Witam

> Sektor van Skijlen wrote:

> > Ale jeśli wydaje ci się, że języki, których standardy są robione
> > równolegle z referencyjną implementacją, nie posiadają idiotyzmów, to
> > jesteś w błędzie.
>  
> C++0x powoli dorabia sobie reference implementation w postaci gcc 4.3 :-).
> To dla tych co narzekają, że komitet wymyśli coś czego nie da się
> zaimplementować.

O właśnie!

Bronek: może tam w komitecie ktoś rozważa propozycję, żeby gcc stało się
oficjalną dla X3J16 referencyjną implementacją do C++0x?

Tak w ogóle mi się zresztą przypomniało, że miałem jakiś kod, który kompilował
się normalnie, a nie kompilował się w ConceptGCC.

> > Efekt jest taki, że zamiast skupić się w trakcie "dewelopmentu" na tym,
> > żeby przynajmniej działał optymistyczny scenariusz, a wszelki "error
> > handling" odłożyć na później, pierwsza rzecz, z którą muszę walczyć, żeby
> > mi się kompilował kod, to z zaprogramowaniem polityki obsługi błędnych
> > sytuacji przez wyjątki. Zazwyczaj efekt jest tego taki, że polityka
> > obsługi błędów jest odwalona na kolanie i zrobiona na łapu-capu, bo
> > chciałbym jak najszybciej, najtańszym kosztem otrzymać wreszcie coś, co
> > mogę sprawdzić, czy zechce działać.

> He, he. A kto potem wraca, aby zrobić refaktoring? Jak "działa" to lepiej
> pisać nowe ficzery niż poprawiać politykę obsługi blędów, czy nie ;-)? 

Nie nie, nie o takie rzeczy chodzi.

Mnie potrzeba napisania SZYBKO i przetestowania SZYBKO kodu, który obsługuje
optymistyczne scenariusze. Wiadomo, że NIE MOŻESZ przecież doprowadzić kodu do
release'u, jeśli nie dorobisz obsługi pesymistycznych scenariuszy i nie
zaprogramujesz error-handling - ale w C++ to jest rzecz, którą można odłożyć
na później. Od tego ewentualnie są code reviews, i testy jednostkowe, żeby
zgubione error handlingi wyłapać.

Ale w dzisiejszym podejściu do oprogramowania najważniejsze jest DEMO. Czyli
działająca aplikacja, którą można pokazać klientowi, że mniej więcej tak to ma
działać. Ale uprzedza się, że to jest na razie posklejane drutem i jakość
produkcyjną osiągnie dopiero za jakiś czas.

> > Nawet już są narzędzia, które to robią,

> Jakie?

Nie wiem, czy nie Klocwork - mówię to z głowy, więc może i nie ma. Wydawało mi
się, że widziałem zgłaszane problemy z unexpected exception, ale nie dam
głowy.

Zresztą, jeśli nie ma, to może chwilowo nie ma zapotrzebowania (właśnie przez
to, że nie ma tylu wyjątków :).

> > A co jeszcze ciekawsze, nie wszystkie wyjątki w Javie wymagają jawnej
> > obsługi. Czyli - ścisłe, ale nie do końca?

> Może zarzucić jakimś krótkim kodem? Z tego co pamiętam to rzutowania na zły
> typ powodują paskudne skutki (NullPointerException).

Każda metoda domyślnie przepuszcza RuntimeException (a jak ta, to wszystkie
jej pochodne, w tym NullPointerException). I nie ma sposobu, żeby jej tego
zabronić (chyba że obejmiesz trajem całe ciało metody). Wszelkie inne klasy
wyjątków muszą być jawnie obsługiwane lub jawnie propagowane.

>  
> > z pożywczego, czy bez, heisenbugi zdarzają się tak samo w C++, jak i w
> > Javie.

> {Do Sebastiana}

> A tak przyokazji według Wikipedii heisenbugi również są związane z "race
> conditions". Rozumiem, że np. w Lispie i Pythonie nie można zrobić "race
> condition", czy się mylę? 

:)

> Moim faworytem jest Logo to jest naprawdę bezpieczny język.

:)))))

> > No i słusznie. Ale tak się akurat składa, że Języki
> > Przemysłowo-Biznesowe(tm) są w większości chwytane przez tych, którzy o
> > powyższych sprawach nie mają bladego pojęcia.

> Tak, ale to jest złe.

No ale jeśli biznesowi takie badziewia wystarczają, to jego sprawa i nic w tym
temacie nie poradzisz.

-- 
//  _    ___         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"

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"

Dnia Wed, 21 Nov 2007 23:56:54 +0100, Tomasz bla Fortuna skrobie:
> Dnia Wed, 21 Nov 2007 23:00:26 +0100
> Seweryn Habdank-Wojewódzki <shw_mail@wp.pl> napisał(a):

> > Moim faworytem jest Logo to jest naprawdę bezpieczny język.
> Nie wiem czy śledziłeś wątek z p.c.programming 'Logo :-)'. W
> skrócie poczepiali się błędów w implementacjach logo jak:
> ? define (10 10)
> Segmentation fault

> i Piotr Dembiński zamknął stwierdzeniem, że ten język parsuje się
> trudno... choć pewnie do C i C++ mu daleko.

> Po prawdzie -- logo nie znam. Za swojego faworyta w konkurencji
> bezpiecznych języków uznałbym chyba LUA. 

Ależ daj spokój, nie licytujmy się w bezpieczeństwie języków skryptowych, bo
po prawdzie we wszystkich (poza Perlem) jest z tym podobnie.

-- 
//  _    ___         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"

Witam

Sektor van Skijlen wrote:

> Nadużywa się ich, zamiast zrobić to samo
> na włóknach.

Co to jest włókno?

Pozdrawiam. 

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Seweryn Habdank-Wojewódzki wrote:
> Co to jest włókno?
> 

http://en.wikipedia.org/wiki/Fiber_(computer_science)

Pozdrawiam
KK

Dnia 22-11-2007, Cz o godzinie 01:42 +0100, Maciej Piechotka pisze:

> C i C++ są dokładnie na poziomie Javy i C#:

Nie chce mi się sprawdzać, w którym z nich od których wersji, ale na
pewno są *wyrażenia* wyglądające jakoś tak:
   new int[] {getInt(), getInt(), getInt()}
co już zbliża się do składni w stylu [1, 2, 3].

Poza tym wbudowane tablice C++ są słabe, bo nie znają swojej własnej
wielkości w czasie wykonania. Żeby zrobić std::vector o danych
elementach, trzeba albo pisać własny konwerter łapiący wielkość
parametrem szablonu, albo ręcznie tę wielkość podawać.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Dnia 22-11-2007, Cz o godzinie 08:30 +0000, Sektor van Skijlen pisze:

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

W którymś momencie tak, ale lepiej nie przy każdym sleepie osobno,
tylko zbiorczo w głównej funkcji wątku.

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

O przerwaniu wątku, a nie wyjątku. Sleep jest jedną z funkcji,
która reaguje na przerwanie wątku z zewnątrz (Thread.interrupt).
Stąd możliwość InterruptedException.

Nie należy pisać tak jak napisałeś (połykać InterruptedException).
http://www-128.ibm.com/developerworks/java/library/j-jtp05236.html

Pewnym odpowiednikiem tego w SUS są funkcje, które są przerywane przez
pthread_cancel w stanie PTHREAD_CANCEL_DEFERRED + PTHREAD_CANCEL_ENABLE
(domyślnym zresztą):
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_05_02

Jedno i drugie jest raczej sztuczką niż porządnym projektem językowym.
Ponieważ te języki nie dostarczają mechanizmów pozwalających
programiście informować, w których momentach można przerwać wątek,
domyślnie zakłada się, że można to zrobić wtedy, kiedy wątek na coś
czeka (ale nie na mutex). Bo po pierwsze jest szansa, że takie momenty
będą zdarzały się wystarczająco często, a po drugie jest szansa, że
wszelkie niezmienniki globalnych struktur danych będą wtedy zachowane.

Różnica między Javą a Uniksem polega w tym miejscu na tym, że Java
zmusza programistów do zauważenia, że dana funkcja jest przerywalna,
a Unix nie. W połączeniu ze sprawą odśmiecania powoduje to, że
w Uniksowym C/C++ pthread_cancel ma małe szanse poprawnego działania.
Większość programistów nawet nie wie, że taka funkcja istnieje, i nie
pisze kodu tak żeby działał poprawnie w obliczu asynchronicznych
przerwań.

Zgadzam się, że checked exceptions powodują z reguły więcej kłopotu niż
pożytku, ale z tego nie wynika, że jest w nic samo zło.

> To, że w Javie funkcja sleep() jest metodą klasy Thread to tylko taka jej specyfika.

Nieważne, jakiej metody jest klasą. Ważne, że pozwala na
InterruptedException. Metoda Object.wait też jest przerywalna,
chociaż nie jest metodą klasy Thread.

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

Gdyby mógł wystąpić w zupełnie dowolnym momencie, to nie dałoby się
pisać poprawnego kodu, bo np. nie da się zagwarantować, że z pewnych
dwóch instrukcji wykonają się obie albo żadna.

Należy umożliwić wątkowi blokowanie przerywania oraz zintegrować
automatyczne blokowanie z innymi konstrukcjami języka (większość
programistów nie myśli o możliwości przerwania wątku i tego nie
zmienimy). Jeśli się postarać, jeśli język ma szansę rozpoznać
regiony, które muszą się wykonać w całości, w sposób niewymagający
od programisty dużego zachodu, to można domyślnie dopuścić przerywanie
w dowolnym momencie.

Przy czym w C++ nie ma na to szans, bo jest zdecydowanie zbyt wiele
miejsc, których nie można przerwać, ale nie ma jak ich automatycznie
rozpoznać. Na przykład region między new a przypisaniem gołego wskaźnika
do sprytnego wskaźnika nie może być przerywalny (przynajmniej przy
standardowym alokatorze).

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

Uważasz, że lepiej wprowadzać sztuczne utrudnienia w używaniu wątków,
żeby zniechęcać do nich programistę?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

On Thu, 22 Nov 2007 10:55:43 +0100, Marcin ‘Qrczak’ Kowalczyk wrote:

> Dnia 22-11-2007, Cz o godzinie 01:42 +0100, Maciej Piechotka pisze:
> 
>> C i C++ są dokładnie na poziomie Javy i C#:
> 
> Nie chce mi się sprawdzać, w którym z nich od których wersji, ale na
> pewno są *wyrażenia* wyglądające jakoś tak:
>    new int[] {getInt(), getInt(), getInt()}
> co już zbliża się do składni w stylu [1, 2, 3].
> 

Patrz na dole mojego postu: *we wszystkich są*.
Kod kompilujący się pod gcc i z rozszerzeniem .c:
int getInt() {
        static int i = 0;
        return i++;
}

void test() {
        int i[] = {getInt(), getInt(), getInt()};
}

> Poza tym wbudowane tablice C++ są słabe, bo nie znają swojej własnej
> wielkości w czasie wykonania. Żeby zrobić std::vector o danych
> elementach, trzeba albo pisać własny konwerter łapiący wielkość
> parametrem szablonu, albo ręcznie tę wielkość podawać.

W C++0x będzie możliwość takiej inicjalizacji a 'już teraz' można robić 
trochę brzydkiej roboty z wskaźnikami + sizeof().

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

Dnia 22-11-2007, Cz o godzinie 21:41 +0100, Maciej Piechotka pisze:

> > Nie chce mi się sprawdzać, w którym z nich od których wersji, ale na
> > pewno są *wyrażenia* wyglądające jakoś tak:

>         int i[] = {getInt(), getInt(), getInt()};

To jest składnia definicji zmiennej, a nie wyrażenia. Po pierwsze nie
można tego umieścić wewnątrz wyrażenia, tylko trzeba wynieść na poziom
deklaracji, a po drugie wielkość trzeba przekazać osobno. To jest
poniżej poziomu Javy i C#.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Dnia Thu, 22 Nov 2007 10:30:59 +0100, Seweryn Habdank-Wojewódzki skrobie:
> Witam

> Sektor van Skijlen wrote:

> > Nadużywa się ich, zamiast zrobić to samo
> > na włóknach.

> Co to jest włókno?

Coś w stylu wątków, które nie wykonują się równolegle, tylko etapami
z ręcznym przełączaniem.

Właściwie to wątki można po prawdzie porównać do włókien, w których
przełączanie zadań następuje w arbitralnym momencie. Jeśli założymy, że wątki
jednego procesu są wykonywane przez jeden procesor (dla uproszczenia), to
wtedy okazuje się, że wątki i włókna niewiele się różnią - jedynie właśnie
tym, że nie wiadomo, w którym momencie nastąpi przełączenie. W przypadku
włókien wiadomo to z góry.

A dalej wiadomo o co chodzi - w przypadku wątków arbitralność przełączania
powoduje, że stan danych jest również arbitralny, a więc o nieznanej
stabilności. Skoro tak, to należy stosować mutexy, aby powstrzymać próbę
wykonania operacji na niestabilnych danych.

W przypadku włókien wystarczy zapewnić, że stan danych jest stabilny zanim
nastąpi przełączenie.


-- 
//  _    ___         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"

Dnia Thu, 22 Nov 2007 13:21:31 +0100, Marcin ?Qrczak? Kowalczyk skrobie:
> Dnia 22-11-2007, Cz o godzinie 08:30 +0000, Sektor van Skijlen pisze:

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

> W którymś momencie tak, ale lepiej nie przy każdym sleepie osobno,
> tylko zbiorczo w głównej funkcji wątku.

Momencik.

Na pewno masz rację. I bardzo chętnie bym to zrobił, tylko nie w sytuacji, gdy
InterruptedException nie jest pochodną RuntimeException, więc z jednego
głupiego sleep() muszę go przepropagować przez całą ścieżkę.

Ciekaw jestem swoją drogą, czy nie kończy się to czasem tym, że programiści
wkurzeni koniecznością definiowania propagacji po prostu każą się wątkowi
ukryć "pod osią ciężarówki RuntimeException".

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

> O przerwaniu wątku, a nie wyjątku.

Taaa... już mi się wszystko plącze :)

> Sleep jest jedną z funkcji,
> która reaguje na przerwanie wątku z zewnątrz (Thread.interrupt).
> Stąd możliwość InterruptedException.

Super! Tylko po jasną cholerę mam w związku z tym deklarować propagację przez
wszystkie możliwe funkcje?

> Nie należy pisać tak jak napisałeś (połykać InterruptedException).
> http://www-128.ibm.com/developerworks/java/library/j-jtp05236.html

Dla mnie ideałem byłoby, gdyby w funkcji głównej wątku, lub w funkcji
startującej aplikację (bo wątek przerywalny to również wątek główny,
startujący aplikację) można było objąć cały kod trajem, jeśli trzeba jakoś
specjalnie zareagować na nakaz zakończenia.

Oczywiście prawda jest też taka, że gdybym miał C++ z biblioteką wątków i taki
wątek byłby kończony za pomocą rzucenia wyjątku, to nie musiałbym właściwie
(teoretycznie) robić niczego, nic się nawet nie stanie jak nie przechwycę
wątku w ogóle. Wszystko mi zrobią destruktory.

Natomiast w takiej np. Javie być może istnieje potrzeba przechwycenia tego
wyjątku gdzieś w środku, żeby po prostu wykonało się odpowiednie finally. Co
jest właściwie tożsame z wywołaniem destruktora w C++, tyle że w Javie trzeba
to zrobić ręcznie.

Oddzielną sprawą jest jednak sensowność kończenia wątku wyjątkiem. Ja sobie
ten wyjątek mogę gdzieś w środku przechwycić. Jak nie przemierzając w podanym
przykładzie. Wypadałoby ten wyjątek spropagować, ewentualnie na odpowiednim
poziomie zakończyć wątek. Jak biblioteka wątków chciałaby mnie zmusić do tego,
żeby nie "przechwytywać wyjątku na daremno"?

> Pewnym odpowiednikiem tego w SUS są funkcje, które są przerywane przez
> pthread_cancel w stanie PTHREAD_CANCEL_DEFERRED + PTHREAD_CANCEL_ENABLE
> (domyślnym zresztą):
> http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_09.html#tag_02_09_05_02

> Jedno i drugie jest raczej sztuczką niż porządnym projektem językowym.

Nie do końca.

> Ponieważ te języki nie dostarczają mechanizmów pozwalających
> programiście informować, w których momentach można przerwać wątek,
> domyślnie zakłada się, że można to zrobić wtedy, kiedy wątek na coś
> czeka (ale nie na mutex). Bo po pierwsze jest szansa, że takie momenty
> będą zdarzały się wystarczająco często, a po drugie jest szansa, że
> wszelkie niezmienniki globalnych struktur danych będą wtedy zachowane.

Zgadza się, ale w stan sleep można wprowadzić wątek nie tylko wywołując sleep
(mówię w sensie systemowo-ogólnym), ale również w stanie oczekiwania na I/O.
Tymczasem w Javie InterruptedException jest rzucane tylko przez Thread.sleep i
Object.wait. InputStream.read przykładowo rzuca tylko IOException!

> Różnica między Javą a Uniksem polega w tym miejscu na tym, że Java
> zmusza programistów do zauważenia, że dana funkcja jest przerywalna,
> a Unix nie.

Super - tylko skoro wątek może być przerwany tylko przez InterruptedException,
to w jaki sposób następuje "killowanie" wątku javowego? Jeśli nikt nie używa
żadnego sleep() w środku, to wątku nie można przerwać w ogóle? A jeśli można,
to jak się to odbywa?

> W połączeniu ze sprawą odśmiecania powoduje to, że
> w Uniksowym C/C++ pthread_cancel ma małe szanse poprawnego działania.
> Większość programistów nawet nie wie, że taka funkcja istnieje, i nie
> pisze kodu tak żeby działał poprawnie w obliczu asynchronicznych
> przerwań.

Jeśli mówimy o GNU pthreads i GCC/C++ to podobno działają poprawnie, bo
używany jest w pthread_cancel ten sam mechanizm, co w wyjątkach w C++.

> Zgadzam się, że checked exceptions powodują z reguły więcej kłopotu niż
> pożytku, ale z tego nie wynika, że jest w nic samo zło.

Jest wystarczająco dużo tego zła, żeby stwierdzić, że ten ficzer jest porażką.

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

> Gdyby mógł wystąpić w zupełnie dowolnym momencie, to nie dałoby się
> pisać poprawnego kodu, bo np. nie da się zagwarantować, że z pewnych
> dwóch instrukcji wykonają się obie albo żadna.

Oj, nie rozumiem, niby dlaczego. Jeśli wykonuję a + b + c, a drugi plus rzuci
wyjątkiem (bo akurat ktoś stwierdził, że sprzeda procesowi killa), to jaki
problem tu może wystąpić?

W C++ mógłby ci tutaj wystąpić problem ze wskaźnikami i nowo utworzonymi
obiektami. No, jeśli chciałbyś mieć 100% exception-safe kod, to należałoby
używać wyłącznie auto_ptr do przechowywania tymczasowej wartości wskaźnika na
obiekt. Chyba że w danej funkcji panuje taka zasada, że w razie wyjątku i tak
kończymy aplikację (i masz pewność, że system zwolni wszystkie zasoby
przydzielone przez proces).

Trochę inna sprawa występuje w przypadku, gdyby chcieć wspierać semantykę
wznowienia - ale właśnie wspomniałem o tym, że semantyka wznowienia powinna
być maksymalnie utrudniona. Na przykład tak, że każda funkcja systemowa
(jakimś sposobem) rzuca wyjątkiem za każdym wywołaniem, jeśli proces już raz
dostał killa.

> Należy umożliwić wątkowi blokowanie przerywania

Nie. Należy umożliwić wątkowi sprzątanie istniejących zasobów w razie
przerwania, natomiast na pewno nie odkładanie reakcji na przerwanie ad
calendas graecas.

> oraz zintegrować
> automatyczne blokowanie z innymi konstrukcjami języka (większość
> programistów nie myśli o możliwości przerwania wątku i tego nie
> zmienimy). Jeśli się postarać, jeśli język ma szansę rozpoznać
> regiony, które muszą się wykonać w całości, w sposób niewymagający
> od programisty dużego zachodu, to można domyślnie dopuścić przerywanie
> w dowolnym momencie.

Tak - a to z kolei wymaga oznaczenia obszarów, na terenie których następuje
niestabilność stanu aplikacji.

Ale wtedy można bez problemu przerwać to wyjątkiem.

> Przy czym w C++ nie ma na to szans, bo jest zdecydowanie zbyt wiele
> miejsc, których nie można przerwać, ale nie ma jak ich automatycznie
> rozpoznać. Na przykład region między new a przypisaniem gołego wskaźnika
> do sprytnego wskaźnika nie może być przerywalny (przynajmniej przy
> standardowym alokatorze).

Moment - o ile ja znam C++, to przerwanie przez wyjątek może nastąpić tylko w
dwóch miejscach: w operatorze new (wtedy pamięć jest automatycznie usuwana)
lub po przypisaniu (zakładamy, że w trakcie przypisywania nie wystąpi).

Jeśli przerywamy wątek wyjątkiem, to tak powinno to działać. Ale nie mam
pomysłu, jak to zorganizować.

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

> Uważasz, że lepiej wprowadzać sztuczne utrudnienia w używaniu wątków,
> żeby zniechęcać do nich programistę?

Uważam, że należy wspierać alternatywne rozwiązania i wskazywać ich zalety.

I nie doradzać wątków do wszelkiej równoległej pracy, lecz właśnie wskazywać,
dlaczego one się do równoległej pracy na jednym obiekcie nie nadają.


-- 
//  _    ___         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"

Seweryn Habdank-Wojewódzki wrote:
>>>>a w razie czego podstawienie zamiast niej czegoś
>>>>własnego nie wpływa mi na miejsca użycia.
>>>
>>>A niby z czym w C++ masz problemy?
>>
>>W C++ niby uniwersalne kontenery uniwersalne nie są, w miarę uniwersalność
>>kończy się na vector i deque oraz map i multimap.
> 
> No i?

No i kiepsko.

>>>Wieź mi tu nie zalatuj przykładami kodu powstałymi w czasie kiedy Python
>>>był co najwyżej w umyśle GvR.
>>
>>Języki bezpieczne znane są od ponad 45 lat. Języki w których nie ma
>>podstawoych dziur w systemie typów były popularne już blisko 40 lat temu
>>sic(!).
> 
> Tak i gdyby wtedy informatyka bazowała tylko na nich to do dziś byśmy mieli
> tylko maszyny do pisania. Niebezpieczne języki pozwoliły wejść na orbitę
> szybkości.

Nonsens. Wiele innych kompilowanych języków by się nadawało.


> A gdyby nie te niebezpieczne języki, to dziś nie miałbyś tych
> niby lepszych bezpiecznych języków nowej generacji. Python w ogóle by nie
> istniał, bo jego reference implementation stoi po pachy w C.

Mogłoby równie dobrze stać w innym języku kompilowanym, hgdyby to ten język 
był językiem API OS.


>>>>>>>No więc w C++ będziesz miał smart_ptr, na razie są one w boost (i nie
>>>>>>>tylko np. g++ ma już w sobie mocną wersję tr1).
>>>>>>
>>>>>>Tyle że wbrew zasadzie you don't pay for what you don't use, w każdym
>>>>>>użyciu zapłacę za sychronizację wątkową choć 95% wskazywanych obiektów
>>>>>>nigdy pomiędzy wątkami nie będzie przekazywane.
>>>>>
>>>>>Jak masz taki projekt to tak.
>>>>
>>>>To jest sytuacja jak najbardziej typowa.
>>>
>>>Nie wiedzę o czym mówisz. W kodzie shared_ptr z boosta nie widzę żadnej
>>>synchronizacji, więc nie wiem o czym mówisz.
>>
>>Boszsz... Spytaj Piotra Wyderskiego, to ci powie. On robił to np. dla
>>SPARCA.
>>
>>Oczywiście że synchronizacja jest -- użycie operacji atomowych to myślisz
>>że co to jest? I czemu jest o 2 rzędy wielkości sic(!) wolniejsze od
>>normalnego dostępu do pamięci.
> 
> O tak? A czy Piotr nie wspomniał, że w wersji MT?

W paru kompilatorach nie maż wersji nie MT. Albo biblioteki których używasz 
są skompilowane w wersji MT i już -- bo w normalnej sytuacji to ma koszt 
przyzerowy a nie ma kłopotów jak ktoś włączy drugi wątek.


> 
> I czy nie możesz mieć swojej banalnej implementacji bez tej synchronizacji?

Zrób to sam(tm) -- mantra C++.

Poprawne zaimplementowanie tego nie jest takie banalne (choćby poprawny 
interfejs samego sprytnego wskaźnika, choć takie rzeczy jak konwersja 
pozwalająca w warunku logicznym czy pointer jest not null)

> Tak na marginesie nie wspomniałeś, że języki te lepsze to są natkane
> synchronizacją synchronizacji a w nich też są synchronizacje. Które są nie
> używane w 95% procentach, czyż nie?

Są, albo nie są natkane. Wbudfowane w język GC np. realizuje się bez 
synchronizacji każdego przypisania na wskaźnik. W Takim Pythonie GIL nie 
włącza i wyłącza się co instrukcję -- tylko gdy wołana jest ciężka rzecz 
(np. funkcja systemowa).


>>Ada to jest rzecz całkem nowa i młoda w porównianiu do paru innych
>>języków.
> 
> Ale ja nie słyszę o tych jezykach, nie widzę ofert pracy, nie widzę
> projektów (a już w mojej działce to w ogóle). Proszę oświeć mnie, bedę
> wdzięczny.

Ludzie jedzcie guano! Miliardy much nie mogą się mylić!


>>>A jednak Ty go wychwalasz. Jakaś sprzeczność.
>>
>>Ja go specjalnie nie wychwalam. Po prostu stwierdzam fakt. Różne inne
>>języki nieudolnie naśladują rozwiązania w Lispie znane od 30 lat.
> 
> No naśladują i co z tego? Python też niby jest ten tego ten trochę
> funkcyjny. Mnie się to trochę podoba, a Ci co są "zboczeni" powiedzą, że to
> jest kicha i dziadostwo.

Python ma kilka lekkich wtrętów funkcyjnych. Ale AFAIR nie ma choćby 
rozwijania rekursji ogonowej (a w każdym razie na to gwarancji) więc kod w 
sytlu funkcyjnym, bez pętli, w Pythonie leży conajmniej źle.

>>W Pythonie włąsny kontener zrobię łatwiej i wygodniej niż w C++.
> 
> I jest równie wydajny i zajmuje równie mało ramu, co?

Python jakoś duuużo nie żre (zwykle mniej niż Java). Włącz sobie Psyco i 
porównaj.


>>>I tak wolę C++ rozwiązania, bo są bardziej
>>>dedykowane -- w zakresie swojego użycia są szybsze i mniej zajmują ramu.
>>
>>Są kiepskie. Sztywne i równocześnie nadmiernie skomplikowane. I
>>niewiedzieć czemu ponazywali różne rzeczy inaczej niż reszta świata.
> 
> Co np?

np. owo nieszczęsne map (co to nie ma już dictionary?) czy nawet vector 
(zamiast array czy dyn_array czy dynamic_array).

Nie mówiąc już o "super wygodnym" wykonywaniu takich dupereli jak 
sprawdzenie czy w mapie jest dany klucz.


>>>>Traci czas na duperele, takie jak synchronizacja shared_ptr której nie
>>>>użyję w 95% wypadków.
>>>
>>>
>>>Tak. Wiem. A synchronizacje w Pythonie nie istnieją -- podobno to jest
>>>bezpieczny język?
>>
>>Istnieją.
> 
> No więc właśnie one SĄ jest dzikie mnóstwo i często nie są w ogóle
> wykorzystane, chyba że GC generuje jakiś nadmierny ruch.

No włąsnie nie ma dziekiego mnóstwa. W zasadzie jest jedna :) i wołana 
nieczęsto :)


>>>A w ogóle pokaż mi te synchronizacje w kodzie
>>>boost::shared_ptr.
>>
>>Seweryn, a jak myślisz, jakim cudem to działa w wielu wątkach?
> 
> Działa na wielu wątkach, a ja myślałem, że C++ nie wpiera wątków?

Jego implementacje wspierają -- inaczej nie nadawałby się w ogóle do użycia.

> Ile lat potrzebujesz aby napisać (skopiować) swojego shared_ptr, bez tej
> nieszczęsnej synchronizacji? 

Czytać kod boosta? Dziękuję, postoję.

> A ja i tak nie widzę gdzie w pliku boost/shared_ptr.hpp jest synchronizacja,
> poproszę o pomoc publiczności.

Publiczność (w osobie Piotra Wyderskiego) już pomogła :)


> C++0x ma wspomniane tak, że czytanie jest nie blokowane, tylko zmiany są
> blokowane. Rozdział 2.11 Peter Becker  C++ STL Extensions + dyskusje na
> boost. Ale To jest TR1, możesz użyć nie synchronizowanego również.
> 
> Zresztą, nie kapuję Twojego płaczu, kiedyś płakałeś, że nic nie jest
> synchronizowane, teraz płączesz, że tr1::shared_ptr jest synchronizowany.
> Nie rozumiem o co chodzi?

Dziecko wylane z kompielą?


>>>>>Np. po co w aplikacji jednowątkowej mieć synchronizację wątków?
>>>>>Albo mając aplikację wielowątkową widząc gdzie się one spotykają
>>>>>synchronizujesz dokładnie to co jest wspólne i w sposób najbardziej
>>>>>odpowiedni.
>>>>
>>>>Nie mam takiej możlwości ani w przypadku wbudowanego new i delete ani w
>>>>przypadku shared_ptr, itd...
>>>
>>>Pokaż mi odpowiedniki w Pythonie.
>>
>>Każda refeferencja do obiektu jest odpowiednikiem (bardzo bliskim!)
>>shared_ptr.
> 
> I jak myślisz czy tam jest synchronizacja?

Nie ma:)
Jest w lepszym miejscu :)


>>Haskell jest starannie przemyślany i ma ogromną wyrażalność. Szablony nie
>>są ani przemyślane anie nie da się w nich sensownie wyrazić żadnej
>>konkretnej złożoności -- trzeba stanąć na głowie żeby zrealizować zwykły
>>warunek.
>>
>>Szablony były zresztą (czasami panicznie) łatane. Stąd takie dziwności jak
>>Koenig lookup, SFiNaE itd.
> 
> Z czego SFINAE przynosi korzyści.

Tricki i nieczytelny kod.

[...]
>>Tanie rozwiązanie polega na jak najszybszym powiadomieniu twórców o
>>błędzie i w miarę możliwości automatycznym uruchomieniu opcji zapasowej
>>(np. restart instanji aplikacji, jeśli jest odpowiednio zaprojektowana to
>>np. bez utraty kontekstu)
> 
> No i? Przykładem takich wymagań są bazy danych. Nie widzę żadnej napisanej w
> językach lepszych. Większość jest pisana w C/C++. Relacyjne zazwyczaj w C,
> obiektowe mieszają C i C++.

Rozumiem że mowa o DBE (DataBase engines). Większość jest pisana po prostu w 
języku systemowym. Coś co dla poperawnego działania wymaga niebuforowanego 
dostępu do dysku, kontroli procesów (tego co ginie co nie) itd pisze sie 
raczej w języku systemowym.


>>Jeśli już, to właśnie C++ z jego UB i heisenbugami to jest jakość dysnontu
>>zpożywczego.
> 
> A zyskiem jest wydajność? Hę? Nie ma nic za darmo dobrze o tym wiesz.

Wydajność przez te całe UB itp jest dziś tracona(!).

Np. bezpieczniejszy od C/C++ fortran często lepiej się optymalizuje, bo on 
może zagwarantować np. takei rzeczy że nie ma aliasingu.


>>>>C++ to taki samochód, co przy pierwszej drobnej awarii traci hamulce,
>>>>kierownica się blokuje a na kierowcę leci gorący olej i borygo.
>>>
>>>Tak. To bardzo dobry język, bo low-quality koderzy dostają ciężkie baty.
>>
>>Klient ma gdzieś, czy koder dostał baty czy ucieło mu głowę czy co innego.
>>Klient nie ma zamiaru bycia oblanym olejem i borygo.
> 
> 
> O tak! Klient nie używa bazydanych innej niż napisanej w C/C++. Klient
> płacze jak mu okienka wolno działają, już o grach nie wspomnę.
> Pokaż mi w czym są napisane najpopularniejsze programy jak nie w C/C++?
> Jest oczywiście cała masa softu w J, jako frontendy do baz danych
> (napisanych w tych kulawych językach).

Znam dużo popularnego softu nie w C++. Działa. Dobrze działa. I nie umiera 
od czasu do czasu z informacją że jakiś generał Protection się pomylił (soft 
pisany przez wojsko ;) ?). Np. taki Jedit, czy Eclipse, czy parę dobrych 
webserwerów.


>>A może to to że gawiedź pisząca PHP to właśnie, w znacznej większości,
>>gawiedź a nie specjaliści. 
> 
> Ale wśród języków bezpiecznych takiej gawiedzi jest masa, bo oni czują się
> tam bezpiecznie.

Tak samo tego jest pełno w C a nawet assemblerze.


[... duże ciach gdzie się zgadzam ...]

pzdr
\SK

Sebastian Kaliszewski wrote:
> Python ma kilka lekkich wtrętów funkcyjnych. Ale AFAIR nie ma choćby 
> rozwijania rekursji ogonowej (a w każdym razie na to gwarancji) więc kod w 
> sytlu funkcyjnym, bez pętli, w Pythonie leży conajmniej źle.

Bo taka jest decyzja projektantów, żeby nie robić tego typu
optymalizacji.  Ale jest już dekorator do tail-recursion:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/474088

w.

Witam

Sektor van Skijlen wrote:

> Dnia Thu, 22 Nov 2007 10:30:59 +0100, Seweryn Habdank-Wojewódzki skrobie:
>> Witam
> 
>> Sektor van Skijlen wrote:
> 
>> > Nadużywa się ich, zamiast zrobić to samo
>> > na włóknach.
> 
>> Co to jest włókno?
> 
> Coś w stylu wątków, które nie wykonują się równolegle, tylko etapami
> z ręcznym przełączaniem.

Dzięki. Już się tym nieco pobawiłem w Linuxie. Trochę nisko poziomowe, ale
ma całkiem miły determinizm przełączeń. 

Ciekawe, czy dałoby się takim czymś unikać "race conditions"?

Pozdrawiam. 

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Witam

Sebastian Kaliszewski wrote:

>>>>Wieź mi tu nie zalatuj przykładami kodu powstałymi w czasie kiedy Python
>>>>był co najwyżej w umyśle GvR.
>>>
>>>Języki bezpieczne znane są od ponad 45 lat. Języki w których nie ma
>>>podstawoych dziur w systemie typów były popularne już blisko 40 lat temu
>>>sic(!).
>> 
>> Tak i gdyby wtedy informatyka bazowała tylko na nich to do dziś byśmy
>> mieli tylko maszyny do pisania. Niebezpieczne języki pozwoliły wejść na
>> orbitę szybkości.
> 
> Nonsens. Wiele innych kompilowanych języków by się nadawało.

Ale się nie nadały. Przykro mi. Naprawdę. Wiem jak to jest kiedy produkty
bardzo dobrej jakości przegrywają z produktami marki "dyskont".
Trzeba jednak żyć w takiej a nie innej rzeczywistości i starać się robić
najlepiej jak się da, ale tak, aby dało się jakoś sprzedać np. w postaci
projektu naukowego lub produktu dla klientów wymagających jakości. Jednak
odnoszę wrażeni, że języki, które kiedyś były rewelacyjne, były jak poezja
Norwida, niedoceniane i poszły w odstawkę. W przyszłości się do nich wróci,
aczkolwiek obserwuje trywializację. Np. Sun odgrzebuje starocie nadając im
nowe nazwy, ale nie poprawia niczego, tylko psuje i rzutuje na Javę, co MHO
źle się skończy (patrz projekty Scala i Fortress).
 
>> A gdyby nie te niebezpieczne języki, to dziś nie miałbyś tych
>> niby lepszych bezpiecznych języków nowej generacji. Python w ogóle by nie
>> istniał, bo jego reference implementation stoi po pachy w C.
> 
> Mogłoby równie dobrze stać w innym języku kompilowanym, hgdyby to ten
> język był językiem API OS.

No ale niestety API OS są paskudnie C-owate :-). Coś się tam Java wychyla
poprawiając Pana Boga -- nieudolnie naśladując Unix'a. Ale nie ma to w
ogóle porównania wydajnościowego, chociaż jak mnie ktoś uświadomił na
WallStreet zapłacą za dowolną liczbę komputerów więc ich przebicie 10 razy
liczba maszyn w stosunku do Unixa nie boli, do póki nie dojdą do zagadnień,
kiedy komunikacja stanie się ciężarem.
 
>> O tak? A czy Piotr nie wspomniał, że w wersji MT?
> 
> W paru kompilatorach nie maż wersji nie MT. Albo biblioteki których
> używasz są skompilowane w wersji MT i już -- bo w normalnej sytuacji to ma
> koszt przyzerowy a nie ma kłopotów jak ktoś włączy drugi wątek.

OK. Wyślę Ci kod shared_ptr wyciągnięty z Linuxa programem bcp. Będziesz
miał wersję ST, chcesz?
 
>> I czy nie możesz mieć swojej banalnej implementacji bez tej
>> synchronizacji?
> 
> Zrób to sam(tm) -- mantra C++.

Wyślę Ci.
 
>> Ale ja nie słyszę o tych jezykach, nie widzę ofert pracy, nie widzę
>> projektów (a już w mojej działce to w ogóle). Proszę oświeć mnie, bedę
>> wdzięczny.
> 
> Ludzie jedzcie guano! Miliardy much nie mogą się mylić!

Sebastian. Wszystko jest dobrze. Rozumiem Twoje dążenie do ideału. Kłopot
polega np. na tym, że do super języków nie ma ekip koderskich.

Lokalnie tutaj możemy uznać że Kogut jest jednym z bliskich ideałowi.
OK. załóżmy, że go umiemy. I teraz biorę ten język i mówię obcej kompanii
"chłopaki od dziś piszemy w Kogucie". Co oni na to? 

Co manago finansowy na to? Kiedyś ktoś mi powiedział, że manago nie może
zmuszać ludzi do nauki języka, bo oni za chwilę przyjdą po podwyżkę. 

Znajomość i nauka drugiego trzeciego, k-tego języka musi wyjść od ludzi
samych, bo wtedy finansista nie przylatuje z wrzaskiem, że za duże koszty
są generowane. Jego nie obchodzi to, że ekipa znająca dziś jeden język
jutro 3, dziś i jutro przyniesie stratę 100%, pojutrze zysk 500%. 
Manago finansowy patrzy, aby jemu kichany Annual Turnover się poprawiał, bo
ma w planie na koniec roku prezentację i tam wykres musi iść do góry.

Teraz mi powiedz jaki wybierasz język, aby jednak ekipa coś więcej
potrafiła. Przede wszystkim taki, który jest znany, bądź poznawalny kosztem
hobby. Zatem muszą to być języki nie tyle idealne, co języki mające taki a
nie inny support. Szybko okazuje się, że nawet jeśli ja znam Koguta, to mój
qmpel nie całkiem i ma problemy z poznaniem. Tak więc szybko topnieje
liczba ideałów, które mogą być używane w ekipie koderskiej. Do tego
dochodzą listy dyskusyjne tutki itd. Jakbyś nie patrzył, na grupach o C,
++, J, Py, jest spory ruch a takiego Lispa nie widzę. Jest oczywiście
grupa "funkcyjna", ale tam ruch jest mały, żeby nie powiedzieć znikomy.
 
> Python ma kilka lekkich wtrętów funkcyjnych. Ale AFAIR nie ma choćby
> rozwijania rekursji ogonowej (a w każdym razie na to gwarancji) więc kod w
> sytlu funkcyjnym, bez pętli, w Pythonie leży conajmniej źle.

Nie bądźmy purytańscy. Nie chodzi o pisanie tak samo, chodzi o możliwość
przeniesienia abstrakcji myślowej.
 
>>>W Pythonie włąsny kontener zrobię łatwiej i wygodniej niż w C++.
>> 
>> I jest równie wydajny i zajmuje równie mało ramu, co?
> 
> Python jakoś duuużo nie żre (zwykle mniej niż Java). Włącz sobie Psyco i
> porównaj.

Włączam i porównuje. Zresztą na grupie z Py, jeden kolo wyleciał, że mu Ru,
czy Perl lepiej działają. A ja sprawdziłem z Psyco i mi wyszło w Py
najlepiej. Ale Psyco ma wadę, nie hula na 64-bit w pełnej krasie, co w
sytuacji pisania kodu dla serwerów jest dziś niemiłe.
 
> np. owo nieszczęsne map (co to nie ma już dictionary?) czy nawet vector
> (zamiast array czy dyn_array czy dynamic_array).

Znaczy się, co? Nazwy Ci przeszkadzają?
 
> Nie mówiąc już o "super wygodnym" wykonywaniu takich dupereli jak
> sprawdzenie czy w mapie jest dany klucz.

map::count(klucz)?
 
>> Ile lat potrzebujesz aby napisać (skopiować) swojego shared_ptr, bez tej
>> nieszczęsnej synchronizacji?
> 
> Czytać kod boosta? Dziękuję, postoję.

Po co czytać, chociaż ja czytam. Użyj bcp i już.
 
>> A ja i tak nie widzę gdzie w pliku boost/shared_ptr.hpp jest
>> synchronizacja, poproszę o pomoc publiczności.
> 
> Publiczność (w osobie Piotra Wyderskiego) już pomogła :)

Z całym szacunkiem Piotr wskazał kod dla SPARKA. Wskarzę dla mojego marnego
Athlona na Linuxie i tam nie ma synchronizacji. Nawet pofatygowałem się,
aby przeglądnąć powstały asm i są używane tylko normalne komendy.
 
>> Zresztą, nie kapuję Twojego płaczu, kiedyś płakałeś, że nic nie jest
>> synchronizowane, teraz płączesz, że tr1::shared_ptr jest synchronizowany.
>> Nie rozumiem o co chodzi?
> 
> Dziecko wylane z kompielą?

Rozumiem. Ja nie wylewam dzieci, mogę Ci przesłać tego shared_ptr bez
synchronizacji.
 
> Nie ma:)
> Jest w lepszym miejscu :)

Dla mnie z mojego punktu widzenia wydajności nie ma znaczenia gdzie ona jest
jeśli jest.

>>>Haskell jest starannie przemyślany i ma ogromną wyrażalność. Szablony nie
>>>są ani przemyślane anie nie da się w nich sensownie wyrazić żadnej
>>>konkretnej złożoności -- trzeba stanąć na głowie żeby zrealizować zwykły
>>>warunek.
>>>
>>>Szablony były zresztą (czasami panicznie) łatane. Stąd takie dziwności
>>>jak Koenig lookup, SFiNaE itd.
>> 
>> Z czego SFINAE przynosi korzyści.
> 
> Tricki i nieczytelny kod.

:-D

To samo na razie myślę o Haskellu. Ale planuję to zmienić.
 
> Rozumiem że mowa o DBE (DataBase engines). Większość jest pisana po prostu
> w języku systemowym. Coś co dla poperawnego działania wymaga
> niebuforowanego dostępu do dysku, kontroli procesów (tego co ginie co nie)
> itd pisze sie raczej w języku systemowym.

A systemy czemu są pisane w paskudnych językach?
 
> Np. bezpieczniejszy od C/C++ fortran często lepiej się optymalizuje, bo on
> może zagwarantować np. takei rzeczy że nie ma aliasingu.

No i? Mój braciszek jakieś pół roku temu przepisywał kod fortrana na C, bo
już nie miał kto tego (fortrana) pilnować -- jemu przyszła brudna robota,
aby nowe nie fortranowe pokolenie cos kapowało. Zresztą, jak przepisał to
na C, to kompania, za wrapowała kod w C# i teraz mają dwa poziomy "of
understanding" -- 1. Ci co kojarzą C i C# i ci co tylko *jarzą* C#.
 
> Znam dużo popularnego softu nie w C++. Działa. Dobrze działa. I nie umiera
> od czasu do czasu z informacją że jakiś generał Protection się pomylił
> (soft pisany przez wojsko ;) ?). Np. taki Jedit, czy Eclipse, czy parę
> dobrych webserwerów.

O tak. Nawet w KDE klikam na ikonę KDevelop i program się otwiera. Klikam na
Eclipse i czekam i czekam ... idę po napój ... wracam jest. Z Netbeansami
jest jeszcze gorzej. A ram? Mam 1.5GB i o jak strasznie mało dla tego
Eclipse/Netbeans. Muszę kupić sobie więcej. W ogóle mam kiepskie komputery,
musze kupić lepsze. 

Szkoda tylko, że kiedy napiszę ten sam program obliczeniowy w C/C++ w stylu
dla "Unixa" i to samo w J. to wersja paskudniaczkowa zjada mniej ramu i
jest szybsza. 

Albo co jest często lepsze. Mogę połknąć tyle samo ramu, ale mam w pamięci
więcej danych, co np w dataminingu jest korzystniejsze. Zatem wolę
mieć "Unix" + C/C++ niż J.

Oczywiście piszę o swoim stanowisku, bo algorytmy jako takie nie mają
ŻADNEGO wsparcia w językach, więc gadanie, że w J ma to czy tamto w klasach
wbudowanych jest dla mnie o picowaniem. Mam worek danych ma algorytm i
mielę i wypluwam wyniki. Albo wersja RT, mielę i wypluwam wyniki on-line, a
jakiś zewnętrzny obserwator pobiera jest sobie przez ustalony interfejs
komunikacyjny.

A co do webserwerów w J -- nic mi o nich nie mów. Już pisałem że np. EJB
przy Plone to jak asembler przy C++.

>>>A może to to że gawiedź pisząca PHP to właśnie, w znacznej większości,
>>>gawiedź a nie specjaliści.
>> 
>> Ale wśród języków bezpiecznych takiej gawiedzi jest masa, bo oni czują
>> się tam bezpiecznie.
> 
> Tak samo tego jest pełno w C a nawet assemblerze.

Oczywiście, że tak. W szczególności, co mnie irytuje, C Legacy People (tm), 
którzy twierdzą, że umieją C++.
 
> [... duże ciach gdzie się zgadzam ...]

Cieszę się, że mamy jakieś punkty zgodności :-D.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/

Dnia Fri, 23 Nov 2007 15:40:39 +0100, Sebastian Kaliszewski skrobie:
> >>>>C++ to taki samochód, co przy pierwszej drobnej awarii traci hamulce,
> >>>>kierownica się blokuje a na kierowcę leci gorący olej i borygo.
> >>>
> >>>Tak. To bardzo dobry język, bo low-quality koderzy dostają ciężkie baty.
> >>
> >>Klient ma gdzieś, czy koder dostał baty czy ucieło mu głowę czy co innego.
> >>Klient nie ma zamiaru bycia oblanym olejem i borygo.
> > 
> > 
> > O tak! Klient nie używa bazydanych innej niż napisanej w C/C++. Klient
> > płacze jak mu okienka wolno działają, już o grach nie wspomnę.
> > Pokaż mi w czym są napisane najpopularniejsze programy jak nie w C/C++?
> > Jest oczywiście cała masa softu w J, jako frontendy do baz danych
> > (napisanych w tych kulawych językach).

> Znam dużo popularnego softu nie w C++. Działa. Dobrze działa. I nie umiera 
> od czasu do czasu z informacją że jakiś generał Protection się pomylił (soft 
> pisany przez wojsko ;) ?). Np. taki Jedit, czy Eclipse, czy parę dobrych 
> webserwerów.

Jedit to jest twoim zdaniem "popularny soft"? Chyba jaja sobie robisz.

A Eclipse... cóż.

Na moim służbowym laptoku mam 2G ramu. Najczęściej mam odpaloną Operę, jeszcze
jakąś przeglądarkę MSIE-based, Outlooka (bo pocztę trzeba widzieć na bieżąco)
no i ostatnio również Eclipse'a.

Przy uruchomionych tych wszystkich aplikacjach (bo reszta to zużywa nieistotną
ilość pamięci) zajętość pamięci oscyluje wokół 1.22GB.

Przy uruchomieniu dowolnego dodatkowgo programu w Javie spod Eclipse'a
(Tomcat, Maven) komputer doznaje spowolnienia tak na oko do poziomu 386. Po
dłuższym czasie używania w ten spsób Eclipse'a (wystarczą 4h) zaczynają się
robić różne dziwne rzeczy typu:
 - Błędy odświeżania GUI
 - Eclipse robi wylot z komunikatem, że nastąpił błąd i aplikacja zostanie
   zakończona
 - Eclipse zgłasza jakiś poważny problem z ilością pamięci i... nie daje się
   zamknąć (nie reaguje ani na krzyżyk, ani na File/Exit, choć poza tym działa
   zupełnie normalnie)

Nie mów mi nic nigdy pozytywnego o Eclipsie, bo dla mnie to straszne gówno
jest. Już nawet MSVC 5.0 chodził o niebo stabilniej.


-- 
//  _    ___         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"

Dnia Fri, 23 Nov 2007 22:29:27 +0100, Seweryn Habdank-Wojewódzki skrobie:
> Witam

> Sektor van Skijlen wrote:

> > Dnia Thu, 22 Nov 2007 10:30:59 +0100, Seweryn Habdank-Wojewódzki skrobie:
> >> Witam
> > 
> >> Sektor van Skijlen wrote:
> > 
> >> > Nadużywa się ich, zamiast zrobić to samo
> >> > na włóknach.
> > 
> >> Co to jest włókno?
> > 
> > Coś w stylu wątków, które nie wykonują się równolegle, tylko etapami
> > z ręcznym przełączaniem.

> Dzięki. Już się tym nieco pobawiłem w Linuxie. Trochę nisko poziomowe, ale
> ma całkiem miły determinizm przełączeń. 

> Ciekawe, czy dałoby się takim czymś unikać "race conditions"?

Oczywiście. Wątki symulują "równoczesność dostepu", niestety zapominając o
tym, że akurat równoczesność dostępu to jest najgorszy możliwy sposób
zarządzania wspólnym zasobem. Włókna nie ukrywają nawet, że ten dostęp jest
"po kolei", a nie równoczesny.

Z race conditions akurat można sobie radzić właśnie w ten sposób, że w cyklu
wykonywania dane włókno ma się do zasobu dobrać, wykonać operację i odstąpić
od zasobu. Albo w ogóle się do tego zasobu nie dobierać, jeśli akurat nie ma
potrzeby. W obu sytuacjach nie ma możliwości "wstrzelenia się" jednego w
drugie.


-- 
//  _    ___         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"

Sektor van Skijlen wrote:

>> Znam dużo popularnego softu nie w C++. Działa. Dobrze działa. I nie
>> umiera od czasu do czasu z informacją że jakiś generał Protection się
>> pomylił (soft pisany przez wojsko ;) ?). Np. taki Jedit, czy Eclipse, czy
>> parę dobrych webserwerów.
> 
> Jedit to jest twoim zdaniem "popularny soft"? Chyba jaja sobie robisz.
> 
> A Eclipse... cóż.
> 
> Na moim służbowym laptoku mam 2G ramu. Najczęściej mam odpaloną Operę,
> jeszcze jakąś przeglądarkę MSIE-based, Outlooka (bo pocztę trzeba widzieć
> na bieżąco) no i ostatnio również Eclipse'a.

SOA#1.

Ale ja uzywam Eclipse pod linuksem "tylko" w polaczeniu z CDT. Na laptopie
mam 1G ramu i eclise nie zuzywa wiecej niz 300MB. Ale projekt tez nie jest
najwiekszy. 16000 plikow w 70MB

-- 
Michal Schulz

Dnia Fri, 23 Nov 2007 23:50:30 +0100, Marcin ?Qrczak? Kowalczyk skrobie:
> Dnia 23-11-2007, Pt o godzinie 14:13 +0000, Sektor van Skijlen pisze:

> > Ciekaw jestem swoją drogą, czy nie kończy się to czasem tym, że programiści
> > wkurzeni koniecznością definiowania propagacji po prostu każą się wątkowi
> > ukryć "pod osią ciężarówki RuntimeException".

> Od Javy 1.4 klasa Throwable ma atrybut cause, typu również Throwable.
> A więc każdy wyjątek ma miejsce na opcjonalny inny wyjątek, który był
> jego przyczyną. Istnieje kanoniczny sposób na owinięcie dowolnego
> wyjątku w RuntimeException (a także w dowolny inny wyjątek, który
> umiemy skonstruować):

>    new RuntimeException(exn)

> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html

> Nie używam Javy, ale mogę się domyślać, że owijanie i odwijanie wyjątków
> pochodzących z różnych warstw abstrakcji (niższych w wyższe) jest typowe.

Ja już to zauważyłem, ale dopiero teraz zdałem sobie sprawę, że jest to sposób
na obejście ścisłych wyjątków.

> > Zgadza się, ale w stan sleep można wprowadzić wątek nie tylko wywołując sleep
> > (mówię w sensie systemowo-ogólnym), ale również w stanie oczekiwania na I/O.
> > Tymczasem w Javie InterruptedException jest rzucane tylko przez Thread.sleep
> > i Object.wait. InputStream.read przykładowo rzuca tylko IOException!

> Zauważyłem. Za to od Javy 1.4 jest interfejs InterruptibleChannel.
> Operacje wejścia-wyjścia na takim strumieniu reagują na Thread.interrupt
> zamknięciem strumienia i rzuceniem wyjątku ClosedByInterruptException
> (a nie InterruptedException). Chyba wszystkie klasy strumieni z NIO
> implementują ten interfejs. Można uznać, że "po nowemu" operacje na
> strumieniach są już przerywalne.

Zgadza się - tylko nie wiem, czy przyjrzałeś się, ile klas do obsługi
strumieni istnieje w Javie. Kręćka można dostać.

A przerabiałem ten temat ostatnio właśnie w związku ze wspomnianą aplikacją.
Okazuje się, co ciekawe, że wsród ok dobrych 20 klas do obsługi strumieni w
najróżniejszych kontekstach i sposobach itd. nie ma ani jednej klasy
pozwalającej na buforowanie liniowe.

A druga ciekawa sprawa polega na tym: mamy InputStreamReader, która czyta
tekst (bajty, dekodując na UTF-8 stają się tekstem ASCII - to mnie
interesowało w tym przypadku, bo tak zorganizowałem protokół). Dodatkowo
istnieje klasa BufferedReader i BufferedWriter, a konkretnie interesowało mnie
to drugie. Dokładnie to interesowało mnie, żeby tekst posłać do strumienia bez
buforowania, bo strumień był podłączony do socketa. Ponieważ komunikacja
polegała na wykonywaniu komend, więc interesowało mnie, żeby tekst został tam
posłany od razu. Okazało się jednak, ku mojemu zdumieniu, że nawet bez użycia
BufferedWriter, klasa OutputStreamWriter, której obiekt został utworzony na
bazie obiektu klasy OutputStream, pobranego z Socketa, również posiada
buforowanie! To znaczy - jeśli chcesz mieć "efekt niebuforowany", to musisz
robić flush() po write().

Jest to o tyle ciekawe, że w dokumentacji zapewniają wyraźnie, iż czytanie na
zapas jest potrzebne tylko do tego, żeby poskładać w jedno kilkubajtowy znak w
UTF.

Efekt jest taki, że aby obsługiwać protokół tekstowy musiałem sobie napisać
klasy DirectWriter i LineReader. Tak swoją ścieżką, LineReader okazała się na
tyle przydatna, że przepisałem ją potem na C++ :)

> Nie wykluczam, że osobna klasa wyjątku jest spowodowana tym, że różne
> interfejsy wejścia-wyjścia uwzględniały już IOException, ale nie
> InterruptedException, więc można było dodać ClosedByInterruptException
> pośrednio dziedziczące po IOException bez zmiany deklaracyj wyjątków.
> Ale tylko tak zgaduję.

Tak - a ponieważ Java nie ma wielorakiego dziedziczenia i nie można było
zrobić klasy dziedziczącej równocześnie po IOException i
InterruptedException... :)

> > Super - tylko skoro wątek może być przerwany tylko przez InterruptedException,
> > to w jaki sposób następuje "killowanie" wątku javowego? Jeśli nikt nie używa
> > żadnego sleep() w środku, to wątku nie można przerwać w ogóle? A jeśli można,
> > to jak się to odbywa?

> Ktoś z zewnątrz może zrobić temu wątkowi Thread.interrupt. Wtedy
> ten wątek zostanie przerwany przy najbliższej okazji, kiedy wykona
> przerywalną operację (wait, join, sleep, coś z InterruptibleChannel,
> coś z Selector). Przy czym przerwanie Selectora nie powoduje wyjątku.

> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#interrupt()

> Nie wiem, czy w Javie są inne źródła takich przerwań niż Thread.interrupt.

Czyli jeśli np. mam wątek, który wykonuje "śledzenie kanału", tzn. czyta ze
strumienia (socketowego), interpretuje komunikat i aktualizuje stan (i on
tutaj niczego nie obciąża, bo za "sleepa" robi read), to nie ma żadnej
możliwości, żeby taki wątek ustrzelić? Oczywiście chyba żeby używać
InterruptibleChannel.

> W Kogucie najbliższy odpowiednik takich przerwań (nazwany przeze mnie
> sygnałami) nie skutkuje wyjątkiem, tylko wykonaniem funkcji obsługi
> sygnału (nie mylić z funkcjami obsługi sygnału w C, które określa się
> całkiem inaczej), która może rzucić wyjątkiem, ale może też zrobić coś
> innego i potem kontynuować działanie przerwanego kodu.

No i prawidłowo - tak właśnie powinno się robić.

Tylko po pierwsze, twórcy Javy wszystko wiedzą lepiej (przecież NA PEWNO
będziesz chciał rzucić wyjątkiem), a po drugie dodanie "funkcji obsługi" w
Javie to katorga niesamowita - bo w Javie, ponieważ nie ma wskaźników do
funkcji ani delegatów, trzeba się ratować metodami.

> Do tego dochodzi
> mechanizm tymczasowego blokowania sygnałów, zintegrowany z różnymi
> konstrukcjami języka. Sygnał z kolei może być skutkiem:
> - jawnego przerwania wątku przez inny wątek
> - sygnału Uniksa skierowanego do procesu (dostaje go wątek przeznaczony
>   do odbioru sygnałów systemowych, domyślnie jest nim wątek główny)
> - kończącej się pamięci (dostaje go wątek odbierający sygnały systemowe)
> - zbyt dużego zużycia stosu (dostaje go winowajca)
> - zakończenia programu, któremu zostały inne wątki
> - forka procesu (za pomocą sygnałów znajdowany jest odpowiedni dla
>   innych wątków moment wykonania forka)
> - porzucenia zablokowanego wątku przez program (zanim wątek zostanie
>   odśmiecony, jest kopnięty przez sygnał i ma szansę się ładniej zamknąć)
> - wzajemnego zakleszczenia się wszystkich wątków

> Moje założenie dla Koguta jest takie, żeby typowy kod można było
> bezpiecznie przerwać bez poświęcania istotnej części projektu danego
> programu na obsługę przerwań. Konstrukcje językowe, które ułatwiają
> pisanie kodu bezpiecznego względem synchronicznych wyjątków, miewają
> proste uogólnienia, które ułatwiają osiągnięcie bezpieczeństwa również
> względem asynchronicznych sygnałów. Chodzi głównie o stosowanie operacji
> działających na zakresach kodu zamiast polegania na zmianach stanu
> jako efektach ubocznych instrukcji (odpowiednik RAII) i o automatyczne
> blokowanie sygnałów przez pewne operacje (kanoniczny przykład to zajęcie
> muteksa).

No dobrze - ale co taki sygnał może przerwać?

Bo dla mnie idealny sposób przerywania wątku jest taki, że można przerwać w
dowolnym momencie, nawet w połowie operacji, tyle że wszystkie obiekty powinny
być bezpiecznie zniszczone - ale mówię, zniszczone; program nie może mieć
gwarancji, że będzie mógł dalej działać, jeśli dostał już killa.

> > > Gdyby mógł wystąpić w zupełnie dowolnym momencie, to nie dałoby się
> > > pisać poprawnego kodu, bo np. nie da się zagwarantować, że z pewnych
> > > dwóch instrukcji wykonają się obie albo żadna.
> > 
> > Oj, nie rozumiem, niby dlaczego. Jeśli wykonuję a + b + c, a drugi plus rzuci
> > wyjątkiem (bo akurat ktoś stwierdził, że sprzeda procesowi killa), to jaki
> > problem tu może wystąpić?

> Jak napisałem, problemem jest brak możliwości zagwarantowania,
> że z dwóch sąsiednich instrukcji wykonają się obie albo żadna.
> Na przykład niech jedna z tych instrukcji dodaje powiązanie we
> współdzielonym słowniku, a druga uaktualnia rozmiar słownika.

> Twórcy Javy nie od razu to zauważyli:
> http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#stop()

> Sposób, w jaki zostało to poprawione (tzn. Thread.interrupt przerywające
> wybrane operacje), nie jest idealny, bo z jednej strony nie umożliwia
> wykonania tych operacji bez możliwości przerwania, a z drugiej strony
> nie pozwala przerwać czystych obliczeń, które tego nie przewidziały.
> Ale przynajmniej pozwala pisać kod, który bezpiecznie jest przerwać
> i który po tym przerwaniu program nie nadaje się wyłącznie do awaryjnego
> zakończenia.

No tak, ale mówimy o współdzielonych obiektach.
Nie wiem, czy w ogóle istnieje sensowny sposób na zdefiniowanie
nieprzerywalnych operacji. Ale - przykładowo - z tego co pamiętam do tego
czegoś właśnie służą muteksy - chodzi o to, żeby inny wątek nie dobrał się do
tych samych danych równocześnie. Może dobrym pomysłem byłoby wstrzymywanie
przerwania do czasu, aż wątek zwolni wszystkie muteksy?

Oczywiście wątek nadrzędny powinien dostać killa w przypadku wykrycia
zakleszczenia.

> > > Należy umożliwić wątkowi blokowanie przerywania
> > 
> > Nie. Należy umożliwić wątkowi sprzątanie istniejących zasobów w razie
> > przerwania, natomiast na pewno nie odkładanie reakcji na przerwanie ad
> > calendas graecas.

> Jak widzę, popełniłbyś ten sam błąd co twórcy Javy :-)

> Upieram się, że należy umożliwić wątkowi blokowanie przerywania.
> To jest naturalne rozwiązanie dla typowego modelu współbieżności:
> dla wątków ze współdzieloną pamięcią zawierającą zmieniające swój
> stan obiekty.

Tak - tu, jak najbardziej, ale napisałem wyraźnie: NIE odkładanie reakcji na
przerwanie ad calendas graecas. To znaczy - żeby nie umożliwiać programowania
wątku tak, że składa się on wyłacznie z ciągu nieprzerywalnych instrukcji.

> Uniksowa funkcja sigprocmask (tudzież pthread_sigmask dla programów
> wielowątkowych) istnieje nie bez powodu.

Owszem.

> Haskell ma trochę inny paradygmat i trochę inny model przerywania wątków.
> W dużej mierze podobny, ale jego zachowanie przerwania obliczenia leniwej
> zmiennej jest lepsze niż moje. A to dzięki temu, że Haskell rozróżnia
> czysto funkcyjny kod od kodu imperatywnego. Dzięki temu wie, które
> obliczenia bezpiecznie jest wykonać jeszcze raz, a które nie. Ja tego
> nie wiem, więc musiałem przyjąć domyślne blokowanie przerywania przy
> leniwych zmiennych. Haskell mógł wykorzystać to, że czysto funkcyjny kod
> bezpiecznie jest przerwać w każdym momencie.

No taaak - nie no na pewno jest to w ogólności dobre, że Haskell musi mieć
wyraźnie zaznaczone, gdzie w ogóle jest kod imperatywny, ale problem w tym, że
mało komu się chce tak pisać.

> Za to moja semantyka jest
> przydatniejsza w innych sytuacjach. Na przykład Concurrent Haskell nie
> rozróżnia muteksów od semaforów, a ja rozróżniam, przez co mnie jest
> łatwiej powiązać przerywalność wątku z faktem zajęcia muteksa.

O, widzę że chyba myślimy o tym samym :)

> > > Przy czym w C++ nie ma na to szans, bo jest zdecydowanie zbyt wiele
> > > miejsc, których nie można przerwać, ale nie ma jak ich automatycznie
> > > rozpoznać. Na przykład region między new a przypisaniem gołego wskaźnika
> > > do sprytnego wskaźnika nie może być przerywalny (przynajmniej przy
> > > standardowym alokatorze).
> > 
> > Moment - o ile ja znam C++, to przerwanie przez wyjątek może nastąpić tylko w
> > dwóch miejscach: w operatorze new (wtedy pamięć jest automatycznie usuwana)
> > lub po przypisaniu (zakładamy, że w trakcie przypisywania nie wystąpi).

> Cały czas mówię o asynchronicznych wyjątkach, mających swoje źródło poza
> danym wątkiem. One mogą przyjść w dowolnym momencie, również kiedy wątek
> jest "między" alokacją pamięci a przypisaniem wskaźnika. Nie da się tego
> załatać przez zadeklarowanie, że "między" nie istnieje, bo w bardziej
> rozbudowanym przypadku tam się znajdą jakieś wywołania funkcji itp.,
> które musiałbyś zakwalifikować jako reagujące na asynchroniczne wyjątki
> bądź nie. Jeśli za dużo operacji będzie przerywalnych, to trudno będzie
> pisać bezpieczny kod, bo zdarzą się sytuacje, w których skądinąd
> przerywalna operacja akurat w danym kontekście nie może być przerwana.

Ok - to trzeba w takim przypadku dać możliwość zdefiniowania takiego
szczególnego przypadku.

> Przy przesadzie w drugą stronę wątek może wykonywać dużo obliczeń bez
> szans na przerwanie. To nie wystarczy.

Za bardzo uogólniasz.

A sam wskazałeś właśnie, że problem istnieje tutaj dokładnie w jednym
przypadku: jeżeli wątek, który jest przerywany, jest akurat w trakcie
wykonywania nieprzerywalnej operacji, a nieprzerywalność tej operacji wynika
tylko i wyłącznie stąd, że dokonuje modyfikacji współdzielonych danych.

Jeśli wykluczymy działanie na współdzielonych danych (włączając w to nawet
operacje na plikach), to okaże się, że każdą operację można przerwać w
połowie, jeśli za chwilę wszelkie zasoby, na których ta operacja działała,
zostaną zniszczone. Można wręcz potraktować przerwanie jako przełączenie
wykonania na inny wątek (przy czym sterowanie do tego wątku nigdy już nie
wróci, a o tym, że ten inny wątek nie istnieje pierwotny wątek i tak się nie
dowie).

> Najlepszą radą na to, jaką znam, jest związanie z każdym wątkiem
> bieżącego stanu zablokowania asynchronicznych sygnałów. Przy czym
> okazuje się, że ten stan powinien być trochę bardziej rozbudowany
> niż jedna boolowska flaga (u mnie to jest licznik + dodatkowa flaga).
> Przedsmakiem tego rozbudowania jest funkcja pthread_setcanceltype
> istniejąca obok pthread_setcancelstate.

Można, ale nie wiem, czy znów nie umożliwi to blokowania w nieskończoność.


-- 
//  _    ___         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"

Dnia 26-11-2007, Pn o godzinie 09:17 +0000, Sektor van Skijlen pisze:

> No dobrze - ale co taki sygnał może przerwać?

Stan blokowania sygnałów przez dany wątek ma postać pary (all, async),
gdzie all jest liczbą naturalną oznaczającą liczbę powodów, dla których
sygnały powinny być zablokowane, a async ma zakres 0..1. Ta przestrzeń
stanów daje to tylko trzy możliwe reakcje na sygnały:

(0, 0) - sygnał może być obsłużony w każdym momencie
(0, 1) - sygnał może być obsłużony tylko przez wybrane operacje,
         które na coś czekają (tzw. tryb synchroniczny)
inne   - sygnał jest kolejkowany do obsłużenia później

Stan blokowania jest jawnie zmieniany przez pewne funkcje, a także mniej
jawnie:

- Sygnały są blokowane na czas wzięcia muteksu, wzięcia read-write locka
  (jak on się po polsku nazywa?), obliczania wartości leniwej zmiennej,
  inicjalizacja modułu innego niż moduł główny, jawnego uruchomienia
  finalizatora obiektu, obsługi wyjątku (chyba że zaznaczono inaczej),
  obsługi sygnału.

- Konstrukcja zarządzająca zasobem wymagającym jawnego zwalniania
  (Using) składa się z trzech części: pobranie zasobu, treść główna
  i zwolnienie zasobu. Na czas pobierania zasobu asynchroniczne
  sygnały są blokowane, a na czas zwalniania - wszystkie są blokowane.

- Nowy wątek normalnie ma odblokowane sygnały, ale można utworzyć wątek
  z zablokowanymi na starcie (co jest konieczne, jeśli chcemy uniknąć
  okienka, kiedy wątek nie zdążył jeszcze określić innej funkcji obsługi
  sygnałów).

(Leniwa zmienna to jest coś takiego, co przy pierwszej próbie odczytania
wartości wykonuje dane obliczenie, a przy następnej próbie zwraca to co
obliczono poprzednio. Pytanie o wartość leniwej zmiennej, która właśnie
się liczy przez inny wątek, czeka na zakończenie tego obliczenia.
Pytanie o wartość leniwej zmiennej, która właśnie się liczy przez ten
sam wątek, jest błędem. Inicjalizacja modułu ma analogiczną semantykę
i wewnętrznie używa jednej leniwej zmiennej na moduł.)

Operacje, które obsługują sygnały w trybie synchronicznym, to
czekanie na condition, na zakończenie wątku, na zakończenie procesu,
na wejście-wyjście (w tym na otwarcie pliku, który może być rurką -
wtedy open jest blokujące), na upływ danego czasu. Ale nie na mutex,
na leniwą zmienną ani na finalizator obiektu.

Nie będę teraz wnikać w bardziej szczegółowe przypadki: leniwe listy
(które są podobne do leniwych zmiennych, ale mają dodatkowe komplikacje
związane z sygnałami), eksperymentalne kolejki multipleksujące zdarzenia,
czekanie na muteks przy wyjściu z lokalnego zwolnienia, a nie przy
wejściu na lokalne zajęcie, fork wielowątkowego procesu i inne.

> Oczywiście wątek nadrzędny powinien dostać killa w przypadku wykrycia
> zakleszczenia.

Jakiego zakleszczenia i jaki wątek nadrzędny? W Kogucie wątki nie mają
relacji nadrzędny-podrzędny.

Jeśli wątek miałby zakleszczyć się sam ze sobą, to odpowiednia operacja
rzuca wyjątkiem. Wzajemne zakleszczenie kilku wątków nie jest wykrywane,
ale są reakcje na to, że wątek miałby zostać odśmiecony (co może być
skutkiem ich zakleszczenia, jeśli nikt inny nie ma dostępu do obiektów
synchronizujących, na których czekają) i na zakleszczenie wszystkich
wątków.

> Tak - tu, jak najbardziej, ale napisałem wyraźnie: NIE odkładanie
> reakcji na przerwanie ad calendas graecas.

To jest kwestia przyzwoitości kodu, a nie gwarancji dawanych przez język.
Dobrym zwyczajem jest blokowanie sygnałów tylko na krótkie chwile, ale
nie da się tego wymusić.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Seweryn Habdank-Wojewódzki wrote:
>>>>>Wieź mi tu nie zalatuj przykładami kodu powstałymi w czasie kiedy Python
>>>>>był co najwyżej w umyśle GvR.
>>>>
>>>>Języki bezpieczne znane są od ponad 45 lat. Języki w których nie ma
>>>>podstawoych dziur w systemie typów były popularne już blisko 40 lat temu
>>>>sic(!).
>>>
>>>Tak i gdyby wtedy informatyka bazowała tylko na nich to do dziś byśmy
>>>mieli tylko maszyny do pisania. Niebezpieczne języki pozwoliły wejść na
>>>orbitę szybkości.
>>
>>Nonsens. Wiele innych kompilowanych języków by się nadawało.
> 
> Ale się nie nadały.

Raczej nie zostały użyte. Albo produkty w których zostały użyte nie 
zdominowały rynku (z przyczyn rozmaitych, niekoniecznie technicznych).

[...]
>>>A gdyby nie te niebezpieczne języki, to dziś nie miałbyś tych
>>>niby lepszych bezpiecznych języków nowej generacji. Python w ogóle by nie
>>>istniał, bo jego reference implementation stoi po pachy w C.
>>
>>Mogłoby równie dobrze stać w innym języku kompilowanym, hgdyby to ten
>>język był językiem API OS.
> 
> No ale niestety API OS są paskudnie C-owate :-).


Akurat tych popularnych. Ale znam OS w którym jeszcze parę lat temu sporo 
programowałem, którego API jest mało C-towate (choć wiązania do C są, ale 
tak samo są np. do Pascala). Ten OS jest zresztą całkiem sławny, to poniekąd 
intelektualny poprzednik windows NT -- Mowa o OpenVMS. OS jescze istnieje 
ale to już kompletna nisza -- ale z powodów zupełnie nietechnicznych (raczej 
takich że Digital był zarządzany słabo, a potem wprost wrogo do firmy 
(ostatni prezes przed wykupieniem przez Compaqua firmę rozmontowywał, 
uzyskując w ten sposób wysokie wyniki księgowe)


>>>Ale ja nie słyszę o tych jezykach, nie widzę ofert pracy, nie widzę
>>>projektów (a już w mojej działce to w ogóle). Proszę oświeć mnie, bedę
>>>wdzięczny.
>>
>>Ludzie jedzcie guano! Miliardy much nie mogą się mylić!
> 
> Sebastian. Wszystko jest dobrze. Rozumiem Twoje dążenie do ideału. Kłopot
> polega np. na tym, że do super języków nie ma ekip koderskich.
> 
> Lokalnie tutaj możemy uznać że Kogut jest jednym z bliskich ideałowi.
> OK. załóżmy, że go umiemy. I teraz biorę ten język i mówię obcej kompanii
> "chłopaki od dziś piszemy w Kogucie". Co oni na to? 
> 
> Co manago finansowy na to? Kiedyś ktoś mi powiedział, że manago nie może
> zmuszać ludzi do nauki języka, bo oni za chwilę przyjdą po podwyżkę. 
> 
> Znajomość i nauka drugiego trzeciego, k-tego języka musi wyjść od ludzi
> samych, bo wtedy finansista nie przylatuje z wrzaskiem, że za duże koszty
> są generowane. Jego nie obchodzi to, że ekipa znająca dziś jeden język
> jutro 3, dziś i jutro przyniesie stratę 100%, pojutrze zysk 500%. 
> Manago finansowy patrzy, aby jemu kichany Annual Turnover się poprawiał, bo
> ma w planie na koniec roku prezentację i tam wykres musi iść do góry.

Cóż, tacy właśnie od Annual Turnover parę firm rozwalili. Trzba pracować w 
czymś mniejszym, ale elastycznnym i prężnym, gdzie władza jest w rękach 
żywych właścicieli, i gdzie ci właścieciele mają firmę programistyczną bo na 
tworzeniu programowania się znają, a nie dla tego, że tak jest cool.

BTW. to jest, wg niektórych, jeden z powodów sukcesu Microsoftu -- Bill wie 
co to jest program i co to jest komputer. Jak ktoś nie odróżnia komputera od 
puszki pepsicoli to zjeżdża tak ja Apple z kilkunastu procent rynku do dwu 
(zauważ, że Apple się odbiło jak wrócił Jobs, który o dziwo wie co to jest 
ta blaszana puszka z elektroniką w środku)


> Teraz mi powiedz jaki wybierasz język, aby jednak ekipa coś więcej
> potrafiła. Przede wszystkim taki, który jest znany, bądź poznawalny kosztem
> hobby. Zatem muszą to być języki nie tyle idealne, co języki mające taki a
> nie inny support. Szybko okazuje się, że nawet jeśli ja znam Koguta, to mój
> qmpel nie całkiem i ma problemy z poznaniem. Tak więc szybko topnieje
> liczba ideałów, które mogą być używane w ekipie koderskiej. Do tego
> dochodzą listy dyskusyjne tutki itd. Jakbyś nie patrzył, na grupach o C,
> ++, J, Py, jest spory ruch a takiego Lispa nie widzę. Jest oczywiście
> grupa "funkcyjna", ale tam ruch jest mały, żeby nie powiedzieć znikomy.

Cóż. Paki Py też kiedyś zaczynał. Zwykle to się bierze od tego, że nowy 
języka ma jakąś niszę w której wymiata i jest sexi. Jest jakiś zabójczy 
produkt (killer application) właśnie na tym języku oparty. Tak było z C na 
którym oparto Unix, który to Unix przez swoje bardzo poważne walory 
projektowe szybko się wybił, ciągnąc za sobą C (którego walory są już nieco 
wątpliwe). Tak było z Rubym (Rails), Pythonem (edukacyjna składnia), Perlem 
(oskryptowywwanie administracji systemami), itd.

Btw. ja też mam tu pewien pomysł, ale jeszcze zbyt wcześnie by go ujawniać. :)


>>Python ma kilka lekkich wtrętów funkcyjnych. Ale AFAIR nie ma choćby
>>rozwijania rekursji ogonowej (a w każdym razie na to gwarancji) więc kod w
>>sytlu funkcyjnym, bez pętli, w Pythonie leży conajmniej źle.
> 
> Nie bądźmy purytańscy. Nie chodzi o pisanie tak samo, chodzi o możliwość
> przeniesienia abstrakcji myślowej.

No, ale użycie rekursji jest w nim kosztowne i tam gdzie da się użyć pęltli 
należy użyc pętli. W podejściu funkcyjnym nie ma pętli -- jest tylko 
rekursja. Ten "mindset" nie znosi pętli a (nad)używa rekursji.


>>np. owo nieszczęsne map (co to nie ma już dictionary?) czy nawet vector
>>(zamiast array czy dyn_array czy dynamic_array).
> 
> Znaczy się, co? Nazwy Ci przeszkadzają?

Nazwy to jest element entry barrier dla początkujących.


>>Nie mówiąc już o "super wygodnym" wykonywaniu takich dupereli jak
>>sprawdzenie czy w mapie jest dany klucz.
> 
> map::count(klucz)?

count sugeruje zliczenie a nie sprawdzenie istnienia. To jest Ceizm. Tak jak:

int i = sth()
if(i) {
   do_other_thing()
}

Jak piszę count to liczę wystąpienia kluczy (w map zresztą bez sensu, zawsze 
będzie 1 lub 0, w multi_map ma to sens). To jest właśnie taka drobna 
upierdliwość. A wystraczyło by has_key() zdefiniowane jako count() != 0.


>>>A ja i tak nie widzę gdzie w pliku boost/shared_ptr.hpp jest
>>>synchronizacja, poproszę o pomoc publiczności.
>>
>>Publiczność (w osobie Piotra Wyderskiego) już pomogła :)
> 
> 
> Z całym szacunkiem Piotr wskazał kod dla SPARKA. Wskarzę dla mojego marnego
> Athlona na Linuxie i tam nie ma synchronizacji. Nawet pofatygowałem się,
> aby przeglądnąć powstały asm i są używane tylko normalne komendy.

Ależ jest. Inaczej by nie spowalniało 2 razy przy zlinkowaniu z wątkami. I 
musi być bo inaczej byłoby cienko, bo by kopilator wyoptymalizował i popsuł.


>>>Zresztą, nie kapuję Twojego płaczu, kiedyś płakałeś, że nic nie jest
>>>synchronizowane, teraz płączesz, że tr1::shared_ptr jest synchronizowany.
>>>Nie rozumiem o co chodzi?
>>
>>Dziecko wylane z kompielą?
> 
> Rozumiem. Ja nie wylewam dzieci, mogę Ci przesłać tego shared_ptr bez
> synchronizacji.

A jak będę chciał dla paru obiektów mieć synchronizację a dla innych nie?
To jest właśnie zły design.


>>Nie ma:)
>>Jest w lepszym miejscu :)
> 
> Dla mnie z mojego punktu widzenia wydajności nie ma znaczenia gdzie ona jest
> jeśli jest.

No właśnie ma znaczenie. Bo ma znaczenie czy jest wywoływana 10000000 razy 
czy 10000 razy w trakcie trwania obliczeń.


>>Rozumiem że mowa o DBE (DataBase engines). Większość jest pisana po prostu
>>w języku systemowym. Coś co dla poperawnego działania wymaga
>>niebuforowanego dostępu do dysku, kontroli procesów (tego co ginie co nie)
>>itd pisze sie raczej w języku systemowym.
> 
> A systemy czemu są pisane w paskudnych językach?

Wszystkie trzy? Tak wyszło historycznie.


>>Znam dużo popularnego softu nie w C++. Działa. Dobrze działa. I nie umiera
>>od czasu do czasu z informacją że jakiś generał Protection się pomylił
>>(soft pisany przez wojsko ;) ?). Np. taki Jedit, czy Eclipse, czy parę
>>dobrych webserwerów.
> 
> O tak. Nawet w KDE klikam na ikonę KDevelop i program się otwiera.

Ino od czasu do czasu się wywala.

> Klikam na
> Eclipse i czekam i czekam ... idę po napój ... wracam jest. Z Netbeansami
> jest jeszcze gorzej. A ram? Mam 1.5GB i o jak strasznie mało dla tego
> Eclipse/Netbeans. Muszę kupić sobie więcej. W ogóle mam kiepskie komputery,
> musze kupić lepsze. 

Odpal Jedita -- chodzi o dziwo szybko.

Odpal też takiego Gimpa (kod w C) i popatrz czemu tyle wstaje.


[...]
> A co do webserwerów w J -- nic mi o nich nie mów. Już pisałem że np. EJB
> przy Plone to jak asembler przy C++.

Mówię o samych webserwerach jako takich. Aplikacjach samych w sobie. Parę 
jest zupełnie OK.


[...]
>>[... duże ciach gdzie się zgadzam ...]
> 
> Cieszę się, że mamy jakieś punkty zgodności :-D.

:)

pzdr
\SK

>> Teraz mi powiedz jaki wybierasz język, aby jednak ekipa coś więcej
>> potrafiła. Przede wszystkim taki, który jest znany, bądź poznawalny
>> kosztem hobby. Zatem muszą to być języki nie tyle idealne, co języki
>> mające taki a nie inny support. Szybko okazuje się, że nawet jeśli ja
>> znam Koguta, to mój qmpel nie całkiem i ma problemy z poznaniem. Tak
>> więc szybko topnieje liczba ideałów, które mogą być używane w ekipie
>> koderskiej. Do tego dochodzą listy dyskusyjne tutki itd. Jakbyś nie
>> patrzył, na grupach o C, ++, J, Py, jest spory ruch a takiego Lispa nie
>> widzę. Jest oczywiście grupa "funkcyjna", ale tam ruch jest mały, żeby
>> nie powiedzieć znikomy.
> 
> Cóż. Paki Py też kiedyś zaczynał. Zwykle to się bierze od tego, że nowy
> języka ma jakąś niszę w której wymiata i jest sexi. Jest jakiś zabójczy
> produkt (killer application) właśnie na tym języku oparty. Tak było z C
> na którym oparto Unix, który to Unix przez swoje bardzo poważne walory
> projektowe szybko się wybił, ciągnąc za sobą C (którego walory są już
> nieco wątpliwe). Tak było z Rubym (Rails), Pythonem (edukacyjna
> składnia), Perlem (oskryptowywwanie administracji systemami), itd.
> 
> Btw. ja też mam tu pewien pomysł, ale jeszcze zbyt wcześnie by go
> ujawniać. :)
> 

Jeśli dobrze sobie przypominam to C wymyślono na potrzeby Uniksa właśnie. 
Umożliwiło mu to uzyskanie przewagi nad OS'ami pisanymi w assemblerze. A 
jeśli chodzi o zalety C w stosunku do języków wysokopoziomowych to podam 
jedną - szybkość. U mnie jest znacząca różnica między działaniem beagle 
(C#) i tracker (C). O ile ten drugi potrafi zajmować xxx MiB RAMu i swapu 
a na wszyskanie czeka się kilkanaście sekund to tracker zajmuje 38 MiB 
pamięci.

>>>Nie mówiąc już o "super wygodnym" wykonywaniu takich dupereli jak
>>>sprawdzenie czy w mapie jest dany klucz.
>> 
>> map::count(klucz)?
> 
> count sugeruje zliczenie a nie sprawdzenie istnienia. To jest Ceizm. Tak
> jak:
> 
> int i = sth()
> if(i) {
>    do_other_thing()
> }
> 
> Jak piszę count to liczę wystąpienia kluczy (w map zresztą bez sensu,
> zawsze będzie 1 lub 0, w multi_map ma to sens). To jest właśnie taka
> drobna upierdliwość. A wystraczyło by has_key() zdefiniowane jako
> count() != 0.
> 

count ma sens dla map w programowaniu generycznym. A co do has_key się 
zgadzam jeśli miałoby to różną złożoność(czyli zapewne dla multi_map).

>> Klikam na
>> Eclipse i czekam i czekam ... idę po napój ... wracam jest. Z
>> Netbeansami jest jeszcze gorzej. A ram? Mam 1.5GB i o jak strasznie
>> mało dla tego Eclipse/Netbeans. Muszę kupić sobie więcej. W ogóle mam
>> kiepskie komputery, musze kupić lepsze.
> 
> Odpal Jedita -- chodzi o dziwo szybko.
> 
> Odpal też takiego Gimpa (kod w C) i popatrz czemu tyle wstaje.
> 

Wtyczki w Lispie? ;)

A tak na poważnie u mnie (Celeron M 1.5 GHz + 512 MiB RAM) gimp uruchamia 
się 10x szybciej niż eclipse i porównywalnie z moim DumpProp.java(program 
wypisujący na stdout wartości z System.getProperties()) zajmując 26 MiB 
RAM. 

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

Dnia 28-11-2007, Śr o godzinie 22:56 +0100, Maciej Piechotka pisze:

> U mnie jest znacząca różnica między działaniem beagle 
> (C#) i tracker (C). O ile ten drugi potrafi zajmować xxx MiB RAMu i swapu 
> a na wszyskanie czeka się kilkanaście sekund to tracker zajmuje 38 MiB 
> pamięci.

U mnie też jest różnica. Beagle rzeczywiście zajmuje sporo procesora
(co jakiś czas) i pamięci.

Tracker za to nie działa w ogóle. Wcześniejsze wersje trackera były
chyba niekompatybilne z wersją dbus, którą miałem, a w nowszej wersji
w końcu przestał sypać błędami przy próbie komunikacji przez dbus,
ale i tak wynik wyszukiwania zawsze był pusty.

Dlatego używam beagle :-)

(Zresztą głównie do przeszukiwania stron WWW, które odwiedzałem.
Tracker chyba nie ma takiej wtyczki dla Firefoksa.)

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

On Wed, 28 Nov 2007 23:10:44 +0100, Marcin ‘Qrczak’ Kowalczyk wrote:

> Dnia 28-11-2007, Śr o godzinie 22:56 +0100, Maciej Piechotka pisze:
> 
>> U mnie jest znacząca różnica między działaniem beagle (C#) i tracker
>> (C). O ile ten drugi potrafi zajmować xxx MiB RAMu i swapu a na
>> wszyskanie czeka się kilkanaście sekund to tracker zajmuje 38 MiB
>> pamięci.
> 
> U mnie też jest różnica. Beagle rzeczywiście zajmuje sporo procesora (co
> jakiś czas) i pamięci.
> 
> Tracker za to nie działa w ogóle. Wcześniejsze wersje trackera były
> chyba niekompatybilne z wersją dbus, którą miałem, a w nowszej wersji w
> końcu przestał sypać błędami przy próbie komunikacji przez dbus, ale i
> tak wynik wyszukiwania zawsze był pusty.
> 
> Dlatego używam beagle :-)
> 
> (Zresztą głównie do przeszukiwania stron WWW, które odwiedzałem. Tracker
> chyba nie ma takiej wtyczki dla Firefoksa.)

U mnie tracker działa(0.6.3). Za to z koleji beagle zaczeło zawieszać 
programy (dokładnie FileChooserDialog) - co ostatecznie skłoniło mnie do 
migracji.

Na razie tracker ma mieć możliwość dodania takiej wtyczki. Pożyjemy - doczekamy 
się ;)

Pozdrawiam
-- 
I've probably left my head... somewhere. Please wait untill I find it.
Homepage (pl_PL): http://uzytkownik.jogger.pl/
(GNU/)Linux User: #425935 (see http://counter.li.org/)

Dnia Mon, 26 Nov 2007 12:26:30 +0100, Marcin ?Qrczak? Kowalczyk skrobie:
> Dnia 26-11-2007, Pn o godzinie 09:17 +0000, Sektor van Skijlen pisze:

> > No dobrze - ale co taki sygnał może przerwać?

> Stan blokowania sygnałów przez dany wątek ma postać pary (all, async),
> gdzie all jest liczbą naturalną oznaczającą liczbę powodów, dla których
> sygnały powinny być zablokowane, a async ma zakres 0..1. Ta przestrzeń
> stanów daje to tylko trzy możliwe reakcje na sygnały:

> (0, 0) - sygnał może być obsłużony w każdym momencie
> (0, 1) - sygnał może być obsłużony tylko przez wybrane operacje,
>          które na coś czekają (tzw. tryb synchroniczny)
> inne   - sygnał jest kolejkowany do obsłużenia później

> Stan blokowania jest jawnie zmieniany przez pewne funkcje, a także mniej
> jawnie:

> - Sygnały są blokowane na czas wzięcia muteksu, wzięcia read-write locka
>   (jak on się po polsku nazywa?),

Blokada czytelnicy-pisarze. Przynajmniej takie spotkałem w książce pt. "Jądro
systemu UNIX".

> obliczania wartości leniwej zmiennej,
>   inicjalizacja modułu innego niż moduł główny, jawnego uruchomienia
>   finalizatora obiektu, obsługi wyjątku (chyba że zaznaczono inaczej),
>   obsługi sygnału.

Obsługi sygnału również? A co w przypadku, gdy handler sygnału "spowoduje"
sygnał?

> - Konstrukcja zarządzająca zasobem wymagającym jawnego zwalniania
>   (Using) składa się z trzech części: pobranie zasobu, treść główna
>   i zwolnienie zasobu. Na czas pobierania zasobu asynchroniczne
>   sygnały są blokowane, a na czas zwalniania - wszystkie są blokowane.

No to jest ok.

> - Nowy wątek normalnie ma odblokowane sygnały, ale można utworzyć wątek
>   z zablokowanymi na starcie (co jest konieczne, jeśli chcemy uniknąć
>   okienka, kiedy wątek nie zdążył jeszcze określić innej funkcji obsługi
>   sygnałów).

> (Leniwa zmienna to jest coś takiego, co przy pierwszej próbie odczytania
> wartości wykonuje dane obliczenie, a przy następnej próbie zwraca to co
> obliczono poprzednio. Pytanie o wartość leniwej zmiennej, która właśnie
> się liczy przez inny wątek, czeka na zakończenie tego obliczenia.
> Pytanie o wartość leniwej zmiennej, która właśnie się liczy przez ten
> sam wątek, jest błędem.

Znaczy się bottomem (w tym przypadku z powodu nieskończonej rekurencji).

> Inicjalizacja modułu ma analogiczną semantykę
> i wewnętrznie używa jednej leniwej zmiennej na moduł.)

ok.

> Operacje, które obsługują sygnały w trybie synchronicznym, to
> czekanie na condition, na zakończenie wątku, na zakończenie procesu,
> na wejście-wyjście (w tym na otwarcie pliku, który może być rurką -
> wtedy open jest blokujące), na upływ danego czasu. Ale nie na mutex,
> na leniwą zmienną ani na finalizator obiektu.

> Nie będę teraz wnikać w bardziej szczegółowe przypadki: leniwe listy
> (które są podobne do leniwych zmiennych, ale mają dodatkowe komplikacje
> związane z sygnałami), eksperymentalne kolejki multipleksujące zdarzenia,
> czekanie na muteks przy wyjściu z lokalnego zwolnienia, a nie przy
> wejściu na lokalne zajęcie, fork wielowątkowego procesu i inne.

No super - tylko czy teraz możesz używając właściwości języka określić dany
zakres instrukcji "ręcznie" jako nieblokowalny w określonym trybie? Wraz,
oczywiście, z ewentualnymi możliwymi do zdefiniowania zastrzeżeniami, że
danego bloku z pewnych przyczyn nie można "zalakowć" (bo np. w środku wywołuje
instrukcję, która w razie niepowodzenia rzuca wyjatkiem, co oznacza, że
instrukcja dla niej nadrzędna nie może zostać wykonana)?

> > Oczywiście wątek nadrzędny powinien dostać killa w przypadku wykrycia
> > zakleszczenia.

> Jakiego zakleszczenia i jaki wątek nadrzędny? W Kogucie wątki nie mają
> relacji nadrzędny-podrzędny.

No, wątek nadrzędny, to ten wątek, który odpala inne wątki. Przynajmniej tak
się to przyjmuje w modelu obiektowym wątków, w zasadzie w tej chwili jedynym
słusznym (posix pod to oczywiście również podlega). Jak startuje mi program i
wykonuje się jego funkcja zarejestrowana jako główna, to jest w takim
przypadku jeden wątek. Jeśli spod tej funkcji, lub którejś dalej, wywołuje się
pthread_create, to ten wątek jest nadrzędnym dla tego, co się w tym momencie
tworzy. Z procesami i forkiem jest zresztą podobnie.

Natomiast inna sprawa, gdy mamy do czynienia z modelem wątków zaproponowanym
przez Maćka Sobczaka. Ale i tam model blokowania sygnałów musiałby być
zupełnie inny - nie wykluczam, że prostszy.

> Jeśli wątek miałby zakleszczyć się sam ze sobą, to odpowiednia operacja
> rzuca wyjątkiem.

No i ok.

> Wzajemne zakleszczenie kilku wątków nie jest wykrywane,

To mogłoby być trudne, chociaż nie wykluczam, że mogłoby to być możliwe.
Program musiałby jednak mieć również jeden wątek kontrolny na takie okazje.
Oczywiście pod warunkiem, że mówimy o zasobach jednostkowych (bo unix-owe
funkcje typu semget pozwalają na zabieranie wielokrotne).

> ale są reakcje na to, że wątek miałby zostać odśmiecony (co może być
> skutkiem ich zakleszczenia, jeśli nikt inny nie ma dostępu do obiektów
> synchronizujących, na których czekają)

I jednocześnie nie mający dostępu do IO?

> i na zakleszczenie wszystkich wątków.

A tu - jak? W momencie zajęcia mutexu się to sprawdza?

> > Tak - tu, jak najbardziej, ale napisałem wyraźnie: NIE odkładanie
> > reakcji na przerwanie ad calendas graecas.

> To jest kwestia przyzwoitości kodu, a nie gwarancji dawanych przez język.
> Dobrym zwyczajem jest blokowanie sygnałów tylko na krótkie chwile, ale
> nie da się tego wymusić.

Zgadza się, co więcej, nawet w C++ da się zrobić tak, że w handlerze
terminate() wywołasz main().

Ale fakt, że nie możesz normalnie kontynuować wykonania po otrzymaniu
terminate() lub unexpected() stanowi już pewne określone utrudnienie. To
stanowi zawsze odpowiednią sugestię.

PS. Swoją drogą, zauważyłem że na wszystkich tutorialach - nie sprawdzałem
dokładnie swojego pod tym względem, ale chyba jest chlubnym wyjątkiem :) -
całkowicie ŹLE tłumaczą, jak wygląda obsługa nieoczekiwanego wyjątku i wyjątku
poprzez main(), czyli sprawa unexpected() i terminate().

Funkcje set_terminate() i set_unexpected() nie służą do ustawiania własnych
handlerów wykonujących się ZAMIAST domyślnych (to nie jest "szklanka zimnej
wody jako środek antykoncepcyjny"). Handlery te wykonują się PRZED domyślną
obsługą. Inaczej mówiąc:

Wystąpienie nieoczekiwanego wyjątku powoduje wywołanie funkcji unexpected().
Wykonuje ona funkcję użytkownika, jeśli takową ustawiono przez
set_unexpected(), a następnie wywołuje terminate().

Wypuszczenie wyjątku z funkcji main() bezpośrednio wywołuje terminate().
Wykonuje ona funkcję użytkownika, jeśli takową ustawiono przez
set_terminate(), a następnie wywołuje abort().



-- 
//  _    ___         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"

On 3 Gru, 22:50, Sektor van Skijlen

> PS. Swoją drogą, zauważyłem że na wszystkich tutorialach - nie sprawdzałem
> dokładnie swojego pod tym względem, ale chyba jest chlubnym wyjątkiem :) -
> całkowicie ŹLE tłumaczą, jak wygląda obsługa nieoczekiwanego wyjątku i wyjątku
> poprzez main(), czyli sprawa unexpected() i terminate().
>
> Funkcje set_terminate() i set_unexpected() nie służą do ustawiania własnych
> handlerów wykonujących się ZAMIAST domyślnych (to nie jest "szklanka zimnej
> wody jako środek antykoncepcyjny"). Handlery te wykonują się PRZED domyślną
> obsługą.
[...]

Nie.
Funkcje podane przez użytkownika są ZAMIAST a nie PRZED.
set_terminate() ustawia funkcję, wobec której standard wymaga, aby
zakończyła program. Nie ma sensu rozważać, co się dzieje potem.
set_unexpected() ustawia funkcję, wobec której standard wymaga, aby
nie wracała i dodatkowo nakłada reguły (15.5.2/2), które reagują na
jej wyjątki - ale standardowa funkcja nie jest już wołana.

Nie ma tu żadnego PRZED. To jest ZAMIAST.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com