Questions hypothétiques, anciennement C ++ 0x

Question

( Préambule: , je suis un partisan du jeu C ++ 0x et la controverse récente concernant la suppression de concepts du standard C ++ 0x m'a motivé à en apprendre davantage à leur sujet. Bien que je comprenne que toutes mes questions sont complètement hypothétiques - dans la mesure où les concepts ne seront pas du code C ++ valide pendant un certain temps, voire pas du tout - je suis toujours intéressé à en apprendre davantage sur les concepts, en particulier de la manière dont cela aiderait. mieux comprendre le bien-fondé de la décision récente et de la controverse qui a suivi)

Après avoir lu des documents d'introduction sur des concepts présentés par C ++ 0x (jusqu'à récemment), j'ai du mal à comprendre certaines questions de syntaxe. Sans plus tarder, voici mes questions:

1) Un type prenant en charge un concept dérivé particulier (implicitement, via le mot clé auto ou explicitement via concept_maps) aurait-il également besoin de prendre en charge le concept de base de manière indépendante? En d'autres termes, le fait de dériver un concept d'un autre (par exemple, concept B<typename T> : A<T>) inclut-il implicitement une déclaration "invisible" requiert-elle (dans B, requires A<T>;)? La confusion provient de la page Wikipedia sur les concepts qui dit:

  

Comme dans l'héritage de classe, les types qui   répondre aux exigences de la dérivée   concept répondent également aux exigences de   le concept de base.

Cela semble indiquer qu'un type n'a besoin que de satisfaire les exigences du concept dérivé et pas nécessairement les exigences du concept de base, ce qui n'a aucun sens pour moi. Je comprends que Wikipedia est loin d’être une source définitive; la description ci-dessus est-elle un mauvais choix de mots?

2) Un concept répertoriant les noms de types peut-il être 'auto'? Si tel est le cas, comment le compilateur mappera-t-il automatiquement ces noms de types? Sinon, y a-t-il d'autres occasions où il serait invalide d'utiliser "auto" sur un concept?

Pour clarifier, considérons le code hypothétique suivant:

template<typename Type>
class Dummy {};

class Dummy2 { public: typedef int Type; };

auto concept SomeType<typename T>
{
     typename Type;
}

template<typename T> requires SomeType<T>
void function(T t)
{}

int main()
{
    function(Dummy<int>()); //would this match SomeType?
    function(Dummy2()); //how about this?
    return 0;
}

Est-ce que l'une ou l'autre de ces classes correspondrait à SomeType? Ou bien un concept_map est-il nécessaire pour les concepts impliquant des noms de types?

3) Enfin, j'ai du mal à comprendre quels axiomes seraient autorisés à définir. Par exemple, pourrais-je avoir un concept définissant un axiome logiquement incohérent, tel que

concept SomeConcept<typename T>
{
    T operator*(T&, int);

    axiom Inconsistency(T a)
    {
         a * 1 == a * 2;
    }
} 

Qu'est-ce que cela ferait? Est-ce même valable?

J'apprécie le fait qu'il s'agisse d'une très longue série de questions et je vous en remercie donc d'avance.

Answer 1

J'ai utilisé le brouillon C ++ 0x le plus récent, N2914 (qui contient toujours le libellé des concepts) comme référence pour la réponse suivante.

1) Les concepts sont comme des interfaces en cela. Si votre type prend en charge un concept, il doit également prendre en charge tous les & "Base &"; concepts. La déclaration de Wikipedia que vous citez est logique du point de vue du client d’un type. S'il sait que T correspond au concept Derived<T>, il sait également qu’il satisfait le concept Base<T>. Du point de vue des auteurs, cela signifie naturellement que les deux doivent être implémentés. Voir 14.10.3 / 2.

2) Oui, un concept avec typename membres peut être auto. Ces membres peuvent être déduits automatiquement s'ils sont utilisés dans les définitions des membres de la fonction dans le même concept. Par exemple, value_type pour l'itérateur peut être déduit comme type de retour de son operator*. Cependant, si un membre de type n'est utilisé nulle part, il ne sera pas déduit et ne sera donc pas défini implicitement. Dans votre exemple, il n’existe aucun moyen de déduire SomeType<T>::Type pour Dummy ou Dummy1, car Type n’est pas utilisé par les autres membres du concept. Par conséquent, aucune classe ne correspond au concept (et, en fait, , aucune classe ne pourrait éventuellement s’y mapper automatiquement). Voir 14.10.1.2/11 et 14.10.2.2/4.

3) Les axiomes étaient un point faible de la spécification et ils étaient constamment mis à jour pour donner un sens (plus) logique. Juste avant que les concepts aient été extraits du projet, il y avait un papier qui a beaucoup changé - lisez-le et voyez si cela vous semble plus logique ou si vous avez encore des questions à ce sujet.

Pour votre exemple spécifique (prise en compte de la différence syntaxique), cela signifierait que le compilateur serait autorisé à considérer que l'expression (a*1) est identique à (a*2), aux fins du " as-if " règle du langage (c’est-à-dire que le compilateur est autorisé à effectuer les optimisations qu’il souhaite, tant que le résultat se comporte comme si il n’y en avait pas). Cependant, le compilateur n’est nullement tenu de valider l’exactitude des axiomes (c’est pourquoi ils s’appellent axiomes!). Cela les prend juste pour ce qu’ils sont.