Comment la norme C ++ 0x définit les déclarations multiples C ++ Auto?

Question

mmm, j'ai juste une petite confusion à propos des déclarations automatiques multiples dans le prochain standard C ++ 0x.

auto a = 10, b = 3.f , * c = new Class();

quelque part que j'ai lu, ce n'est pas permis. La raison en était (?) Car il n'était pas clair si les déclarations consécutives devaient avoir le même type du premier, (int dans l'exemple) ou non.

Traduction possible 1:

int a = 10; 
int b = 3.f; 
int * c = new Class ();

provoquant une erreur

Traduction possible 2:

int a = 10;
float b = 3.f;
Class * c = new Class (); 

comment cela se traduit dans la norme?

Si je peux dire mon point de vue, la traduction n ° 2 était la plus obiouvée, du moins pour moi, je suis un utilisateur régulier de C ++. Je veux dire, pour moi & "Chaque variable déclarée est du même type déclaré &" ;, qui est auto. La traduction n ° 1 me serait vraiment peu intuitive.

Au revoir QbProg

Answer 1

Ce n'est probablement pas la dernière, mais mon projet de norme C ++ 0x de juin 2008 stipule que vous pouvez effectuer les opérations suivantes:

auto x = 5; // OK: x has type int
const auto *v = &x, u = 6; // OK: v has type const int*, u has type const int

Donc, à moins que quelque chose ait changé depuis juin, ceci est (ou sera) autorisé dans une forme limitée avec une interprétation assez intuitive.

La limitation est que si vous voulez utiliser plusieurs déclarations automatiques comme ceci (à l'aide de l'exemple ci-dessus), cela fonctionne car les types inférés de v et u ont le même 'type de base' (int cas) d’utiliser un terme inexact.

Si vous voulez la règle précise, le projet de norme dit ceci:

  

Si la liste de déclarateurs contient plus d'un déclarant, le type de chaque variable déclarée est déterminé comme décrit   au dessus de. Si le type déduit pour le paramètre de modèle U n’est pas le même dans chaque déduction, le programme est mal formé.

où le & paramètre de modèle déduit U " est déterminé par:

  

le type déduit du paramètre u dans l'appel f (expr) du modèle de fonction inventé suivant:

 `template <class U> void f(const U& u);`

Pourquoi ils ont proposé cette règle au lieu de dire quelque chose comme:

auto a = 10, b = 3.f , * c = new Class();

est équivalent à:

auto a = 10;
auto b = 3.f;
auto * c = new Class();

Je ne sais pas. Mais je n'écris pas de compilateurs. Probablement quelque chose à faire avec une fois que vous avez déterminé le auto mot clé remplacé, vous ne pouvez pas le changer dans la même déclaration.

Prenez par exemple:

int x = 5;
CFoo * c = new CFoo();

auto  a1 = x,       b1 = c; // why should this be permitted if
int   a2 = x, CFoo* b2 = c; // this is not?

Dans tous les cas, je ne suis pas du tout disposé à ajouter plusieurs déclarations à la même déclaration.

Answer 2

Le projet de norme La section 7.1.6.4 implique que vous ne pouvez pas mélanger les types comme dans traduction possible 2. Ainsi, aucune traduction possible n’est valide.

Answer 3

Il y a peu de points qui, à mon avis, contribuent à la formulation actuelle. Le premier est la cohérence. Si vous écrivez une déclaration telle que:

int j;
int i = 0, *k = &j;

Ensuite, les deux types utilisent int quelque part dans leur type. C'est une erreur par exemple, si "j" était un "const int". Faire en sorte que auto fonctionne de la même manière est & "Cohérent &"; avec le modèle actuel pour de telles déclarations.

Il existe alors un avantage pratique du point de vue d’un rédacteur. Il existe déjà dans les compilateurs des machines pour effectuer la déduction de type pour un appel de fonction (c'est ainsi que auto est décrit comme opérationnel). La règle ci-dessus est cohérente avec la règle selon laquelle la déduction pour un paramètre de modèle doit avoir le même type:

template <typename T> void foo (T, T*);

void bar ()
{
  int i;
  const int j = 0;

  foo (i, &i);  // OK deduction succeeds T == int
  foo (i, &j);  // ERROR deduction fails T == int or const int.
}

Une mise en oeuvre facile pour auto consiste à réutiliser les mécanismes existants pour en déduire le type pour auto . En raison de la cohérence avec les comportements actuels, le résultat ne sera pas trop surprenant. aux gens.

Enfin, et c’est probablement le point le plus important à mon avis. Le modèle actuel est conservateur et fonctionne de manière très similaire aux constructions de langage existantes en C ++. Par conséquent, les chances qu’il en résulte un bogue linguistique d’arrêt du spectacle sont très minces. Cependant, le modèle actuel peut facilement être étendu à l'avenir pour contenir les autres exemples que vous avez énumérés dans votre question.

De plus, cette extension ne cassera pas le code qui utilise le libellé actuel de auto . Demandez-vous s'ils l'ont fait dans l'autre sens. Si la version développée de auto était la première version et que le mot clé comportait un défaut étrange et fatal, il faudrait alors supprimer une fonctionnalité de langage de la norme, ce qui ne se produit presque jamais il est très probable qu'il casse le code.

Answer 4

Le premier s'alignerait sur le fonctionnement de l'inférence de type dans le type de retour de l'opérateur?:.