Pagini recente » Diferente pentru blog/metaprogramare-cu-template-uri intre reviziile 10 si 9 | Diferente pentru blog/metaprogramare-cu-template-uri intre reviziile 8 si 7 | Diferente pentru blog/de-ce-python intre reviziile 11 si 12 | Atasamentele paginii Profil [email protected] | Diferente pentru blog/metaprogramare-cu-template-uri intre reviziile 9 si 8
Nu exista diferente intre titluri.
Diferente intre continut:
*Principiul de baza*
Poate stiti ca in STL exista o implementare generala pentru vector, insa exista si o implementare speciala numai pentru _vector<bool>_, care foloseste doar cate un bit pentru fiecare valoare. Idioma C++ care permite asa ceva este "template specialization" si este un mecanism foarte puternic (mult mai puternic decat vom vedea aici). Practic, compilatorul are mai multe definitii din care alege una anume. Folosind acest lucru putem sa "trucam" compilatorul in a face un "if".
Poate stiti ca in STL exista o implementare generala pentru vector, insa exista si o implementare speciala numai pentru _vector<bool>,_ care foloseste doar cate un bit pentru fiecare valoare. Idioma C++ care permite asa ceva este "template specialization" si este un mecanism foarte puternic (mult mai puternic decat vom vedea aici). Practic, compilatorul are mai multe definitii din care alege una anume. Folosind acest lucru putem sa "trucam" compilatorul in a face un "if".
De exemplu, sa zicem ca vrem sa facem o asertie la timpul compilarii. Avem o expresie statica (care poate fi calculata la compilare) si vrem sa primim o eroare daca aceasta expresie nu se evalueaza la true. Putem sa folosim aceasta idee de template specialization:
template<> struct CompileTimeError<true> { enum { Cool = 1 }; };
==
Am definit un tip _CompileTimeError_ care in general este gol. Insa daca parametrul bool se intampla sa fie true, compilatorul foloseste definitia specializata a tipului. Daca avem o expresie expr, sa ne gandim la urmatoarea expresie:
Am definit un tip CompileTimeError care in general este gol. Insa daca parametrul bool se intampla sa fie true, compilatorul foloseste definitia specializata a tipului. Daca avem o expresie expr, sa ne gandim la urmatoarea expresie:
==code(c) |
CompileTimeError<expr>::Cool
*Recursivitate*
Pentru ca tipurile sunt prin definitie imutabile, nu vom putea face compilatorul sa ruleze algoritmi iterativi - nu avem cum sa il facem sa mentina o stare. Va trebui sa convertim orice lucru iterativ in ceva recursiv, cum am face la un limbaj functional (in stil lisp). Cum determinam daca un numar este prim fara sa mentinem stare? Putem sa definim o "functie" _HasDivisors_ cu doi parametri, $N$ si $K$. _HasDivisors_ returneaza true daca vreun numar intre 2 si $K$ il divide pe $N$. Astfel, un numar este prim daca _HasDivisors_ este true pentru parametrii $N$ si $N-1$. Putem implementa aceasta idee cu template-uri:
Pentru ca tipurile sunt prin definitie imutabile, nu vom putea face compilatorul sa ruleze algoritmi iterativi - nu avem cum sa il facem sa mentina o stare. Va trebui sa convertim orice lucru iterativ in ceva recursiv, cum am face la un limbaj functional (in stil lisp). Cum determinam daca un numar este prim fara sa mentinem stare? Putem sa definim o "functie" _HasDivisors_ cu doi parametri, $N$ si $K$. HasDivisors returneaza true daca vreun numar intre 2 si $K$ il divide pe $N$. Astfel, un numar este prim daca _HasDivisors_ este true pentru parametrii $N$ si $N-1$. Putem implementa aceasta idee cu template-uri:
== code(c) |
template <int N, int K>
};
==
Observam recursivitatea din _HasDivisors_; conditia de oprire este implementata prin specializarea partiala _HasDivisors<$N$, 1>_
Observam recursivitatea din HasDivisors; conditia de oprire este implementata prin specializarea partiala HasDivisors<N, 1>
Putem combina acestea cu definitiile de mai sus pentru a genera erori pentru numerele prime:
Nu exista diferente intre securitate.
Topicul de forum nu a fost schimbat.