🚀 go-pugleaf

Witam

Adam Karpierz wrote:

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

Nie całkiem. Są możliwe konstrukcje oparte o polimorfizm statyczny paskudnie 
osiągalne na drodze polimorfizmu dynamicznego.

Polecam głębokie studium pojęcia specjalizacja szablonu.

Na grupie o C. Podałem pewien przykład w wątku "Dziedziczący wraper".

A z grubsza chodzi o coś takiego:

template < typename Result, typename Arg >
class foo {
public:
  typedef Result result_t;
  typedef Arg arg_t;
  result_t operator() ( arg_t const & t ) {
    // ... pracujemy z uwzględnieniem typów result_t i arg_t
  }
};

// i np. specjalizacja
template < typename Arg >
class foo <void,Arg>
{
  //... robimy dziwne rzeczy kiedy zwracany jest void.
}

// i np. specjalizacja
template < typename Result >
class foo <Result,void>
{
  //... robimy dziwne rzeczy kiedy argument jest void.
}

// i np. specjalizacja
template <>
class foo <void,void>
{
  //... robimy jeszcze dziwniejsze rzeczy kiedy,
  // argument jest void i wynik jest void
}

Aby to zrobić w oparciu o dziedziczenie musimy stworzyć kilka klas bazowych.
Do tego kod będzie musiał mieć jeszcze albo enum, albo jakąś klasę która
poprzez dzidziczenie wskaże na "specjalizację (dynamiczną)". W końcu dla
POD musimy mieć wrapery. Jeśli założymy, że je mamy tak jak w Javie jest
int oraz Integer to powstaje i tak pytanie jak zawrapować void, czy
oszukiwać i dawać int/Integer zamiast void i tak dalej. Oczywiście w
Pythonie nie ma problemu pod warunkiem, że w obrębie pracy z typami nie
mamy jakichś spraw np wyboru optymalnego algorytmu potęgowania, czy też np.
liczenia silni vs. funkcji Gamma - kiedy np. Arg jest int lub double i
chcemy liczyć arg! to raz dobrze jest mieć "!" dla typów
całkowitoliczbowych, a raz trzeba liczyć wartość funkcji Gamma.

> Czy ty rozumiesz juz, ze to co jest w Javie
> to jest typowy przyklad generyka
> polimorficznego parametryzowanego typem ?

No i? Mnie np. bardzo podoba się w Javie możliwość zadania pytania

class foo < ? extends bar >

> Sektorku kochany , racz zauwazyc ze operator ++ w ogole nie
> dziala na typie ale na _iteratorze_ i duze g.. wie jaki jest typ obiektu
> kontenera.

Inny jest iterator dla std;;list<double> inny dla std::vector<MyClass>.
A find_if rozróżnia je sam. Zresztą każdy algorytm tak robi.

Jest też takie coś: iterator::value_type i to jest typ wartości pokazywanej
przez iterator.

> On zna tylko typ iteratora (podanego mu explicite przez 
> kompilator) i wie ze na tymze ma wykonac metode operator ++

Ciekawe, że operator++ musi być wykonany dla konkretnego typu iteratora.

> Potem, wie tylko ze ma wykonac metode operator *

Jw.

> a potem funkcje operatorowa operator ==

Jw.

> Tyle.

No tak.

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

Nie jest potrzebny to nie znaczy, że nie osiągalny. Rozdział 7.5 z
książki "C++ Biblioteka standardowa", N.M. Josuttis.

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

Ja sobie życia ni utrudniam i te iteratory, które używam znają typ elementu.
Każdy używa co lubi.

A z ciekawych rzeczy polecam głębokie studium kolekcji połączonych z
boost::any, kiedy istotnie trzeba głębiej zapytać o typ elementu
zapakowanego do kolekcji.

Pozdrawiam.

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/