🚀 go-pugleaf

Dnia Thu, 20 Oct 2005 20:04:11 +0200, jarekr skrobie:
> > class_requires<is_base_and_derived<T,MyInterface>::value>();
> > class_requires<is_base_and_derived<U,My2<Y>>::value>();

> O znowu się czegoś dowiedziałem o C++ od Ciebie - dzięki (przyda mi się).
> Za czasów kiedy pisałem w C++ nijak na tak ładne rozwiązanie nie wpadłem 
> i nie znalazłem w sieci tego rozwiązania (wtedy boost jako "standard" 
> sie chyba dopiero rodził)

Nie no to jest tak wymyślone "naprędce". To całe is_base_and_derived to nawet
jest w boost::type_traits, ale class_requires to trzeba se zrobić samemu w
taki sposób, żeby się sypało podczas kompilacji gdy ...::value jest false.

> Jest tylko jedne kłopot - sądząc po googlu... to nie jest za często 
> stosowane.

Oczywiście, bo jest to znacznie mniej potrzebne, niż się ludziom wydaje.
Co więcej, jest to też często zabójcze! Nałożenie dowolnego ograniczenia na
typ-parametr powoduje od razu bardzo możliwe ograniczenia użycia takiego
wzorca. Przykładowo, pamiętam jak jakaś klasa używała własnego type-traita do
sprawdzenia, czy dany typ jest integer. A ja sobie zrobię np. własny typ
integer i co? Wiem, że powinienem się w takim przypadku "dopisać do listy" i
to rozwiązuje problem, ale z drugiej strony to może spowodować, że mój typ
będzier traktowany jak całkowity nawet jeśli spełnia "nie wszystkie" warunki.

Jeśli już, to powinno się definiować w miarę możliwości osobne definicje dla
różnych kwalifikacji typów.

W istocie w Javie to ograniczanie typów (tak samo zresztą jak w C#) bierze się
wcale nie stąd, że "ludzie potrzebują ograniczania typów", tylko stąd, że tego
wymaga runtime języka (inaczej: język nie będzie działał bez tych ograniczeń).
W przypadku Javy jest to bardzo proste przełożenie: jeśli używany typ nie ma
ograniczeń, to będzie implementowany przez Object; jeśli ma ograniczenie na
bycie wyprowadzonym z określonej klasy/interfejsu - wtedy będzie
implementowany przez referencję do tej właśnie klasy/interfejsu. Generyki
zapewniają ci tylko tyle, że zrobią za ciebie rzutowanie.

> Absolutnie źle mnie zrozumiałeś. W javie (genericsy) nie ma 
> metaprogramowania ani trochę.

Aha, jeśli tak to się zgodzę. Nie sprecyzowałeś po prostu.

> I to jest zaleta. Przynajmniej patrząc na to co pamiętam z C++.

No nie wiem. Jak słyszę takie rzeczy, że w Javie czegoś brakuje, co ma C++ i
że to jest zaleta, to mnie dosłownie pusty śmiech ogarnia. Jeszcze większy,
jak się po jakimś czasie okazuje, że to zostało częściowo potem dodane, tak
jak było z generykami.

> Poza tym, boost::mpl stracił w moich oczach dawno temu - jak niechcący 
> zaglądnąłem do źródeł i zobaczyłem ile konstrukcji jest "sficzerowanych" 
> chamskimi makrami. Prawda, że na oko 95% tych makr (a może troche więcej 
> -ale na pewno nie wszystkie) to poprawki na problemy z kompilatorami 
> (wyjątkowo często na msvc).

Nie masz się czym przejmować; boostowcy przesadzają z komplikowaniem kodu. To
jeszcze niczego nie oznacza.

> To, że z C++ da sie zasymulować prawie dowolny język korzystając z makr 
> i derektyw typu #pragma to fakt. Ale tak się składa, że w praktyce to 
> może nie być zaleta :-).

Ale tu nie chodzi o makra; te są używane wyłącznie instrumentalnie. Da się to
wszystko napisać zupełnie bez makr, a nawet prościej. W metaprogramowaniu
chodzi głównie o wykonywanie operacji na wartościach i typach podczas
kompilacji. To nie wymaga jakichś specjalnych sztuczek, ani nie jest wcale tak
często stosowane.

Ale mimo niewielu zastosowań jego istnienie jest nieocenione! Tym bardziej
zatem nie rozumiem, dlaczego jego brak w języku miałby być zaletą, skoro w
niczym nie przeszkadza.

> >>4) brainfuck
> > To chyba to, co brałeś przed napisaniem tego postu.
> To było odnosnie lukru syntaktycznego - brainfuck to język, który w 
> zasadzie nie ma lukru syntaktycznego.

No jak to - przecież wszystko jest na operatorach, nie ma w ogóle słów
kluczowych ;)))))

> Sorry, ale ten zarzut jest naprawde absurdalny dla mnie - bo akurat
> zaczynałem programowanie od assemblera i makroassemblera i długo (z pięknym
> uporem) C/C++ widziałem tylko jako mały lukier syntaktyczny :-)
> (kilkaset kilo makr do (dobrego) makroassemblera tworzy język cholernie 
> podobny do C (wizualnie).
> A jak pamiętam kiedyś zdobyłem piękny zestaw makr do C, które robiły 
> "prawie" C++.
>   (prawie (w obu przypadkach) to znaczy z dużymi problemami w 
> dziedzinach tak istotnych jak kontrola typów.. ale przynajmniej wizualne 
> podobieństwo dało się uzyskać)).

I chyba destruktorów, których nie jesteś w stanie zasymulować w C w żaden
sposób. A jest to bardzo istotny element C++.

> Konkretnie:
> To że genericsy javowe generują kod wynikowy taki jaki się daje uzyskać 
> bez ich stosowania to nie znaczy, ze jest to tylko lukier syntaktyczny.
> Wprowadzja dodatkową kontrole typów na poziomie kompilacji (po to je 
> wprowadzono) więc ten twój argument - zbijam.

Eeee tam. No dobrze - dodają statyczną weryfikację poprawności typu. Ale to
wszystko.

Istotnym elementem wzorców w C++ jest ich "efficiency". Dlatego jest to
właśnie "polimorfizm statyczny". W Javie nie ma żadnego statycznego
polimorfizmu; jest to dynamiczny polimorfizm z drobnym wsparciem statycznym.

-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"I am allergic to Java because programming in Java reminds me casting spells"