🚀 go-pugleaf

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"


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


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

> 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ą?



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


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


>>>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.
Tyle że jest to mało wydajne i nie ma nic wspólnego z szybkim usuwaniem.

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


>>>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. PRzy takich użyj słownika i już. 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++).


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


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

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


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


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


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



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

  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. A 
specyfikacje wyjątków są nie z tego ni z owego sprawdzane dynamicznie. Za to 
Java w której jest istotny odsetek elementów dynamicznych ma nagle statyczną 
kontrolę wyjątków.

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


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

> 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ę?

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


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

[...]
> 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++.

pzdr
\SK