🚀 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"
> 
> To chyba mamy inne definicje pojęcia "wpasowania do języka".
> 
> Może chodziło ci o "zawarcie w definicji języka"?

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


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

Sektor zamiast chrzanić, przeczytaj sobie jaka jest różnica. Zostawiam jako 
zadanie domowe :)


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


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


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

lista z C++ jest wyjątkowo do dupy. Ponawtykali jakiś rzeczy których nie 
powinno być (sort, merge, itp...)


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

2

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

A w przypadku multi_map i multi_set może być nawet (zależnie od samej 
implementacji kontenera) nieco szybciej szybciej zaimplementowana.


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


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

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.


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

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

Musz więc gdzieś przechowywać pozycje tych elementów albo masz znowu liniowy 
koszt usuwania.


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

A skąd mam to wiedzieć,

> Mówisz: zmień wymagania.

Mówię, że zmieniasz wymagania albo ich nie podajesz.

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

Nie. Dopiero teraz coś konkretnego jest, ale i tak mało.


> ż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 a jak nie masz kluczy to zbiór (set).


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

Akurat wskaźniki nie przeszkadzają w bezpiecznej implementacji jeśli nie 
masz na nich arytmetyki (a oryginalny Pascal AFAIR nie miał).


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



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


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

To, że nie jest kontenerem booli tylko pewnego śmiesznego typu 
vector<bool>::reference?

Ze wszystkimi tego konsekwencjami dla rzeczy takich jak non-const 
operator[], itd...


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

Ja pamiętam jaja z MSVC i z tym, że jak jakaś, nawet nieużywana, metoda 
szablonu oczekiwała czegoś od parametyzującego typu to to w tym typie 
musiało istnieć. To jest zaprzeczenie SFINAE.


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


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

Właśnie od tego są specyfikacje wyjątków. Tez z C++ są dynamicznie 
kontrolowane a te z Javy statycznie. W obu przypadkach wbrwe charakterom 
języków.


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

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

To jakim cudem to działą w Dżawie??? Sektor, nie wypisuj głupot.


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


>>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. W Javie byłoby to bardziej na mijescu 
niż w C++.


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

Wszelkie obliczenia s a dynamiczne tak czy siak. Co nie znaczy że typy na 
których są oparte są dynamiczne.

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

Pobaw się trochę z sygnałami na systemie bez NPTL a poitem z NPTL :)

Albo choćby taki "szczegół" jak get_pid() :)


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


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

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

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.

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

pzdr
\SK