🚀 go-pugleaf

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