🚀 go-pugleaf

On 11 Kwi, 01:09, "Adam Karpierz" <karpierz@_NOSPAM_python.pl> wrote:
> Użytkownik "ethouris" <ethou...@gmail.com> napisał:
>
> > Pomijając już kwestie "makrogeneratorowatości" szablonów C++, o czym
> > nie chce mi się już pisać, bo argumenty panów AL + AK od zawsze w tym
> > temacie były typu "makrogenerator, bo tak" -
>
> 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ół.

> Czy porownujac te rozwiazania z tych trzech jezykow
> dalej nie mozna rzec ze w stosuku np. do Javy czy C#
> rozwiazania kontenerowe STL to prymitywny makrogenerator ?

Adam, nie rób sobie jaj.

Cóż takiego lepszego mają generyki z Javy czy C#, że są one lepsze od C
++-owych szablonów?

> > Nie istnieje taki makrogenerator, który potrafi:
> > a) dedukować parametr
> > x = find_if( ls.begin(), ls.end(), is_divisible_by_3 );
>
> 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().

> On typ musi miec podany explicite typ (niewazne kto go podaje).

No i gdzie przepraszam masz ten explicite typ? Widzisz gdzieś tutaj
powyżej std::list<int>::iterator lub coś podobnego? Nie, przepraszam,
std::_List_iterator<int,int*,int&>.

--
((
 ))