🚀 go-pugleaf

Witam

Czemu zawsze kłócimy się o to samo?

Sebastian Kaliszewski wrote:

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

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? 

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? 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?
 
> Nie wiem jak się ten wzorzec nazwa, jeśli nie ma nazwy, to można go nazwać
> Testament :)  (infromacje dla przyjaciół (friends) i innych zstępnych
> zawierające wolę testamentodawcy, również po jego śmierci).

To jest ciekawe.
 
>> 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! Wskaźnik to nie iterator. Iterator może być
wskaźnikiem. Taka silna inkluzja zbiorów. Pan F. bawi się wskaźnikami a nie
iteratorem.
 
>> O tak. Każdy iterator powinien być wizytatorem, obserwatorem, kompozytem,
>> mózgiem i wiedzą kodera w jednym.
> 
> Patrz wyżej. To jest proste, tanie i szybkie.

OK, ale IMHO nie jedyne słuszne.
 
>> 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.
I soft pisany stylem Pana F. też może robić dziwne rzeczy. Ale styl Pana F.
jest paskudny. Zastanów się i odpowiedz. Czy życzyłbyś sobie takiego kodera
w zespole? Nie zależnie od języka, takie haxory jak popisał Pan F. nadają
się wyłącznie jako podstawa do wysłania go na szkolonko.
 
>> 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?
Czemu nie ma sekcji prywatnej w klasach?
Czy python zakłada dobrą wolę kodera? Słusznie. 
C++ zakłada, że języka używa wykształcony koder, a nie gamoń.

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! 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.
 
> Obraziłeś się, 

W żadnym wypadku, obrażanie się to nie moja domena.

> że najechał na twój kochany język

"Kochany" -- zazwyczaj takie określenie używam względem ludzi.

> i o zgrozo, najazd jest celny.

Celnych jest kilka uwag. Podkreśliłem to! 

I powiedziałem, że dla mnie to jest nic nowego, bo już od Ciebie
dowiedziałem się więcej i na przykładach DUŻO mniej wyssanych z palca. 

Tobie jestem wdzięczny, a Pana F. traktuję jako speca od haków.

>> Do tego właśnie służy CONST!!!
> 
> Co ty wyyślasz???!!?!?!?!?!?!?
> 
> int dupa(int niemodyfikowany, int& modyfikowany);
> 
> gdzie masz jakieś const??!?!

int dupa(int niemodyfikowany    // tu wszyscy orędownicy języków lepszych
                                // podnoszą larum o kopiowanie, 
                                // zatem proponuję to co poniżej
        , int& modyfikowany);

int dupa(type const & niemodyfikowany, type & modyfikowany);
int dupa(POD_type const niemodyfikowany, POD_type & modyfikowany);

int dupa(boost::call_traits<type>::param_type niemodyfikowany, 
        POD_type & modyfikowany);

>> Pokaż mi takie cos jak MPL i SPIRIT w J i w Py.
> 
> W Py masz PyParsing.

To jest odpowiednik spirita, a mpl?
 
> Zamiast zatykającego kompilator i powolnego Spirita wolę użyć Antlr -- da
> mi kod i dla Javy i dla C++ i dla C# i dla Pythona. Szybszy i w kompilacji
> i w wykonaniu niż rzeźba w spiricie.

Super.
 
> 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.
 
>> 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.
 
>> Więc Twój argument, że Spirit jest
>> potworny jest nietrafiony.
> 
> Do parserów używa się odpowiednich narzędzi. Albo dobrego, a nie kulawego,
> języka :)

Słusznie. Tylko, że pojęcie "dobry/dobrego" należy do dziedziny rozmytych
pojęć -- kłopot polega na tym, że Twoje "dobry" jest inne niż moje.
 
>> Co do MPL. Np. w konstrukcji rozmytego algorytmu predykcyjnego mam
>> kawałki z boost::mpl (dziś lepiej jest używać boost::fusion).
>> 
>> Jest to raczej poprawa czytelności, niż utrudnienie.
> 
> Co?!?! MPL i poprawa czytelności? Bez jaj!

U mnie poprawia :-).

Masz jasno określone, że system wnioskowania/klasyfikacji składa się z
wektora funkcji przynależności, z których każda ma określony typ. To jest
jedna linia. Nic dodać nic odjąć. Jeśli tylko klasyfikator się nie zmienia
w sensie typów to taka konstrukcja jest lepsza niż co innego (zmiana
parametrów funkcji nie zmienia ich typów, tak więc system nadal może się
modyfikować np. uczyć).
 
>>>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 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++.

>> Tak? A gdzie to jest normalny zwyczaj?

Nie odpowiedziałeś na to pytanie!

>> 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.
 
>> A ciekawie się dzieje, kiedy sam zaczniesz
>> grzebać w tym co robi GC i np. rozgrzebiesz w GC to na czym pracuje GC.
> 
> ?????

Poczytaj o kręceniu przy GC w run-time dla JVM, można naprawdę sobie
wykręcić to i owo.

>> Nie prawda. Zobacz sobie na to:
>> 
>> http://qsorix.jogger.pl/2006/12/14/java-jezyk-pelen-niespodzianek
> 
> I co to ma być? To jest poziom #define private public

I co? Nie da się zrobić brzydala? Da się! I co z tego! 
To nie jest wada J, to jest możliwość, jak chcesz, to z niej korzystasz.
Jak nie, to nie.

Jeden człowiek raz mi powiedział, że dostał w spadku kod, w którym takie coś
należało użyć, bo najprawdopodobniej projekt był zwalony. 
I co on by zrobił gdyby nie mógł tego typu gniota zrobić? Przepisać wszystko
od zera?
 
>> 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?
 
>> 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.
 
>>>>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.
 
> 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. Rozmiar? 12 bajtów na maszynie 32bity -- gigant.

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

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

>> 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 ;-).
 
Wszystko co ma status stabliny i jest wymagana wydajność/oszczędność ramu w
CPythonie jest napisane w C. Wszystko! Czemu?

> Kod w C często jest kodem w C++. 

To jest wina edukacji i legacy people.
 
>>>>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.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/