🚀 go-pugleaf

On 11 Kwi, 21:47, "Adam Karpierz" <karpierz@_NOSPAM_python.pl> wrote:
> Użytkownik "ethouris" <ethou...@gmail.com> napisał:
>
> >> Czy Pan uwaza ze mozna postawic znak rownosci pomiedzy
> >> "trzepiacymi konkretyzacjami" czy trzeba czy nie szablonami z C++
> >> a rozwiazaniami szablonow w Javie czy C#  ktore.. tak naprawde
> >> w ogole szablonami nie sa  (choc moze mylic skladnia podobna do C++) ,
> >> ale  parametryzowalnymi obiektowymi kontenerami ?.
> > Szablonami są jak najbardziej.
> > Przecież z punktu widzenia programisty piszącego kod istotne jest
> > tylko to, co jest w źródłach programu i co jak działa. Fakt, że
> > wszystkie parametry szablonu są wewnętrznie magicznie przerabiane na
> > Object to nieistotny szczegół.
>
> Sektor czy Ty czujesz ze dzieki takiemu podejsciu
> wystarcza w Javie _jedna_  (jak to w C++ sie nazywa)
> "specjalizacja" szablonu obslugujaca wszystkie typu
> wywodzace sie od klasy bazowej ?

Nigdy nie twierdziłem, że to podejście nie posiada określonych zalet.

Ale co z tego? Efekt jest taki, że tego typu wyrażeń nie da się
optymalizować, bo każde musi mieć w efekcie wersję obiektową, która
każdą specjalizację wybiera poprzez dynamiczne dispatchowanie.

Z punktu widzenia programisty różnica jest żadna, bo on i tak używa
tego, co zostało zadeklarowane jako wzorzec typu.

> Czy ty czujesz juz ze taki "szablon" mozna spokojnie
> skompilowac, umiescic w bytecode a bedzie dobrze
> dzialal wlasnie dzieki podejsciu obiektowemu
> a nie "pieczatkowemu" jeno ?.

Problem tylko w tym, że jego umieszczenie w bajtkodzie nie powoduje
bynajmniej, że ów szablon typu można potem używać tak, jakby był
oparty na obiektach. Skoro tak, to z punktu widzenia programisty nie
ma różnicy, jak on jest wewnętrznie implementowany.

> No to mi powiedz dlaczego slawetne export w C++ (ktore
> ma niby robic to samo) tak sie nie podaje implementacji
> przez tyle lat ?

Bo nikt nie opracował dla C++ sensownego systemu modułów, tylko wciąż
wszystko oprarte jest na "systemowych" rozwiązaniach, czyli na języku
C. A tutaj elementy eksportowane to mogą być tylko obiekty i funkcje.
Gdyby ktoś się pokusił o sensowny system modułów, problemów by nie
było. Oprzeć export na plikach *.o się po prostu nie da - i twórcy ISO
C++ najwyraźniej o tym zapomnieli.

> Czy ty rozumiesz juz, ze to co jest w Javie
> to jest typowy przyklad generyka
> polimorficznego parametryzowanego typem ?
> (sorry za nowomowe ale jakos tak mi sie
>  powiedzialo wyjatkowo), i dzieki temu podlega kontroli
> typow w taki sposob jak i kazda inna rzecz,
> a to co jest w C++

Też podlega kontroli typów, jak każda inna rzecz.

> to plaskie "trzaskanie
> specjalizacji"  bez opameitanei

Z punktu widzenia programisty ma to znaczenie dopiero w przypadku, gdy
musi mieć definicje dzielone pomiędzy jednostkami kompilacji. I
zgadzam się, nie opracowano sensownego rozwiązania tego problemu. I
tylko tyle widzę w tym wad jako programista.

> i dopiero
> linker sobie z tym radzi

Doprawdy? W jaki cudowny sposób linker zażąda utworzenia
konkretyzacji?

> (bo zrobiono kolejny
> wyjatek dla linkera ze gdy napotka natrzaskane
> takie same specjalizacje w roznych modulach to
> w przeciwienstwie do inych externali gdzie daje
> duplicate error tu ma wybrac jedna.

Czyli uprawia "słabe wiązanie". Jasne, ale to nie jest żadne "radzenie
sobie" (przypominam, że język C zakłada "słabe wiązanie" dla
wszystkich eksportowanych symboli, więc nie wiem co to ma być za
"zaleta"). Problem tylko w tym, że zgodnie ze standardem nie można
założyć możliwości importowania symbolu opisującego choćby nawet tylko
konkretyzację. Nawet gcc robi to tylko na niektórych platformach.

> >> Czy tu _gdziekolwiek_ nastepuje dedukcja typu parametru
> >> przez szablon ? Szablon jest glupi jak but.
> > Owszem. Następuje w operatorze ++, używanym wewnątrz find_if, który
> > wybiera odpowiednią specjalizacje opartą o typ obiektu podanego jako
> > ls.begin() i ls.end().
>
> Sektorku kochany , racz zauwazyc ze operator ++ w ogole nie
> dziala na typie ale na _iteratorze_ i duze g.. wie jaki jest typ obiektu
> kontenera.

Jego to akurat po prostu nie interesuje. Ta informacja jest mu zbędna.
A definicja typu iteratora logicznie należy do deklaracji kontenera.

> On zna tylko typ iteratora (podanego mu explicite przez
> kompilator)

Buhahahahaha :)

No jasne - jak już musimy udowadniać, że template to makrogenerator,
to musimy jakoś zaznaczyć, że ktoś mu jednak ten typ explicite
podaje ;)

> i wie ze na tymze ma wykonac metode operator ++

Bo tak ma zresztą zakodowane.

> Potem, wie tylko ze ma wykonac metode operator *
> a potem funkcje operatorowa operator ==
> Tyle.

Zgadza się. I co?

> W calej find_if (czy innych tego rodzaju rozwizazaniach)
> typ _samego obiektu_ nie jest nigdzie potrzebny.

No dobrze i co - czy to oznacza, że jest on niemożliwy do uzyskania?

> Stad te Wasze bajki o "dedukcji typu" przez yntelygentny
> szablon to wlasnie miedzy... bajki wlozyc.

No tak, oczywiście - nie ma tutaj żadnej dedukcji typu, jest tylko
PODAWANIE TYPU EXPLICITE PRZEZ KOMPILATOR.

>
> AK

Tak, może lepiej zacznij się podpisywać twoim ulubionym ostatnio "AM".

Pozdrawiam,
((
 ))