🚀 go-pugleaf

On 9 Kwi, 19:47, p...@gazeta.pl (Piotr Dembiński) wrote:
> A.L. <f...@2005.com> writes:
>
> [...]
>
> > Szablony to zwykly makrogenerator i z obiektowoscia nic zgola
> > wspolnego nei maja.
>
> Programowanie generyczne.  Swoją drogą to ciekawie mogłaby wyglądać
> biblioteka STL dla ANSI C zrealizowana w oparciu o procesor makr M4.

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" - problem polega na tym, że
STL opiera się nie tylko na samych szablonach, ale również np. na
przeciążaniu. I tu nie chodzi o to, że mamy np. kilka wersji funkcji
transform() z różną ilością argumentów, ale również o dedkukcję typów
w przypadku ptr_fun, czy bind2nd.

Druga sprawa to specjalizacja szablonu. Nie istnieje taki
makrogenerator, który potrafi:
a) dedukować parametr
b) specjalizować wzorzec wybiórczo

Do tych obu rzeczy potrzebne są takie konstrukcje, które pracują
bezpośrednio na elementach języka. Makrogenerator nie potrafi, po
otrzymaniu 'a', dowiedzieć się, że 'a' jest obiektem typu 'int' i
przekazać owo 'int' jako parametr. Makrogenerator nie potrafi również
domyślić się, które z części definicji wzorca są używane w miejscu
specjalizacji, a które nie.

Przykładowo, weźmy takie find_if, zrealizowane jako makro:

x = FIND_IF( LIST, ls->head, ls->tail, bool (*)(int),
is_divisible_by_3 );

LIST potrzebujemy do tego, żeby mieć nagłówek do zestawu funkcji
charakterystycznych (w tym funkcji określającej metodę awansowania
iteratora), a typ funkcyjny po to, żeby można było przekazać funkcję
is_divisible_by_3. Ja i tak nawet nie mam pewności, czy w tym powyżej
jeszcze nie brakuje czegoś dodatkowego. W przypadku prawdziwego STL z C
++ wygląda to oczywiście

x = find_if( ls.begin(), ls.end(), is_divisible_by_3 );

Nie wspominając już o tym, że tam nawet nie trzeba definiować osobno
funkcji ze specjalizacją argumentu:

x = find_if( ls.begin(), ls.end(), bind2nd( is_divisible_by, 3 ) );

STL i tak ma zresztą jeszcze poważny design flaw polegający na tym, że
nie należało w algorytmach dawać osobnych argumentów dla początkowego
i końcowego iteratora (generalizacja poszła nie w tą stronę, co
trzeba). Po uzupełnieniu o wszystkie braki najpewniej przyszła wersja
będzie wyglądać tak:

x = find_if( ls, bind( is_divisible_by, _1, 3 ) );

I dlatego właśnie nigdy nie powstała biblioteka generyczna oparta na
makrach i nigdy takowa nie powstanie. Z prostej przyczyny - nikt by
jej po prostu nie używał, bo interfejs takiej biblioteki byłby na tyle
koślawy, że każdego by odrzucało.