🚀 go-pugleaf

Seweryn Habdank-Wojewódzki 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).

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


To się robi tak:

template <typename T>
class container
{
   struct testament_t
   {
     typedef unsigned long state_t

     state_t state;

     testament_t(): state(1);
   }

   typedef std::tr1::shared_ptr<testament_T> testament_ptr;

   class iterator
   {
      testament_ptr creator_testament;
      testament_t::state_t initial_state;

      ...

      iterator(testament_ptr t, ...):
        creator_testament(t), initial_state(t->state), ...
      {...}

      T& operator* ()
      {
        if(creator_testament->state != initial_state)
	 throw invalid_iterator(); // albo abort() -- jak kto woli
        ...
      }

      ...
   };


   testament_ptr testament;

   void update_testament()
   {
     testament->state++;
     if(testament_state == 0)
     {
       testament = new testament_t();
     }
   }

   void last_testament()
   {
     testament->state = 0;
   }

   ...

public:
   container(...): testament(new testament_t()), ... {...}

   ~container()
   {
      last_testament();
      ...
   }

   void invalidating_modify(...)
   {
      update_testament();
      ...
   }

   iterator begin()
   {
     ...
     return iterator(testament, ...);
   }

};


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


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


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

Patrz wyżej. To jest proste, tanie i szybkie.


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


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

To czemu język na to pozwala? Statyczny system typów? ROTFL! To jest 
Dziurawy System Typów(tm).


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

Skąd wiesz czego on używa a czego nie?

Obraziłeś się, że najechał na twój kochany język, i o zgrozo, najazd jest celny.


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

Co ty wyyślasz???!!?!?!?!?!?!?

int dupa(int niemodyfikowany, int& modyfikowany);

gdzie masz jakieś 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ą?

To nie jest myślenie abstrakcyjne. To jest marnowanie czasu swojego i innych 
  -- to jest jak IOCCC czy Perl Golf, tyle że szkodliwe, bo usiłuje być na 
serio.


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

W Py masz PyParsing.

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.

MPL to jest chore same w sobie.


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

Taaa, zwłaszcza w Ocamlu... Albo w Pythonie


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


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


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

W C wszystko jest explicite. W pewnych zastosowaniach to jest nawet istotne 
-- jak masz traceability w systemach krytycznych to to rzecz ułatwia.

W C++ już często tego explicite nie ma a syf i ubecja pozostały.


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

Te kwiatki są proste i ograniczone jak samo C.


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

Ale nie wszędzie kod najbardziej oczywisty jest kodem niebezpiecznym i 
niestylowym. To jest domena C++.


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

I dobrze. GC znane jest od ponad 40 lat.

Zresztą C++ też już dosrasta do tego (w końcu). tr1 to już prawie standard, 
a w tr1 jest shared_ptr który od biedy pomaga.

> 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

I co to ma być? To jest poziom #define private public


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


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


>>>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 karygodny błąd języka. Tłumaczenie wielbicieli C++, żeby użyć 
ciężkiego wektora czy niewiele lżejszego, ale w ogóle nie należącego do 
języka boost::array jest poprostu żałosne.

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


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

Kod w C nie jest kodem w Pythonie. Kod w C często jest kodem 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.

pzdr
\SK