In che modo lo standard C ++ 0x definisce le dichiarazioni multiple automatiche C ++?

Question

mmm, ho solo un po 'di confusione su più dichiarazioni automatiche nel prossimo standard C ++ 0x.

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

da qualche parte ho letto che non è permesso. Il motivo era (?) Perché non era chiaro se le dichiarazioni consecutive dovessero avere lo stesso tipo del primo, (int nell'esempio), oppure no.

Possibile traduzione 1:

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

causa un errore

Possibile traduzione 2:

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

come si ottiene lo standard?

Se posso dire il mio POV, la traduzione n. 2 è stata la maggior parte degli obiouv, almeno per me che sono un normale utente C ++. Voglio dire, per me & Quot; ogni variabile dichiarata è dello stesso tipo dichiarato & Quot ;, strega è auto. La traduzione n. 1 sarebbe davvero poco intuitiva per me.

Arrivederci QbProg

Answer 1

Probabilmente non è l'ultimo, ma la mia bozza standard C ++ 0x di giugno 2008 dice che puoi fare quanto segue:

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

Quindi, a meno che qualcosa non sia cambiato da giugno, questo è (o sarà) consentito in forma limitata con un'interpretazione piuttosto intuitiva.

La limitazione è che se vuoi mettere in stringa più dichiarazioni automatiche come questa (usando l'esempio sopra), funziona perché il tipo inferito di v e u ha lo stesso 'tipo base' (int in questo caso) per usare un termine inesatto.

Se si desidera la regola precisa, la bozza della norma dice questo:

  

Se l'elenco dei dichiaratori contiene più di un dichiarante, il tipo di ciascuna variabile dichiarata viene determinato come descritto   sopra. Se il tipo dedotto per il parametro modello U non è lo stesso in ogni detrazione, il programma non è corretto.

dove il " parametro del modello dedotto U " è determinato da:

  

il tipo dedotto del parametro u nella chiamata f (expr) del seguente modello di funzione inventato:

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

Perché hanno escogitato questa regola invece di dire qualcosa del tipo:

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

è equivalente a:

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

Non lo so. Ma non scrivo compilatori. Probabilmente qualcosa a che fare con una volta che hai capito la sostituzione della parola chiave auto, non puoi cambiarla nella stessa dichiarazione.

Prendi ad esempio:

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?

In ogni caso, non sono un fan del mettere comunque più dichiarazioni sulla stessa dichiarazione.

Answer 2

bozza standard la sezione 7.1.6.4 implica che non è possibile mescolare tipi come nella possibile traduzione 2. Quindi nessuna delle due traduzioni possibili è valida.

Answer 3

Ci sono alcuni punti che ritengo possano contribuire alla formulazione attuale. Il primo è la coerenza. Se scrivi una dichiarazione come:

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

Quindi, i due tipi usano entrambi int da qualche parte nel loro tipo. È un errore, ad esempio, se 'j' era una 'const int'. Avere auto funzionare allo stesso modo è & Quot; coerente & Quot; con l'attuale modello per tali dichiarazioni.

Esiste quindi un vantaggio pratico dal punto di vista di uno scrittore di compilatori. Esistono già i macchinari nei compilatori per eseguire la deduzione del tipo per una chiamata di funzione (che è come auto viene descritto come operativo). La regola di cui sopra è coerente con la regola secondo cui la detrazione per un parametro modello deve comportare lo stesso tipo:

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

Una facile implementazione per auto è di riutilizzare la meccanica esistente per dedurre il tipo di auto e, a causa della coerenza con i comportamenti attuali, il risultato non sarà troppo sorprendente alle persone.

Infine, e questo è probabilmente il punto più importante secondo me. Il modello attuale è conservativo e funziona in modo molto simile ai costrutti di linguaggio esistenti in C ++. Pertanto, le possibilità che si traduca in uno show che interrompe il bug della lingua sono molto scarse. Tuttavia, il modello attuale può essere facilmente ampliato in futuro per contenere gli altri esempi che elenchi nella tua domanda.

Inoltre, tale espansione non interromperà il codice che utilizza la dicitura attuale di auto . Considera se lo hanno fatto al contrario. Se la versione espansa di auto fosse la prima versione, e questo causasse un difetto strano e fatale con la parola chiave, richiederebbe la rimozione di una funzionalità linguistica dallo standard - qualcosa che quasi mai accade come molto probabilmente rompe il codice.

Answer 4

Il primo sarebbe in linea con il modo in cui l'inferenza del tipo funziona nel tipo restituito dell'operatore?: