🚀 go-pugleaf

Witam

Sebastian Kaliszewski wrote:

>> 19 -- o czym on mówi? Czy on może chce, aby iterator był dołączony do
>> obiektu, a może jak obiekt ma 5 MB, to też ma wszystko wiedzieć o
>> pojedynczym obiekcie?
> 
> Po co? Wzkaźniki już nie istnieją?

Wskaźnik przecież może pokazywać na NULL? Przecież wskaźnik nie wie czy
obiekt się zmienił (wzorzec obserwator się kłania).
Pan F. nie pokazuje jak coś nie działa i jest to zrobione w dobrym stylu
C++. Wymaścił jakieś kodziki i płacze, że mu nie działa. W tym stylu
potrafię rozwalić każdy kod w C, J, i Py. # nie umiem na tyle, aby to
zrobić, ale na pewno na tej grupie są geekowie, co potrafią grzebać we
wnętrznościach #.

>> A jak tych obiektów w kolekcji jest dzikie mnóstwo
>> to, co? Ile informacji potrzebuje mieć iterator, aby wszyscy przestali
>> się czepiać, że on czegoś nie wie.
> 
> Powinien wiedzieć po czym iteruje. Tak, żeby nie było UBecji.

O tak. Każdy iterator powinien być wizytatorem, obserwatorem, kompozytem,
mózgiem i wiedzą kodera w jednym.

Iterator przede wszystkim ma być efektywną abstrakcją, a nie kombajnem.
 
>> Zresztą banalne jest związanie iteratora i
>> kontenera wrapując oba w jednym obiekcie.
> 
> Typowe gadanie z C++ -- zrób se sam. W C++ wszystko jest zrób se sam, bo
> biblioteka standardowa jest biedna i prymitywna.

Tak. A i tak kolesie pokroju Pana F. nie używają jej -- przykład tablica
obiektów typu foo rzutowana na bar*. Użycie STL na poziomie 0.

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.
 
>> 32 i 33 -- zapomniał Pan Felix o const, czy to go boli? Czy jeśli żąda
>> czegoś innego od referencji niż od wartości, to może operować constem.
>> A może ma jeszcze coś innego na myśli?
> 
> To, że w wywołaniu nie wiesz czy parametr będzie modyfikowany czy nie.

Do tego właśnie służy CONST!!!
 
>> 34 i 35 -- Super. Język ma być łatwy! Też tak, chce, aby Haskel i Lisp
>> były łatwe, aby asembler był łatwy. Jakoś jest tak, że język, który
>> oferuje więcej niż Logo, musi być nieco trudniejszy.
> 
> Taaak, bo takie potworki jak boost::mpl czy boost::spirit to są niezwykle
> potrzebne

Oh. Przeszkadza Ci, że ktoś myśli bardziej abstrakcyjnie niż łepsajty tego
wymagają? Pokaż mi takie cos jak MPL i SPIRIT w J i w Py.

J wyciera sobie twarz XML i to równiutko, a jak chcesz mieć coś innego niż
XML, to ci mówią, że ... hmm ... ę ... tego ... yyy ... ten tego,
"poco ci coś innego niż XML?"

Parsery wszędzie pisze się parszywie. Więc Twój argument, że Spirit jest
potworny jest nietrafiony.

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. Np. mam takie coś:

mpl::vector < TrapMf, TriMf, TriMf, TriMf, TrapMf >

a w bardziej dynamicznym kontekście:

mpl::vector < shared_ptr<MembershipFunction>, ...
shared_ptr<MembershipFunction>, >

Co można jeszcze bardziej zdynamizować:

std::vector < shared_ptr<MembershipFunction> >

Kłopot polega na tym, w którym miejscu żądam jakich gwarancji. Każda z tych
wersji jest w różnych miejscach kodu. W szczególności mam takie miejsca
gdzie pierwszy kod jest jedynym słusznym rozwiązaniem (zamienić MPL można
na boost::tuple), ale kod jest podobny.

To oczywiście nie jest łepsajt i daleko temu do tego. 
Ale to też nie jest "wydumana sprawa" bo takie konstrukcje stanowią podstawę
Data Miningu. Dla którego powoli oficjalnie jest wsparcie zarówno bazach
danych (Oracle) jak i w językach -- J2EE wyposażone jest w pewien ubogi
projekt do Data Miningu.

>> 36 -- zgada się, tylko co to wnosi?
> 
> W koślawym języku traci się kupę czasu na przeskakiwanie koślawości?

Ha, ha, ha. Tylko, że Pan F. pisze, że lubi C, a tam aż roi się o void* (*)
(void*). I to boli nie na żarty.
 
>> 38 -- mówił, że lubi C, a tam są te same problemy i na dodatek łata się
>> je o wiele gorzej niż w C++.
> 
> W C są wyjątki??? iteratory??? desytuktory????

Nie ma. Są za to inne kwiatki. A w innych językach? Wystarczy sprawnie jak w
dobrej szkole Troli zapodać na grupę post typu. "Słyszałem, że w języku XXX
nie da się zrobić czegoś takiego jak YYY". Ach zaraz masz 1001 przepisów
jak w dowolnym języku XXX można zrobić paskudniaczka. Do tego jeszcze
chłopaki prześcigać się będą jak to wykonać najbardziej ekstremalnie -- bo
przecież się da. Wszędzie się da kod spaskudzić.
 
>> 40 -- no tak, a kto tak projektuje kod nawet w języku C. Co to za
>> zwyczaj, aby obiekt kasował nie ten co go przydziela?
> 
> To jest normalny zwyczaj. Tylko w nienormalnych językach to sprawia
> problem :)

Tak? A gdzie to jest normalny zwyczaj? Jeśli gdzieś są takie zwyczaje to
kończy się to na posiadaniu GC. A ciekawie się dzieje, kiedy sam zaczniesz
grzebać w tym co robi GC i np. rozgrzebiesz w GC to na czym pracuje GC.
 
>> ... męczące jest zastanawianie się ile można brzydkich przykładów podać w
>> dowolnym języku programowania ... bo w każdym to jest możliwe.
> 
> Ale w innych językach tego problemu po prostu nie ma.

Nie prawda. Zobacz sobie na to:

http://qsorix.jogger.pl/2006/12/14/java-jezyk-pelen-niespodzianek

To jest właśnie poziom haków Pana F.

Zrobić coś nie całkiem tak, jak to się powinno robić, a potem gadać o
wadach.

Dorzucam do tego jeszcze mój stary problem jak wyleczyć wadę projektową
generyków J, która nazwana jest ficzerem "erasure". 
Wiesz jaki potworek trzeba napisać, aby twój generyk pomimo wszystko
nie "erasurował się"? Oczywiście (na szczęście) da się to wyleczyć.

>> 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++.
 
> Pokazana jedna z projektowych przypadłości C++ -- niekontrolowane
> nakłądanie się na siebie cech, na skutek niedostatecznego przemyślenia
> skutków dodawania określoncyh ficzerów -- połączenie odziedziczonego z C
> pomieszania wskaźników z tablicami z obiektowym polimorfizmem rodzi
> kaszanę.

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?
 
> Inny przykład to słynne >> w szablonach.

A gdzie nie ma słynnych przykładów? W Pythonie jak dla mnie słynnym
przykładem jest kasowanie metod z klas. Wada czy zaleta?

I pytanie bonus jak skasujesz metodę z klasy, to jak ją odzyskać?
 
>> 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ć.

Pozdrawiam.

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