Les valeurs de non-classe ont toujours des types non-cv

Question

§3.10 La section 9 stipule que "les valeurs de non-classe ont toujours des types cv-non-qualifiés". Cela m'a fait me demande ...

int foo() 
{ 
    return 5; 
} 

const int bar() 
{ 
    return 5; 
} 

void pass_int(int&& i) 
{ 
    std::cout << "rvalue\n"; 
} 

void pass_int(const int&& i) 
{ 
    std::cout << "const rvalue\n"; 
} 

int main() 
{ 
    pass_int(foo()); // prints "rvalue" 
    pass_int(bar()); // prints "const rvalue" 
} 

Selon la norme, il n'y a pas une telle chose comme const rvalue pour les types non-classe, mais préfère bar() se lier à const int&&. Est-ce un bug de compilateur?

EDIT: Apparemment, this est aussi un const rvalue :)

EDIT: Cette question semble être fixé en g ++ 4.5.0, les deux lignes impriment "rvalue" maintenant.

Answer 1

Le comité semble déjà être au courant qu'il ya un problème dans cette partie de la norme. CWG issue 690 parle d'un problème assez similaire avec exactement la même partie de la norme (dans la "note additionnelle" de septembre 2009). Je suppose que la nouvelle langue sera bientôt rédigée pour cette partie de la norme. Edit: Je viens de soumettre un post sur comp.std.C++, notant le problème et suggérant un nouveau libellé pour la partie pertinente de la norme. Malheureusement, étant un groupe de discussion modéré, presque tout le monde aura probablement oublié cette question au moment où il passe par la file d'attente d'approbation.

Answer 2

Bon point. Je suppose qu'il ya deux choses à regarder: 1) comme vous l'avez la rvalue non classe thingsy et 2) comment la résolution de surcharge fonctionne:

Les critères de sélection pour la meilleure fonction sont le nombre d'arguments, à quel point les arguments correspondent à la type paramètre liste de la fonction candidat , [...]

Je ne l'ai pas vu quoi que ce soit dans la norme qui me dit rvalues ​​non classe sont traités différemment au cours résolution de surcharge.

Votre question est traitée dans le projet de norme que j'ai bien (N-4411) un peu:

Ce qui entre en jeu est cependant une lecture parallèle de référence de liaison, des séquences de conversion implicites, les références et la surcharge résolution en général:

13.3.3.1.4 liaison de référence

2 Quand un paramètre de type de référence est pas lié directement à un argumentExpression, la séquence de conversion est celle requise pour convertir l'expression d'argument en le type sous-jacent de la référence en fonction de à 13.3.3.1.

et

13.3.3.2 Classement des séquences de conversion implicites

3 Deux séquences de conversion implicites de la même forme sont impossibles à distinguer séquences de conversion, sauf si l'un des règles suivantes est remplie:

- La séquence de conversion standard S1 est un meilleur c séquence de conversion de standard
séquence de conversion S2 si

- S1 et S2 sont des liaisons de référence (8.5.3) et ne fait référence à un paramètre d'objet implicite d'un non statique fonction membre déclarée sans qualificateur ref, et soit S1 se lie à un référence lvalue à une lvalue et S2 se lie à une référence rvalue ou S1 se lie à une référence rvalue à une valeur et S2 lie une référence lvalue.

[Exemple:

int i; 
int f(); 
int g(const int&); 
int g(const int&&); 
int j = g(i); // calls g(const int&) 
int k = g(f()); // calls g(const int&&)