1
votes

c ++ auto pour les modèles de type et non-type

En c ++ 17, template permet de déclarer des modèles avec des paramètres de type arbitraires. Partiellement inspiré de cette question, il serait utile d'avoir une extension de template qui capture à la fois les paramètres de modèle de type et de non-type, et permet également une version variadique de celui-ci.

Y a-t-il des plans pour une telle extension dans la prochaine version de c ++ 20? Y a-t-il un problème fondamental à avoir une syntaxe comme template , avec X n'importe quel paramètre de modèle de type ou non?


0 commentaires

3 Réponses :


7
votes

Y a-t-il des plans pour une telle extension dans la prochaine version de c ++ 20?

Non.

Y a-t-il un problème fondamental à avoir une syntaxe comme template , avec X n'importe quel paramètre de modèle de type ou non?

Ce serait un concept totalement nouveau dans la langue - avoir un nom fait référence à soit un type ou une valeur au même endroit. Donc, il viendrait avec toutes sortes de questions supplémentaires - et probablement des fonctionnalités de langue supplémentaires pour vérifier si X est un type ou non.

La syntaxe ne peut pas probablement être template struct Y {}; puisque cette syntaxe a déjà un sens et signifie un tas de valeurs et Y {} est mal formé.

Il y a certainement des endroits où une telle chose serait utile. Une proposition devrait simplement aborder ces questions.


5 commentaires

Nous pourrions supprimer totalement le mot-clé template et le remplacer par auto puisque les autos sont de toute façon traduites en tant que modèle dans le backend


J'attends que vous fassiez maintenant cette proposition


@SombreroChicken Ne retenez pas votre souffle.


Je suis maintenant mort.


@texasbruce: La syntaxe correcte serait auto auto {auto}; . Je pense, cependant, que nous devrions travailler à rendre le C ++ moins verbeux en utilisant à la place: car car {car}; . Personne ne pensera aux claviers?



-1
votes

Je ne vois pas en quoi il serait utile qu'un argument de modèle puisse être dynamiquement un type ou une valeur? Les instructions de code qui utilisent des types sont très différentes de celles qui utilisent des valeurs constantes introduites via l'argument template.

Le seul moyen serait un gros "if constexpr" qui le rendrait inutile à mon avis.

Ok, après avoir examiné de plus près la question référencée, je suppose qu'il y a de la place pour un encapsulation générique pass-through des différentes implémentations de modèles de base explicites qui utilisent des ordres de paramètres différents. Je ne vois toujours pas un énorme avantage. Les erreurs du compilateur quand ça va mal vont être insondables, si rien d'autre!

Je me souviens avoir entendu dire que la surcharge et les modèles allaient débarrasser le monde des messages d'erreur insondables générés par les macros. Je ne l'ai pas encore vu!


2 commentaires

Je dois admettre que je ne peux pas penser à un cas d'utilisation complet. Mais étant donné qu'il existe des contextes où à la fois un type ou une valeur serait valide ( sizeof vient à l'esprit), je peux imaginer que quelqu'un quelque part aurait aimé cette fonctionnalité à un moment donné.


@PasserBy Hmm, mais poser la question "Est-ce une spécialisation pour ça" peut être répondu beaucoup plus simplement par le compilateur qui sait déjà, sûrement?



1
votes

Le gros problème en essayant de faire quelque chose comme ça est la grammaire. Les paramètres de modèle indiquent à l'avance s'il s'agit de modèles, de types ou de valeurs, et la raison la plus importante en est la grammaire.

C ++ est une grammaire contextuelle. Cela signifie que vous ne pouvez pas savoir, uniquement à partir d'une séquence de jetons, ce qu'une séquence particulière de jetons signifie. Par exemple, IDENTIFIER LEFT_PAREN RIGHT_PAREN SEMICOLON . Qu'est-ce que cela signifie?

Cela pourrait signifier appeler une fonction nommée par IDENTIFIER sans paramètre. Cela pourrait signifier initialiser par défaut une valeur pr d'une classe nommée par IDENTIFIER . Ce sont des choses assez différentes; vous pourriez les voir conceptuellement comme similaires, mais la grammaire de C ++ ne le fait pas.

Les modèles ne sont pas des macros; ils ne font pas de collage de jetons. Il est entendu qu'un morceau de code dans un modèle est censé signifier une chose spécifique. Et vous ne pouvez le faire que si vous savez au moins quel genre de chose est un paramètre de modèle.

Afin de conserver cette capacité, ces "paramètres de modèle omni" ne peuvent pas être utilisés tant que vous ne savez pas ce qu'ils signifient. Donc, pour créer une telle fonctionnalité en C ++, vous devez:

  1. Créez une nouvelle syntaxe pour déclarer les paramètres du modèle omni ( auto ne va pas voler, car il a déjà une signification spécifique).
  2. Fournissez une syntaxe pour déterminer le type de chose d'un paramètre de modèle omni.
  3. Demandez à l'utilisateur d'appeler cette syntaxe avant de pouvoir utiliser ces noms de paramètres de la plupart des manières. Ce serait généralement via une forme de bloc spécialisé if constexpr , mais les propositions de correspondance de modèle représentent une manière alternative / supplémentaire intéressante de les gérer (car elles peuvent être des expressions aussi bien que des instructions). Et les instructions d'extension représentent un moyen possible d'accéder à tous les paramètres omni d'un pack de paramètres.

0 commentaires