🚀 go-pugleaf

Witam

Seweryn Habdank-Wojewódzki wrote:
> Czemu zawsze kłócimy się o to samo?

Fatum? ;)


>>>Wskaźnik przecież może pokazywać na NULL? Przecież wskaźnik nie wie czy
>>>obiekt się zmienił (wzorzec obserwator się kłania).
>>
>>Jaki obserwator? Obserwator to jest bardzo złe rozwiązanie takiego
>>przypadku. Obserwator służy do rozprowadzania zdarzeń (edge triggered) a
>>nie udostępniania informacji o bieżącym stanie (level triggered).
> 
> 
> Obojętne czy obserwator czy nie. Zapewne masz rację że są lepsze podejścia.
> Ale one nie są jedyne. Czy kod który zaproponowałeś poniżej jest jedyny
> słuszny? Jeśli tak, to powinien wejść w skład jakiejś biblioteki.

To jest wzorzec (konkretniej przykład zastosowania wzorca) -- wzorce mają to 
do siebie, że słabo wchodzą w skład jakiejś biblioteki (chyba że mówimy o 
bibliotece książek). Bo w niektórych kontenerach wystarczy w testamencie 
bool, a w innych przyda się jakaś dodatkowa informacja (np. zakres, przy 
czym zmiana zakresu nie musi oznaczać uniważnienia iteratorów).

> Jeśli nie to ile ma wariantów. Jeśli dużo, to czemu się dziwisz, że lepiej
> mieć osobno iterator osobno kontener, a takie coś budować na własne
> potrzeby? 

Do istniejących kontenerów tego już się nie daje sensownie dołożyć. To musi 
być wbudowane, rozłożone pomiędzy kontener i pasujące do niego iteratory (bo 
  w C++ masz często 4 typy iteratorów dla jednego typu kontenera: forward i 
reverse, oba w wersji const i non-const),


> Tobie zawsze coś nie pasuje. ZAWSZE masz 3 ale i 5 że do każdej rzeczy w
> C++.

???

> W Pythonie są jedyne słuszne rozwiązania np. jedyna słuszna lista i
> nie płaczesz?

W Pythonie mam rozwiązania bardziej elastyczne. W C++ std niby jest 
konfigurowalne i w ogóle, ale jak przyjdzie co do czego to użycie wersji 
niebazowych idzie jak po grudzie (bo np. do niczego te niebazowe wersje nie 
pasują)


> A w ogóle pokaż mi co w Pythonie jest tym Testamentem? W
> itertoolsach są różne rzeczy ale testamentu nie widzę, sama lista też nie
> ma testamentu?

W Pythonie iterator zna blisko obiekt iterowany i nie ma invalidacji 
iteratorów. W Pythonie nie ma też problemu z przedwczesną śmiercią obiektu 
iterowanego (dzięki GC).


>>>Pan F. nie pokazuje jak coś nie działa i jest to zrobione w dobrym stylu
>>>C++.
>>
>>Użycie iteratorów jest w złym stylu C++ ???
> 
> On nie użył iteratora!

Jak nie jak użył?

Coś mi się zdaje, że zapomniałeś o której stornie pisałeś.


>>>Iterator przede wszystkim ma być efektywną abstrakcją, a nie kombajnem.
>>
>>A potem płacz, że jakiś gówniarz włamał się i wszystko pokasował. Albo, że
>>odcieli od Internetu, bo komputer był shackowany i rozsyłał spam.
> 
> 
> Ha, ha, ha. ZTCW to włamy są przede wszystkim do websajtów pisanych w PHP.

Włąmy to są przede wszystkim na domowe pecety, chodzące pod kontrolą softu 
pewnego dużego producenta pisanego głównie w C i C++.

To stąd jest rozsyłany spam, wykonywane ataki ddos, itd. Tędy też rozłażą 
się robale i wirusy.


>>>Tak. A i tak kolesie pokroju Pana F. nie używają jej -- przykład tablica
>>>obiektów typu foo rzutowana na bar*.
>>
>>To czemu język na to pozwala?
> 
> A Python pozwala kasować metody, czemu?

Bo jest dynamiczny.

> Czemu nie ma sekcji prywatnej w klasach?

Została uznana za zbędną w języku o filozofii jaką reprezentuje Python

> Czy python zakłada dobrą wolę kodera? Słusznie. 

Tak.

> C++ zakłada, że języka używa wykształcony koder, a nie gamoń.

C++ zakłada, że koder zna wszystkie pułapki. W Pythonie droga hackerska jest 
praktycznie zawsze trudniejsza od drogi rozsądnej, oczywistej.
W C++ z zasady droga oczywista jest ścieżką na manowce.


> Nie odpowiadasz na pytania, które są niewygodne, czemu?
> 
> 
>>>Poza tym już nie traz narzekałeś na STL więc skąd nagle gadanie o tym,
>>>że "zrób se sam" jest złe? Pan F. jak widać STL'a nie używa tak jak to
>>>należy robić -- jedyne co potrafi to napisać baziewny kod, aby wykazać,
>>>że gcc generuje długie błędy.
>>
>>Skąd wiesz czego on używa a czego nie?
> 
> 
> Bo przykłady są wyssane z palca!

Przykłady mają na celu pokazanie konkretnych błędnych lub błędogennych 
rozwiązań.

> Pisze, że lubi C, a tam takie "haki" są na
> porządku dziennym. Do tego, w C++ często da się "hak" zastąpić jakimś
> zgrabnym kodem. W C często "hak" to jedyna wersja.

Przy hakach z C++ to to jest zabawa.


>>>Pokaż mi takie cos jak MPL i SPIRIT w J i w Py.
>>
>>W Py masz PyParsing.
> 
> To jest odpowiednik spirita, a mpl?

W języku dynamicznym cały język to mpl.


>>MPL to jest chore same w sobie.
> 
> Dla Ciebie. Dla mnie nie. Widocznie mamy inne punkty widzenia. Jakbyśmy
> mieli takie same, to byśmy się nie kłócili :-D.

MPL to jest nadużycie przypadkowej Turing-completeness szablonów. Jest więc 
dziwne w użyciu a rzucane błędy kompilatora są "zabawne". No i zobaczyć 
build aplikacji trwający 3 dni -- bezcenne :)


>>>Parsery wszędzie pisze się parszywie.
>>
>>Taaa, zwłaszcza w Ocamlu... Albo w Pythonie
> 
> W Ocamlu to w ogóle wszystko elegancko się pisze -- język ten zdominował
> rynek. Przepraszam, ale wolę Pythona, czy Haskela.

W Haskelu też będzie łatwo.


>>>>W C są wyjątki??? iteratory??? desytuktory????
>>>
>>>Nie ma. Są za to inne kwiatki.
>>
>>Te kwiatki są proste i ograniczone jak samo C.
> 
> Nie są, ani proste, ani ograniczone, a zakres błędów który może powstawać
> jest duży.

Ale te same błędy w C++ zostają przykryte kołderką (również pełną dziur) 
wyżejpoziomowych abstracji.

W C druty i bebechy są na wierzchu. Jak coś się wali to mechanizm tego jest 
też na wierzchu. W C++ już nie ma tak lekko.


>>Ale nie wszędzie kod najbardziej oczywisty jest kodem niebezpiecznym i
>>niestylowym. To jest domena C++.
> 
> Zapewne. To niech lewary nie piszą w C++! Nie wszyscy maja maturę, nie
> wszyscy kończą studia, nie wszyscy muszą pisać w C++. 
> Nikomu nie każe pisać w C++.

Ale przez te wszystkie nieoczywiste drogi, nawet nie-lewary popełniają, 
często bardzo poważne a zarazem trudne do znalezienia, błędy.


>>>Tak? A gdzie to jest normalny zwyczaj?
> 
> Nie odpowiedziałeś na to pytanie!

W większości języków. W C++ problem własności urasta do jednego z 
najważniejszych -- zupełnie niepotrzebnie, ale taki jest projekt(?) języka.


>>>Jeśli gdzieś są takie zwyczaje to 
>>>kończy się to na posiadaniu GC.
>>
>>I dobrze. GC znane jest od ponad 40 lat.
> 
> To nie jest odpowiedź na moje pytanie.

Problem własności rozwiązauje się właśnie za pomocą GC, lub reference countingu.


>>>To jest właśnie poziom haków Pana F.
>>
>>Nie, pan F. pokazuje rzeczywiste przypadki rzeczywistych kardynalnych
>>błędów projektu samego języka, a to jest pokazanie nadużycia mechanizmu
>>skąd inąd przydatnego.
> 
> Ach tak. A może skądinąd rzutowania rodem z C też są czasem przydatne?

Rzutpowania rodem z C nic ciekawego nie wnoszą.



>>>Zrobić coś nie całkiem tak, jak to się powinno robić, a potem gadać o
>>>wadach.
>>
>>Co jest niecałkiem tak? UB, gdy masz głupi, prosty błąd użycia iteratora?
> 
> Wskaźnik to nie iterator. Tam przede wszystkim pojawia się paskudne
> rzutowanie na bar.

Zapomniałeś o którym slajdzie pisałeś.


>>>>>47 -- chłopina rzutuje obiekt foo na bar a potem dziwi się, że "mu to
>>>>>nie działa".
>>>>
>>>>Co rzutuje? Przecież to jest "normalny" polimorfizm.
>>>
>>>Tak? Jeśli tak piszesz normalne programy. To nie dziwię się, że uciekasz
>>>od C++.
>>
>>Przykazywany jest wskaźnik na obiekt klasy pochodnej do funkcji
>>oczekującej wskaźnika na obiekt klasy bazowej -- to jest *standardowe*
>>użycie polimorfizmu. To, że funkcja oczekuje przekazania tablicy, tylko
>>przygłupi, kulawy język nie miesza tablice ze wskaźnikami to jest to co
>>jest.
> 
> To jest spadek z C.

skoro tak, to należało wprowadzić odpowiednie dynamiczne mechanizmy 
pilnowania porządku. A nie zbyć sprawę UBekiem.


>>To jest karygodny błąd języka. Tłumaczenie wielbicieli C++, żeby użyć
>>ciężkiego wektora 
> 
> Ciężkiego? Co Ty opowiadasz? Pokaż, że vector jest ciężki? Wydajność ma
> identyczną jak tablica.

LOL!

1. Wektor oznacza adresowanie pośrenie, tablica niekoniecznie (albo w 
najgorszym przypadku wzgłedem stosu) -- procesory OOO obsługują tablice 
nieco szybciej.
2. Jeśli weźmiesz mechanizmy dynamiczne, to tu masz kolejne, poważne 
spowolnienie, w dodatku algorytm zmniejszania rozmiaru jest arbitralny (a co 
jest dobre do wszystkiego nie jest dobre w niczym). Jeśli wektor szybko 
rośnie to typowa implementacja rośnie ze zbyt małymi krokami, jeśli zaś 
rośnie wolno to średnio jest 50% marnowanie pamięci. Jak maleje, to 
marnotrastwo może być dowolnie duże.

> Rozmiar? 12 bajtów na maszynie 32bity -- gigant.

Plus zaalokowany kawał pamięci ze sterty, kawał który jest alokowany, 
dealkowany, gdzie woła się tony konstruktorów kopiujących, itd.

Jak w Śmieciuchu zastąpiłem vector włąsną klasą to miałem zysk wydajności ok 
30%.


>>czy niewiele lżejszego, ale w ogóle nie należącego do 
>>języka boost::array jest poprostu żałosne.
> 
> 
> Żałosne? Co jest żałosne? Żałosne jest nieustanne machanie rękami ludzi typu
> Pan F. Nie pasuje mu język, to niech go nie używa!
> Niektóre wady są pokazane obiektywnie, ale przykładziki w większości to są
> badziewia. 

Przykładziki pokazują problemy a nie styl kodowania mający na celu te 
problem obchodzić.


>>Mamy język w którym są tablice, ale nie można ich używać, tylko jakiś
>>cięzkich typów bibliotecznych, bo język jest spieprzony. To są Jaja na
>>Resorach(tm).
> 
> Tak. Jaja na resorach. Zrób sobie statystykę ile ludzi używa surowych tablic
> w innych językach?

W tych dobrych? Tylko perwerci nie używają.

> 
> W J mało koderów używa tablic? A wiesz czemu, bo mają ubogą funkcjonalność,
> i czesto są niewiele szybsze niż kontenery.

A od kiedy uważam J za dobry język? Toż to przerośnięte, ciężkie krówsko, 
typowy overdesign.


>>>C++ zawrapował C bardziej dosłownie niż to robią inne języki, np.
>>>CPython. Czy wadą CPythona jest to, że możesz też kod napisać w C?
>>
>>Kod w C nie jest kodem w Pythonie.
> 
> 
> No to mnie pouczyłeś. Np. takie numpy jest napisane oczywiście w
> Pythonie ;-).

Chodzi o to, że Python nie cierpi tak jak C++ z powodu śmieci z C.

>>Kod w C często jest kodem w C++. 
> 
> To jest wina edukacji i legacy people.

Ależ skąd. Wiele programów w C to programy zarazem w C++.


>>>>>Mi to w ogóle ten kod nie działa, a jak go poprawiłem to mi działa
>>>>>dobrze.
>>>>
>>>>Taaaak??!?!?!? O, to ciekawe!
>>>
>>>Po prostu wystarczy ten kod napisać sensownie, a nie udowadniając tego co
>>>Pan F. chciał wykazać.
>>
>>Pan F. zademonstorwał kardynalny błąd w samym środku języka.
> 
> No to wracamy do punktu wyjścia :-D.

:)

pzdr
\SK