[Metaprogramation]Boucle for template (très) générique

Citation:

---

Envoyé par JolyLoic

Le brouillon actuel de la norme dit (et je crois que c'était déjà ça en C++98) :

Code:

---

1 2 3 4 5

A non-type template-parameter shall have one of the following (optionally cv-qualified) types: — integral or enumeration type, — pointer to object or pointer to function, — lvalue reference to object

---

---

je vais probablement encore dire une bétise, mais... pourquoi ? y'a t'il une limitation architecturale logique à cette limitation ?

surtout que j'ai l'impression que les constexpr sont un paliatif a ce manque, mais sans imposer d'optimisation aux compilos....

Sinon, dans le cas, présent, j'utilise les templates surtout comme des super_préprocesseur... et il y a des fois (comme celui-ci) ou de simples macro évoluées les remplacerait facilement...juste à causes de ces limitations... (bon, il faudrait aussi pouvoir passer un objet non statiques... et c'est un autre probl-me je crois) :?

La complexité ?
La notion d'égalité qui est essentielle pour savoir si deux types en sont un seul, mais difficile à définir pour certains types (double, par exemple) ?
Le fait qu'au moment où ça a été introduit, personne n'en voyais l'intérêt ?
Problèmes liés à la durée de vie des objets si on pouvait directement les déclarer dans un paramètre templace ?

Citation:

---

Envoyé par méphistopheles

Sinon, dans le cas, présent, j'utilise les templates surtout comme des super_préprocesseur

---

c'est se priver de bien des aspects de la chose

Citation:

---

Envoyé par JolyLoic

La notion d'égalité qui est essentielle pour savoir si deux types en sont un seul, mais difficile à définir pour certains types (double, par exemple) ?

---

du moment que l'opérateur est défini...j'aurais tendance à dire que le reste est à la charge de l'utilisateur.(éventuellement en appelant un is_equal<>de son cru sur les types de base à la place des opérateur de base en cas de besoin).

Citation:

---

Envoyé par JolyLoic

Le fait qu'au moment où ça a été introduit, personne n'en voyais l'intérêt ?

---

et maintenant ? c'est toujours aussi inutile ?

Citation:

---

Envoyé par JolyLoic

Problèmes liés à la durée de vie des objets si on pouvait directement les déclarer dans un paramètre templace ?

---

c'est clair que là, c'est beaucoup plus complexe :s... mais on pourrait au moins autoriser ça pour les POD non ?

Citation:

---

Envoyé par Joel F

c'est se priver de bien des aspects de la chose

---

Je ne parlais que du problème présent (boucles for). Ici, une sorte de #FOR INDEX .... serait plus simple...

Citation:

---

Envoyé par méphistopheles

du moment que l'opérateur est défini...j'aurais tendance à dire que le reste est à la charge de l'utilisateur.(éventuellement en appelant un is_equal<>de son cru sur les types de base à la place des opérateur de base en cas de besoin).

---

Ce n'est pas tant le is_equal, ou alors la recherche d'un is_equal doit avoir lieu avant même de valider la syntaxe du code...

Code:

---

1 2 3 4

template <float f> class A {};   void f(A<1> a) {} void f(A<0.9+0.1> a) {}

---

Ce code serait-il correct ?

Citation:

---

Envoyé par méphistopheles

et maintenant ? c'est toujours aussi inutile ?

---

Je pense que oui, les constexpr étant là pour faire pas mal de choses à la compilation avec tous les types.

Citation:

---

Envoyé par JolyLoic

Ce n'est pas tant le is_equal, ou alors la recherche d'un is_equal doit avoir lieu avant même de valider la syntaxe du code...

Code:

---

1 2 3 4

template <float f> class A {};   void f(A<1> a) {} void f(A<0.9+0.1> a) {}

---

Ce code serait-il correct ?

---

Pour être sûr il faudrait écrire une fonction round du genre

Code:

---

1 2 3 4 5 6 7

template <double d, unsigned int NDecimal> struct round { const static double value=( d * puissance< 10, NDecimal > - ( d * puissance< 10, NDecimal > % 1 ) ) / puissance< 10, NDecimal >; //pas sûr que le % existe pour les double, mais bon, c'est juste l'idée. //puissance<double, int > est facile a faire. };

---

et là, je ne vois pas ou est le probleme en appelant :

Code:

---

1 2	void f(A<round<1,2>::value> a) {} void f(A<round<0.9+0.1,2> > a) {}

---

Le problème reste à la charge de l'utilisateur.

Citation:

---

Envoyé par JolyLoic

Je pense que oui, les constexpr étant là pour faire pas mal de choses à la compilation avec tous les types.

---

Mais les optimisations faites avec les constexpr sont-elles définies (je veux dire le comportement :s ) ? j'ai l'impression que l'optimisation est laissée libre au compilateur... ce qui n'est vraiment pas souhaitable pour la portabilité ou autre...