Discussion :

[méphistopheles]

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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)

[JolyLoic]

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 ?

[Joel F]

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

[méphistopheles]

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

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 ?

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 ?

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

[JolyLoic]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

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.

[méphistopheles]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

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