C ++ 0x: operatore condizionale, XValues ??e decltype

Question

Io sono reposting un comp.std.c ++ Usenet discussione qui perché questo gruppo è diventato molto inaffidabile. Gli ultimi post che ci hai inviato sono andati nel vuoto, e l'attività è quasi del tutto cessato. Dubito che ho messo al bando e / o tutti gli altri appena perso interesse. Speriamo che tutte le persone interessate troveranno questa discussione, e ci sarà una migrazione generale. Forse allora si nominare un nuovo moderatore.

---

Ciao!

Con il mio attuale interpretazione del progetto di N3126 w.r.t. il condizionale dell'operatore e XValues, mi aspetto che le seguenti affermazioni per contenere:

 int i = 0;
 int& j = true? i : i;
 int&& k = true? std::move(i) : std::move(i);   // #2
 assert(&i == &j); // Holds since C++98
 assert(&i == &k); // Should this hold as well?

5.16 / 4 dice:

  

Se il secondo e terzo operandi [a   l'operatore condizionale] sono   glvalues ??della stessa categoria valore di   e hanno lo stesso tipo, il risultato è   di quel tipo e valore di categoria [...]

Anche se, non chiaramente dire che il glvalue risultante si riferisce a Uno degli oggetti operandi glvalue cui - o è questo implicita perché altrimenti sarebbe tornato un prvalue? Utilizzando GCC 4.5.1 in modalità C ++ 0x seconda asserzione fallisce. K riferimento sembra riferirsi a qualche oggetto temporaneo. Qualcuno può chiarire se la comiler può creare un tale temporaneo in caso entrambi gli operandi intorno al colon sono XValues ??dello stesso tipo?

Al momento sto assumendo GCC è bacato e / o non up-to-date con rispetto a XValues.

La domanda followup è: Non sarebbe bello essere in grado di rilevare la categoria valore di un'espressione? Se ignoriamo l'operatore condizionale siamo in grado di rilevare la categoria valore di un'espressione con decltype. Ma ciò che è

 bool xvalue = std::is_rvalue_reference<
   decltype( true ? std::move(i) : std::move(i) ) >::value;

dovrebbe rendimento? Utilizzando GCC 4.5.1, la variabile viene inizializzata xValue con falsa. È questo conforme al progetto di norma attuale?

TIA, Sebastian

Answer 1

Credo che il GCC 4.5.1 è non conformi WRT §5.16 / 4. Hai depositato un bug report ?

In ogni caso, penso che sia conforme con il codice operatore ternario. decltype è definito da §7.1.6.2 / 4:

  

Il tipo indicato con decltype (e) è   definiti come segue:

     

  
• se e è un id-espressione unparenthesized o un membro della classe di accesso   (5.2.5), decltype (e) è il tipo di   l'entità denominata via e. Se non c'è   tale soggetto, ovvero se e nomi di una serie di   funzioni di sovraccarico, il programma è   mal formati;
  
• altrimenti, se e è una chiamata di funzione (5.2.2) o un'invocazione di un   operatore di overload (parentesi   intorno e vengono ignorati), decltype (e) è   il tipo di ritorno del staticamente   funzione scelta;
  
• In caso contrario, se e è un lvalue, decltype (e) è T &, dove T è il tipo   di e;
  
• altrimenti, decltype (e) è il tipo di e. L'operando della decltype   specificatore è un operando non valutata   (Clausola 5).
  

decltype opere di recupero della dichiarazione appropriata e restituendo il tipo desiderato da esso. Ha poco di intelligenza rispetto agli operatori non sovraccarico. Forse un altro punto

• In caso contrario, se e è un xValue, decltype (E) è T&&, dove T è il tipo di e

sarebbe in ordine, tanto più che, come scritto, XValues ??ottenere trattati come prvalues. Inoltre, i vostri corrisponde espressione esattamente alla definizione di std::common_type (§20.7.6.6 / 3).

Una soluzione semplice (per coniare una frase: VP):

template< typename T1, typename T2 >
struct common_type_and_category {
    typedef typename std::conditional<
        std::is_same< T1, T2 >::value,
        T1,
        typename std::common_type< T1, T2 >::type
    >::type type;
};