🚀 go-pugleaf

Dnia Thu, 29 Nov 2007 13:43:43 +0100, Sebastian Kaliszewski skrobie:
> Sektor van Skijlen 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?
> > 
> >>Ddaj do tego for, składnię dla splajsów, itd...
> > 
> > ... która dobrze prezentuje się w tutorialach, ale w praktyce nie ma
> > różnicy, czy ten lukier składniowy jest, czy nie?

> Lukier skłądniowy toi jest właśnie element "wpasowania do języka"

To chyba mamy inne definicje pojęcia "wpasowania do języka".

Może chodziło ci o "zawarcie w definicji języka"?

> >>>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.
> > 
> >>Nie jedyny. Tu masz jeszcze tuple, słownik i zbiór -- czyli cały podstawowy 
> >>zestaw. W bibliotece masz jesczcze następne (np talię).
> > 
> > Ach i och. Perl i Tcl jako tuple wykorzystują ten swój podstawowy zbiornik,
> > zwany (akurat w obu) listą.

> Och i ach. Python nie.

No to ma problem na własne życzenie. Żaden z języków skryptowych "starej
szkoły" takich debilizmów nie robi. Tego typu podejście jest pożądane tylko w
językach, które mają większe rygory bezpieczeństwa, ale one sprawdzają to i
tak w czasie kompilacji (bo sprawdzanie tego w czasie wykonywania to pic na
wodę).

> >>Tylko czemu interfejs jest tak parszywie niejednolity? begin/end to trochę mało.
> > 
> > Jak to niejednolity! Jest cholernie jednolity.

> Ależ skąd. Jednolite w miarę są pary vector i deque, map i multimap oraz set 
> i multiset.

A co jest niejednolitego w vector i list?

> map wyłazi zupełnie z jej iteracją po parach. list jest w ogóle 
> w poprzek, itd...

> O jakiś spójnych gwarancjach już lepiej nie myśleć.

Nie rozumiem nadal. Nie podałeś ani jednego konkretu. Opisanie które zbiorniki
są twoim zdaniem niejednolite nic nie znaczy.

> > Do tego stopnia, że nie da się
> > zrobić standard-conformant listy jednokierunkowej (pojedynczo wiązanej), a
> > niektóre ciołki (jak np. autor języka D) nie rozumie, dlaczego do sprawdzania
> > czy string jest pusty trzeba robić if ( s.enpty() ), zamiast normalnie
> > if ( s.size() ).

> To dlaczego dla sprawdzenia czy w mapie jest klucz trzeba robić 
> m.count(keyVal) zamiast m.has_key(keyVal)? Dlaczego "niektóre ciołki" takie 
> jak członkowie komitetu nie rozumieją?

Zastanów się najpierw, o co właściwie pytasz:
1. Dlaczego wybrano nazwę 'count', a nie 'has_key'
2. Dlaczego 'count' nie ma aliasa o nazwie 'has_key'

Mam nadzieję, że pytasz o #2, bo pytanie o #1 jest głupie z zasady.

Na to wytłumaczenie jest takie, że ludzie mają często nieuzasadnione opory
przed robieniem "aliasów" nazw. I tak pewnie komitet z trudem przebolał
pozostawienie basic_string::length jako alias do size. I tak niestety zawsze
będzie, mimo negatywnych doświadczeń ntt. z przeszłości (w wyniku czego np.
jedyna funkcja w bibliotece standardowej języka C (I to również w ostatnim
standardzie!), za pomocą której można porównać dwa stringi to strcmp, znana z
nielogicznego, błędogennego i nieczytelnego interfejsu).

Ja się z tym nie zgadzam, i uważam, że zrobienie funkcji has_key:

bool has_key( const KeyType& k ) { return count( k ) > 0; }

ma jak najbardziej sens, bo nazwa has_key lepiej oddaje intencje, niż count w
przypadku std::map i std::set.

> >>>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.
> > 
> >>Po każdej po której zmienia się capacity. capacity zaś zmienia się tylko 
> >>czasami.
> > 
> > Weź ty się z łaski swojej nie ośmieszaj, dobrze?

> sam się ośmieszasz. Te gwarancje są po to, by można było określone 
> konstrukcje wykonać.

Konkretnie które gwarancje?

> > Gdybyś mi zrobił kod, w którym w jakikolwiek sposób polegasz na stabilności
> > wartości iteratorów do wektora po DOWOLNEJ modyfikacji tego wektora to razem z
> > tym kodem odesłałbym cię na zieloną trawkę.

> Czyli nie umiesz się nawet tą przyszywaną tablicą twojego języka posłużyć.

Oj, brzydko się chwytasz.

> >>>Miałem właśnie
> >>>ostatnio taki przypadek, że musiałem trzymać iteratory do elementów, żeby je
> >>>móc szybko usuwać.
> > 
> >>To możesz trzymać indeksy elementów i usuwac po begin()+index.
> > 
> > A, jasne, oczywiście! Usunięcie elementu ze środka też oczywiście nie zmieni
> > mi względnego położenia obiektów od tego miejsca w dal.
> > 
> > Czy ty na prawdę tak na siłę chcesz coś udowodnić, że aż nie omieszkasz się
> > kompromitować?

> Akurat usuwanie z vectora można robić jadąc od rbegin do rend i robiąc 
> zwykłe erase. To jest gwarantowane przez język.

Sebek, do jasnej cholery, mam takie wymagania, że dowolny obiekt ze zbiornika
może być usunięty w dowolnym czasie. A ty mi tu proponujesz jakieś śmieszne
usuwanie od końca?

> Tyle że jest to mało wydajne i nie ma nic wspólnego z szybkim usuwaniem.

To nie ma nic wspólnego z jakimkolwiek usuwaniem, ani z jakąkolwiek mającą
sens operacją, jeśli rozpatrujemy przestrzeń rozwiązań przemysłowych, a nie
akademickich rozważań.

Ale mnie to oczywiście bawi, śmiało brnij dalej.

> Szybkie usuwanie ze środka i vector nie idą w parze -- jak chciałes to 
> pożenić to sam się ośmieszasz.

A, oczywiście, ośmieszam się.

Z tą tylko różnicą, że jak na razie to wyłącznie ty usiłujesz udowadniać, że
się te dwie rzeczy da pożenić, bo ja od początku mówiłem, że się nie da i
właśnie dlatego wybrałem list.

> >>>Podpowiesz mi może, jakiego rozwiązania powinienem użyć w Pythonie?
> > 
> >>wbudowanej listy albo deque -- zależnie co robisz.
> > 
> > Szczegółowo proszę - jak mogę przechowywać wartość, która będzie mi określała
> > pozycję elementu w zbiorniku i dopóki ten element będzie w zbiorniku, nie
> > zmieni się nigdy po jakiejkolwiek modyfikacji tego zbiornika.

> Zmieniasz wymagania.

Brnij dalej.

> PRzy takich użyj słownika i już.

A, no oczywiście, najlepiej użyć słownika - po co mi stały czas operacji
usunięcia elementu, wystarczy przecież logarytmiczny, a konieczna na wszelki
wypadek obsługa błędu nie znalezienia elementu to przecież drobny szczegół.
Nie wspomnę o generatorze unikalnych kluczy.

> A jak chcesz ni po dowolnej tylko przy usuwaniu i możesz mieć dla tego
> usuwania określoną kolejność to usuwaj od końca i odwołuj się po indeksach
> (tak samo zrób w C++).

Ubaw po same pachy.

Sebek, zrozum: obiekty trzymane w liście to są obiekty reprezentujące
połączenia sieciowe użytkowników. Mówisz: zmień wymagania. Czyli co mam
zrobić, trzymać obiekty połączeń nie usunięte dotąd, aż zbierze się grupa
zdechłych połączeń od samego końca wektora, czy też mam przykazać
użytkownikom, żeby nie rozłączali połączeń, jeśli po nich jest jeszcze ktoś
połączony?

> > Jak już dyskutujemy, to dyskutujmy konkretnie - jeśli masz jakieś sensowne
> > zarzuty, to je poprzyj. Na razie uciekasz w kąt.

> Narazie to ty jesteś nikonkretny.

Przedstawiłem ci wystarczające minimum wymagań, żeby można było pod to
podpasować konkretne rozwiązania: chcę mieć zbiornik taki, którego elementy
będą miały węzły o stałej pozycji (wyrażanej odpowiednią wartością) nie
zmieniającej się w przypadku zmiany liczbności zbiornika (poza usunięciem tego
właśnie elementu).

Zbiornik taki, jak np. mapa (słownik) spełnia te wymagania, ale jest od
std::list niezaprzeczalnie gorszy, bo:

 - złożoność dostępu jest logarytmiczna
 - istnieje potencjalny błąd nieznalezienia elementu
 - istnieje konieczność użycia generatora kluczy

Nadal czekam na propozycję rozwiązania tego w tym wszystkowyrażalnym 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?
> > 
> >>Ze dwa się ostały. Czasem pod smutowaną postacią, ale są.
> > 
> > No więc czym przepraszam chcesz uzasadnić twierdzenia, jakoby bezpiecznych
> > języków ktokolwiek potrzebował?
> > 
> > 
> >>>Powiedz, o które języki ci chodzi, to będziemy przynajmniej wiedzieli, na czym
> >>>stoimy.
> > 
> > 
> >>Pascal, Algol68, Lisp.
> > 
> > 
> > Pascal? Bezpieczny? Chyba jaja sobie robisz.

> Nie robię. Bezpieczna implementacja Pascala jest możliwa i jest naturalna. W 
> odróżnieniu od bezpiecznej implementacji C czy C++.

Jasne - po pozbawieniu Pascala np. wskaźników.

> >>Co do przykładu -- na sieci pełno.
> > 
> > To znajdź i wklej - dopóki tego nie zrobisz, dla mnie bredzisz od rzeczy.

> Nie jestem proxy do google. Oczywistości szukaj sobie sam.

Twoje oczywistości to dla mnie brednie - i obaj wiemy, że tylko ja mam z tego
ubaw.

> >>>Co nazywasz "resztą świata" - Javę, czy Lispa?
> > 
> >>Javę, Smalltalka, skryptowce, itd...
> > 
> > Javę, powiadasz? Tam, gdzie mapa nazywa się Map, a strumień Stream?
>  >
> > Smalltalk to dla ciebie jest licząca się reszta świata?
> > Skryptowce, wśród których masz Tcl-a z Tablicą, Perla z Haszem i Pythona ze
> > Słownikiem?

> Masz jeszcze coś takiego jak ogólnie przyjętą nomenklaturę, reprezentowaną w 
> literaturze. Tu jest słownik lub tablica asocjacyjna, tablica dynamiczna itd.

I chcesz mi może tym stwierdzeniem uzasadnić, że istnieją jakieś "bardziej
ustandaryzowane" terminy obrazujące te pojęcia, skoro w powyższym zdaniu
użyłeś już różnych trzech?

> >>>>>>>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,
> > 
> >>Których nikt za wczasu nie przemyślał.
> > 
> > Możliwe, ale nie sądzę, żeby się to dało zrobić w jakikolwiek sposób inaczej.

> Dałoby się, gdyby całość zaprojektowano a nie zrodzono z chaosu. Jak są 
> idiotyzmy w stylu vector<bool> to być może nie bardzo da się inaczej, by to 
> jeszcze było używalne jakkolwiek.

A co złego jest w vector<bool>?

> >>>a SFiNaE było od samego
> >>>początku podstawą funkcjonowania szablonów w C++.
> > 
> >>I wszelakich tricków na nich opartych. Ale od początku to toto nie było. 
> >>Zobacz takie MSVC 5.0 -- tu np. nie działało.
> > 
> > Oczywiście, że działało (jeśli oczywiście mówimy o M$VC 5.0 + SP2, które
> > obsługiwało np. przestrzenie nazw).

> Oczywiście, że nie działało. Namespejsy do nie świniae.

Ja wiem, bo używaliśmy tego w Aldecu, a jeszcze ZANIM tam przyszedłem (w
morde, to ok. 10 lat temu :), Wojtek Surówka tu na tej grupie udowadniał
Andrzejowi Lewandowskiemu, wykorzystując właśnie świniae, że wzorce nie dają
się żadną miarą porównać do makrogeneratora. Kod, który zacytował, nie działał
mi na ówczesnej wersji gcc (bo w tej wersji gcc świniae jeszcze nie działało),
więc domniemam, że został sprawdzony właśnie na VC5.

O ile sobie również przypominam, w Aldecu napisałem też jakiś kod, który
wykorzystywał świniae. Ale nie wiem, czy nie eksperymentalnie (ten kompilator
miał swoją drogą tyle bugów i braków, że co i raz trzeba było iść na jakiś
kompromis; w jednym z modułów nawet wpuściłem kopię stringa z gcc jako
gnu::string, bo ten, co tam był std::string nie dawał możliwości
zaprogramownia złożonych operacji na stringach bez wylotu).

> >>>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.
> > 
> >>Wydawało? Czy się raczej wyłoniło się z chaosu (poprzedzających implementacji).
> > 
> > Z tego, co BS napisał w "DAEC++", rozważano wiele możliwości, jeśli chodzi o
> > sprawdzanie dopasowania wzorców. Okazało się, że takie będzie najmniej
> > kłopotliwe.

> W zastanej sytuacji chaosu istniejących implementacji.

Nie było jeszcze żadnych implementacji, kiedy to rozważano. Nie mogło być, bo
omawiano tam całkiem podstawowe kwestie (takie jak np. czy używać template
<class T> class X, czy class X<T>, jak w Javie jest to teraz), których nawet
nie można by poddać pod rozważanie, gdyby jakiekolwiek implementacje już
istniały.

> >>>Właśnie ostatnio się o tym przekonałem. Java, jako jedyny język z grupy
> >>>Java/C#/C++, posiada ścisłe wyjątki.
> >>
> >>[...]
> >>
> >>>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?
> > 
> > 
> >>Ze specyfikacjami wyjąytków to jest tak, że zwalono je zarówno w C++ jak i w 
> >>Javie, przy czym statyka Javowa lepiej pasuje do C++ a dynamika z C++ do Javy.
> > 
> > Wyjątki są dynamiczne, czy tego chcesz, czy nie.

> Ale ich specyfikacje mogą być mniej lub bardziej dynamiczne.

Niespecjalnie. Chyba że mówimy o statycznej weryfikacji wyjątków, ale to w
semantyce wyjątków niczego nie zmienia.

>   Pytanie tylko, na ile chcemy
> > mieć do nich statyczne wsparcie, bo trzeba sobie zdawać sprawę z tego, że
> > wszelkie statyczne wsparcie to potencjalne utrudnienia dla użytkownika.
> > 
> > Poza tym, Java nie jest wcale taka znów dynamiczna. Nie widzę w tym względzie
> > żadnych większych różnic od C++.

> C++ (zwłaszcza modern) dużą większy nacisk kłądzie na statyzm.

Z powodu wzorców?

> A specyfikacje wyjątków są nie z tego ni z owego sprawdzane dynamicznie.

Nie "ni z tego ni z owego", tylko dlatego, że inaczej nie jest to możliwe do
wykonania.

> Za to Java w której jest istotny odsetek elementów dynamicznych ma nagle
> statyczną kontrolę wyjątków.

Poza statyczną kontrolą - która do samego działania wyjątków niczego nie wnosi
- nie ma tam nic statycznego.

> Jakby było odwrotnie to byłoby lepiej, co nie znaczy że byłoby dobrze :)

Nie widzę związku - jakby C++ miał statyczną kontrolę wyjątków, to ludzie
nienawidziliby go jeszcze bardziej :). Natomiast brak ten kontroli mógłby
pomóc Javie, ale to nie ma znaczenia, skoro programiści i tak Javę kochają.

Kwestia statycznej kontroli wyjątków nie ma akurat żadnego znaczenia dla
statyzmu wyjątków, skoro ich działanie jest typowo dynamiczne tak czy siak.
Fakt, że variadic templates mogą ułatwić dodawanie specyfikacji wyjątków,
wciąż nie powoduje, że ścisła specyfikacja wyjątków nagle nabierze sensu.

> > Cóż, trudno mi się nie zgodzić :)
> > 
> > Ale linuxowe implementacje akurat takich problemów nie mają (na szczęście, bo
> > inaczej to nie wiem, gdzie bym tą aplikację uruchomił!).

> Linuksowe jak najbardziej mają sporo problemów. Zwłaszcza jak gdzieś jeszcze 
> uchował się system sprzed NPTL.

Nie zauważyłem.

> > Myślałem nawet, żeby podesłać tą moją aplikację ludziom od Cygwina, żeby sobie
> > poprawili - ale niestety o uwolnieniu tego kodu to trzeba by ewentualnie
> > później pomyśleć, bo na razie niestety nie ja jestem jego właścicielem.

> A nie da się wyekstachować/zsyntetyzować tylko przykładu demonstrującego 
> kaszanę?

No właśnie byłby z tym problem, bo i tak z trudem jestem w stanie
zreprodukować to na pełnowartościowym programie. A nawet gdyby udało się to
wyekstrahować, to i tak musiałbym negocjować z firmą możliwość udostępniania
tego komukolwiek. Nieważne, czy to fragment, czy to całość - właścicielem kodu
jest firma.

> >>Ani o tym ani o tym. Chodzi o to, by błędy wykonania były "contained". Niech 
> >>sobie będzie abort, wyjątek, cokolwiek, ale niech po pierwsze będzie a po 
> >>drugie niech będzie tylko to (a nie losowa poprawka do przetwarzanych danych).
> > 
> > Dobrze, nawet się zgadzam. To teraz przystaw to do praktycznych możliwości
> > realizacji powyższych założeń.
> > 
> > Jeśli chodzi np. o odwołanie się do zerowego wskaźnika, to masz tu dwie
> > możliwości: albo w języku sprawdzasz wskaźnik przed każdym odwołaniem
> > (usuwając jedynie zbędne sprawdzenia, gdy jest to bezużyteczne), albo
> > posiadasz platformę wirtualną, na której uruchamiany jest program, i która to
> > platforma sama posiada odpowiednie właściwości pozwalające na wygenerowanie
> > wyjątku w takim przypadku. W obu przypadkach mamy do czynienia z dodatkowym
> > narzutem, który jest tylko czasem akceptowalny.

> W większości systemów nie embedded masz tą wirtualizację daną z góry i nie 
> masz wyboru.

Ale to się do niczego nie nadaje.

> > Wątki po prostu powinny pracować na niezależnych danych.

> Wtedy mogą być równie dobrze procesami. Tzn. niech mają osobną przestrzeń 
> adresową i już.

Gdyby na ZUPEŁNIE niezależnych danych pracowały, to wtedy tak, co więcej,
takie procesy nawet nie wymagają komunikacji.

Ale - jak to napisałem gdzieś - jest to sytuacja idealna, której na dodatek
nikt nie zamierza osiągać. Im mniej danych wątki wymieniają między sobą, tym
lepiej, ale jeśli nie wymieniałyby ich w ogóle, to istnienie wątków traci
sens.

Chodzi więc o to, że w przypadku wątków dane przekazuje się znacznie wygodniej
i wątki mogą raz na jakiś czas korzystać z tych danych. Nie powinny jednak na
nich "pracować" to znaczy odwoływać się do wspólnych danych przez cały czas
swojej pracy.

> [...]
> > Mało co prawda napisałem w życiu aplikacji z użyciem wątków, ale jak na razie
> > zawsze obchodziłem się bez muteksów. Używałem jedynie volatile.

> Rozumiem, że chodzi o volatile z Dżawy, nie to cóś z C/C++.

Ależ oczywiście, że chodzi o oba. Zresztą znaczenie 'volatile' w Javie i w C++
jest identyczne (jeśli oczywiście uwzględnimy fakt, że gcc ma rozszerzenie w
stosunku do standardu, co pozwala zmiennym oznaczonym volatile pracować
poprawnie z posix threads).


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