🚀 go-pugleaf

Sektor van Skijlen wrote:
>>Nie, nie chodziło. Chodzi o to, że w Pythonie masz a = [1, 2, 3]
>>a w C++ masz:
>>std::list a;
>>a.push_back(1);
>>a.push_back(2);
>>a.push_back(3);
> 
> 
> Super - ale (skoro, jak mówisz, w Pythonie jest dużo fajnych zbiorników) czy
> można tak inicjalizować również dowolny, napisany przez siebie zbiornik?

Tak.

>>>>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.
> 
>>Sektor zamiast chrzanić, przeczytaj sobie jaka jest różnica. Zostawiam jako 
>>zadanie domowe :)
> 
> Ha ha ha. Wielka mi różnica, że tupli nie mogę modyfikować! I to w języku, w
> którym i tak nawet głupiego consta nie da się zrobić.

consta który nie oznacza niezmienności obiektu? ROTFL!


>>>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ę).
> 
>>Bzdura.
> 
> Bo nie masz nic więcej do powiedzenia?

Bo piszesz tak oczywiste bzdury, że szkoda na to czasu.

A piszesz bzdury, bo np. te typy przez to, ze się różnią mają inne 
charakteryskytki wydajnościowe.


>>>>>>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?
> 
>>Wszystko.
> 
> "Wszystko" to znaczy "nic" albo "nie wiem".

Napisane było poniżej.


>>>>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.
> 
>>popatrz sobie na interfejs list i vector. Zrób mi vector::sort(), czy 
>>vector::splice(whatever) list::at, itd...
> 
> To ty do tej pory nie wiesz o tym, że do zbiorników swobodnego dostępu należy
> stosować algorytm introsort (czyli std::sort), a do zbiorników dwukierunkowych
> algorytm mergesort (czyli std::stable_sort),


Sektor co ty za bzdury piszesz?!?!!
Standard *nigdzie* nie mówi jaki algorytm gdzie ma być użyty. Podaje tylko 
minimalne wymagania wydajnościowe, i właśnie stabilności. A stable sort moża 
i czasem trzeba użyć i na wektorze.

> a list::sort jest to to samo co
> std::stable_sort, tylko zaimplementowany w sposób bardziej specjalizowany
> (stable_sort, tak jak sort, wykonywałby kopie wartości, a list::sort po prostu
> przestawia węzły na żywca)?

Poza tym że wyszedłeś z całkowicie błednych założeń to co z tego?


> Lista ma zaimplementowane wewnętrznie te rzeczy, które się tak zaimplementować
> opłacało ze względu na jej szczególności i specjalizację.

To było wyspecjalizowac szablon std::sort dla listy a nie robić niejednolity 
interfejs.

> To nie jest kwestia spójności zbiorników.

Jest.

> To jest kwestia koncepcji, jakie te
> zbiorniki spełniają (polecam dokumentację do STL-a).

To jest kwestia chaosu projektowego.

> Lista nie spełnia
> koncepcji zbiornika swobodnego dostępu, a jedynie zbiornika dwukierunkowego, a
> koncepcja zbiornika dwukierunkowego nie zawiera operator[] ani metody at().

No i co to ma do sort czy splice?

> Czy to jest takie trudne do zrozumienia?

Widzę, że dla Ciebie tak. Po tych bzdurach co tu powypisywałeś. Pomyli


> O tym, czy taki podział na koncepcje jest słuszny, możemy dopiero porozmawiać,
> jak będziesz wiedział, jak należy postawić problem.

Ja wiem. Ty, jak widzę, wogóle go zgubiłeś.


>>lista z C++ jest wyjątkowo do dupy. Ponawtykali jakiś rzeczy których nie 
>>powinno być (sort, merge, itp...)
> 
> I bardzo słusznie zrobili - na tej samej zasadzie, na jakiej vector posiada
> metodę reserve(), a list nie.

Zrobili do *dupy*. Od tego są specjalzacje szblonów a nie rozpieprzanie 
interfejsu.


> Może twoim zdaniem powinny one mieć wszystkie te same metody, wszystkie te
> same zależności, wszystkie te same wymagania, a nawet jeszcze niech mają taką
> samą implementację. Wtedy będą spójne. A nie, cholera, będą miały inne nazwy.

Nonsens. Zgubiłeś problem.
Operacje robiące to samo mają mieć interfejs taki sam. A nie mają.

Dlaczego map::iterator iteruje po parach a vector::iterator nie -- przecież 
oba są zbiornikami danych do których można się odwoływac po kluczu -- w 
przypadku vectora kluczem jest indeks, w mapie obiekt dowolnej 
porównowywalnego i przypisywalnego typu. Mapa powinna mieć dwa iteratory -- 
jeden po wartościach i *inny* po kluczach (tylko stały). Zbiór zaś powinien 
mieć tylko stały iterator -- po kluczach. Nie stały interator w zbiorze to 
jest w ogóle kompletna porażka.


>>A w przypadku multi_map i multi_set może być nawet (zależnie od samej 
>>implementacji kontenera) nieco szybciej szybciej zaimplementowana.
> 
> 
> A tu się zgadza - już nawet Seweryn podał implementację, chociaż mam poważne
> wątpliwości, czy rzeczywiście jest sensowna.
> 
> Tylko że akurat to jest dla mnie głupie. Nie po to pytam, żeby tylko zadać tak
> sobie pytanie, tylko dlatego, że chciałbym następnie wykonać na znalezionych
> danych jakąś operację - i to dla mnie robi equal_range.

Nie zawsze chcesz od razu robić jakąś operację. Całkiem często robi się np. 
walidację danych, itp.


>>>>>>>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?
> 
>>Ważności iteratorów po określonych operacjach.
> 
> Ty cały czas nie rozumiesz.
> 
> Ile znasz algorytmów, w których ze zbiornika swobodnego dostępu usuwa się
> elementy od końca? Ja znam tylko jeden przypadek - tylko wtedy, gdy ten
> zbiornik jest stosem.

To cienki jesteś :-P. Od końca to nie znaczy kolejne od końca. Po prostu 
jadąc od końca. Poza tym jak masz ze zbiornika 30 elementowego usunąć 
elementy 5, 13, 17 i 28 to jadąc od końca możesz to zrobić. I co ważne 
zapewne okaże się, że tak jest lepiej niż użyć map (bo samo dodanie elementu 
do map jest o 2 rzędy wolniejsze niż dodanie do vector).


>>>>>>>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.
> 
> 
>>Nie wiem jakie masz wymagania, bo ich nie podałeś. Nie wiem czy usuwasz 
>>wszystko na raz, czy też w arbitralnym momencie arbitralny kawałek. Nie 
>>podałeś też nawet rzędu wielkości danch.
> 
> 
> Przecież napisałem, że chcę je móc w szybki sposób usuwać - nigdzie nie
> napisałem, że wszystkie naraz. Sugestia, że chcę używać do czegoś określenia
> pozycji w zbiorniku powinna ci była sprawę naświetlić od razu, bo gdybym
> chciał usuwać wszystkie naraz, to nie potrzebowałbym żadnej pozycji w
> zbiorniku, tylko zrobiłbym normalnie clear(). Czy tego aż tak trudno się
> domyślić?

Nigdzie ci nie kazałem usuwać wszyskich elementów ze zbiornika. Mogłeś mieć 
np. listę elementów do usunięcia i chcieć usunąć tylko te.


> Czemu ty zamiast najpierw zrozumieć dlaczego chcę stosować taki sposób
> najpierw usiłujesz mi udowodnić, że go nie potrzebuję?

Czemu ty nie jesteś w stanie podać prostej specyfikacji tego co potrzebujesz?


>>>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ń.
> 
>>W "przestrzeni rozwiązań przemysłowych" dla dużej liczby małych struktur to 
>>sie może opłacać (struktury po kilkadziesiąt pozycji których jest wiele -- 
>>pomagamy cache locality).
> 
> 
> Tak, ale nie stosowane w taki sposób. Jeśli już, to można kombinować z
> std::deque, albo czymś podobnym (w sensie, lepiej kontrolowanym).

std::vector jest zupełnie dobrze kontrolowany i przy większej liczbie 
operacji zachowuje ważność iteratorów.

[...]
> Jeśli każdy istniejący obiekt siedzi w liście, to każdy ma zapisany swój
> iterator. W efekcie jestem w stanie każdy z nich usuwać z listy w czasie
> stałym.

A skąd mam wiedzieć, że te obiekty są jeszcze trzymane przez co innego 
(czyli jest do nich innny dostęp niż z kontenera je przechowującego)

>>Nie. Dopiero teraz coś konkretnego jest, ale i tak mało.
> 
> Przestawiłem ci nie wymagania co do działania programu, tylko wymagania co do
> zbiornika. 

Nie przedstawiłeś żadnych wystarczających wymagań.

> Jeśli nie przedstawiłem żadnych szczególnych warunków, przy których
> można poszukać odrębnego lub prostszego rozwiązania, to znaczy, że takowych
> nie ma.

Nie przedstawiłeś warunków wystarczających.


>>>ż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.
> 
>>To już powiedziałem -- słownik
> 
> 
> Jest to - jak powiedziałem - rozwiązanie spełniające, owszem, wymagania (i -
> co ciekawsze - w językach skryptowych wszyscy je stosują), niestety słabe w
> stosunku do std::list z uwagi na:
>  - konieczność generowania kluczy (wartości iteratorów std::list są same z
>    siebie unikalne na całą aplikację)

hash(object) działa całkiem dobrze.

>  - logarytmiczny czas znajdowania węzła w zbiorniku (przy stałym czasie w
>    przypadku std::list)

Ależ ten czas nie jest logarytmiczny -- jest stały (zamortyzowany) :)

>>a jak nie masz kluczy to zbiór (set).
> 
> Zbiór akurat składa się z samych kluczy i jest uogólnieniem słownika (mapy).

Raczej odwrotnie. Mapa uogólnia set. Btw w Pythonie każdy obiekt domyślnie 
może być kluczem -- trzeba by mu tego jawnie zabronić.


>>>>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.
> 
>>Akurat wskaźniki nie przeszkadzają w bezpiecznej implementacji jeśli nie 
>>masz na nich arytmetyki (a oryginalny Pascal AFAIR nie miał).
> 
> Czyżby? I masz udokumentowaną obsługę sytuacji wyjątkowej w przypadku
> zerowego lub wiszącego wskaźnika?

Mogę bez problemu mieć taką implementację. Bezpieczna implementacja C (oraz 
C++) jest praktycznie niemożliwa.


>>>>>>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.
> 
>>Ja tam mam niezły. Zwłaszcza gdy wymyślasz bzdury -- zrób sobie google 
>>python container i nie ośmieszaj się.
> 
> Zrobiłem. Tylko jestem za leniwy, żeby ci wkleić te pierwsze 10 linków i
> udowodnić, że nic nie ma na temat wspomnianego zbiornika.

Zrobiłeś? ROTFL! A 2, 5 i 6 link sprawdziłeś?


>>>>>>>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?
> 
> 
>>Fajsnie się topisz. Nie zauważyłeśm że trzecie z nich dotyczy czego innego 
>>niż dwa piersze.
> 
> 
> Aha, o tym, że niektórym zdarzało się nazywać słownik również tablicą
> dynamiczną, również nie słyszałeś?

Zapewne stosowali się do przyjętej terminologii jak autorzy STL (czyli marnie).


>>>>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>?
> 
>>To, że nie jest kontenerem booli tylko pewnego śmiesznego typu 
>>vector<bool>::reference?
> 
> I co w tym złego?

Że to nie jest referencja.

>>Ze wszystkimi tego konsekwencjami dla rzeczy takich jak non-const 
>>operator[], itd...
> 
> Jakimi znów konsekwencjami? Że trzeba się posłużyć typem pomocniczym? Że w
> ogóle da się go zrobić?

Że to nie jest bool. Że jak użyjesz tego w jakimś szblonie specjalizowanym 
na bool to możesz się zdziwić.


>>>>>>>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.
> 
>>Sorry, Sektor, Ale Koenig lookup to jest rzecz dużo późniejsza, na tyle 
>>późniejsza, że dopiero teraz kompilatory to poprawnie implementują.
> 
> Ale nie SFINAE.

To czemu SFINAE nie działało w tych częsciej używanych kompilatorach?


>>>>>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?
> 
>>Głównie z powodu przyjętych obyczajów (STL vs Smalltalk-like hierarchy). A 
>>także z braku paru dynamicznych mechanizmów (choćby refleksja, ładowanie 
>>dynamiczne klas, itp).
> 
> 
> Nie. Słabo znasz historię C++. Początkowo do C++ miały być stworzone właśnie
> takie kolekcje, z taką właśnie hierarchią, jak to jest w Javie. Zrezygnowano z
> tego w imię wydajności.

Zrezygnowano bo nie było żadnej spójnej propozycji a tylko rzeczy powyrywane 
z szerszych kontekstów (zwykle bibliotek GUI), w dodatku ścierające się. 
Taką w miarę zamkniętą propozycją (przy czym stosunkowo niedużą) był STL. To 
trochę na tej zasadzie, jak w I Rzeczpospolitej w kółko wybierano obcych na 
królów -- miejscowi nie mogli się zgodzić, by jedez z nich nagle był lepszy 
oid innych.

[...]
>>>>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.
> 
>>Statyczność jeżyka to jest właśnie statyczna kontrola! Obliczenia zawsze są 
>>dynamiczne, nawet w Sparku.
> 
> Jakie obliczenia i jaką kontrolę masz tu na myśli?

Ma na myśli "pracę programu" zaś kontorlę w czasie kompilacji.

>>>>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ą.
> 
>>Akurat statyczna kontrola wyjątków by wiele nei zmieniła. Wyjechałoby 
>>unexpected. Bo to że teraz można zrobić:
> 
> 
>>void foo() throws();
>>{
>>   throw bar;
>>}
> 
> 
>>jest wyraźną niekonsekwencją języka.
> 
> 
> Tu się zgadzam, że kompilator mógłby przynajmniej postarać się o ostrzeżenie
> (ale ponieważ wszystkie autorytety dzisiaj zgodnie olewają specyfikację
> wyjątków w C++, to i wartość biznesowa tego ficzera jest zbyt niska).

Przy dynamicznej kontroli kompilator może co najwyżej postarać się -- ale 
niegdy nie odfiltruje każdej sytuacji. Żeby mógł, potrzebna byłaby statyczna 
kontrola specyfikacji (jak w Javie).


> Jedynym sensownym sposobem na statyczne sprawdzanie wyjątków byłby analizator
> kodu, który sam sprawdza, jakie wyjątki są rzucane przez jakie funkcje. I
> dodatkowo, żeby produkował z tego raport, na bazie którego kompilator mógłby
> dokonać optymalizacji.

Co nie działałoby w przypadku zewnętrznych binarny-only modułów. (Bo wyjątek 
może lecieć gdzieś w sródku i może to nie być reprezentowane w żadnym pliku 
nagłówkowym).


[...]
>>Pobaw się trochę z sygnałami na systemie bez NPTL a poitem z NPTL :)
> 
>>Albo choćby taki "szczegół" jak get_pid() :)
> 
> Ano to ja wiem, że implementacja LinuxThreads jest niezgodna z POSIX. Ale
> szczęściem nie mam dziś nigdzie w użyciu systemu z jądrem sprzed 2.6.

Ty nie, ale się trafia.


>>>>>>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.
> 
>>Co się nie nadaje? To się zachowuje całkowicie deterministrycznie. Zarówno 
>>na windowsach, gdzie jest SEH jak i nauniksach, gdzie masz sygnały moża 
>>rzecz załatwić na poziomie runtime języka.
> 
> 
> Rzecz w tym, że to nie takie proste.
> 
> Nie każdy system posiada systemową implementację takiej np. malloc. Czy dziś
> jakieś systemy nie mają - tego nie wiem, ale w którymś ze starszych
> posixowych systemów funkcja malloc była normalną funkcją użytkownika i sama
> zarządzała zasobami, w kwestii systemu poprzestając jedynie na sbrk().

Nadal malloc jest funkcją użytkownika tylko nie koniecze z systemu woła się 
sbrk(). Tylko co to ma do rzucania GPF przy odwołaniu pod adres 0? Na 
Windzie mie działa, na Linuksie takoż.


> Co
> oznacza np., że aplikacja nigdy nie oddawała do systemu przydzielonej pamięci,
> a także przydzielała przez sbrk() większe bloki i wydzielała kawałki tortu z
> jej środka. W takim przypadku niemożliwe jest określenie, czy odwołanie do
> określonego miejsca w pamięci odwołuje się do przydzielonego kawałka, czy nie.

Mówiliśmy od odwołaniu do NULL a nie do dowolnego kawałka.


> Anyway, nie wiem, czy nie wystarczyłoby coś w rodzaju platformy w podobnym
> stylu, co robi C#. W sensie, że niby masz ograniczenia platformy, ale i tak
> program wykonuje się na platformie natywnej.

???
Program C# jest kompilowany do CIL i wykonuje się na VM z .Net. Ta VM jest 
realizowana całkiem wydajnie jako JIT ale wirtualizacja cały czas jest. Że 
są wyjścia unmanaged do poziomu platofrmy natywnej? W Javie też możesz tak 
sobie zrobić.


>>>>>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.
> 
>>Akurat można sobie zogranizować komunikację między procesami też żeby była 
>>zupełnie wygodna.
> 
> 
> I tworzyć np. obiekty w dzielonej pamięci? Nie bardzo mi się to widzi.

Na wielu OS możesz mieć te same adresy logiczne po obu stornach -- wtedy 
całkiem normalnie to się robi.


> Nie bez powodu stworzono normalny mechanizm wątków - gdyby komunikacja
> międzyprocesowa wystarczała, nikt by tego nie tworzył.

Kiedyś wydawało się, że tak będzie super. Bo przełączanie ciężkich 
kontekstów było wooolne, mechanizmy dzielonej pamięci bardzo ograniczone. 
Tak miało być dużo szybciej.

Dziś takie rzeczy jak MPI pokazują że szybciej nie jest. Lepsze wsparcie dla 
pamięci dzielonej, np. poprzez memory mapped files pozwala na zrobienie 
wspólnego okna w przestrzeniach adresowych wielu procesów, gdzie wskaźniki 
zachowują się normalnie. A przełączanie kontekstów nie jest już tak istotne 
z uwagi na to że procesory są szybsze a systemy lepiej zoptymalizowane.

[...]
>>>Ależ oczywiście, że chodzi o oba. Zresztą znaczenie 'volatile' w Javie i w C++
>>>jest identyczne\
> 
>>Ależ skąd!
> 
>>>(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).
> 
>>Chyba coś zmyślasz... Volatile które ma semantykę acquire/release? W GCC??? 
>>Takie volatile to jest sobie w MSVC z VS.NET 2005, ale nie w GCC.
> 
> To zależy.

Nie bardzo zależy. W Javie volatile jest ściśle wyspecyfikowane -- odowłanie 
do takiego pola oznacza na natywnej platformie wystosowanie odpwoiednich 
barier pamięci (acquire przed i release po odwołaniu). W GCC nic takiego nie 
ma. Jak architektura nie ma strict memory ordering to wszystko się rozjeżdża.

>>A w standardzie C++ volatile dotyczy tylko i wyłącznie sygnałów i nic 
>>więcej. O wątkach nie ma mowy bo takie pojęcie w C++ nie występuje
> 
> To się akurat zgadza.

I tu jest różnica w stosunku do Javy. Sygnały są wykonywane zawsze w tym 
samym kontekscie (na tym samym rdzeniu) co proces.

pzdr
\SK