Discussion :

[Pyramidev]

Pourquoi ne peut-on pas modifier une rvalue non objet alors que l'on peut appeler une fonction membre non constante sur une rvalue objet non constante ?
Notamment, pourquoi n'a-t-on pas le droit de faire une pré-incrémentation sur un pointeur nu qui est une rvalue alors qu'on a le droit d'appeler operator++ sur une rvalue objet non constante ?

Exemple avec g++ 6.2.0 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
#include <set>
#include <array>
 
int main() {
    std::set<int>      set = {0, 1, 2, 3};
    std::array<int, 4> tab = {0, 1, 2, 3};
    auto setIt = ++set.begin(); // Compile, car std::set<int>::iterator est un objet.
    auto tabIt = ++tab.begin(); // Ne compile pas, car std::array<int, 4>::iterator est un pointeur nu.
    return 0;
}

A quoi sert cette différence de règle ?

Je sais que le code générique pour récupérer un itérateur vers le deuxième élément d'un conteneur de la STL est std::next(conteneur.begin()).
Mais je trouve dommage qu'il faille passer par un modèle de fonction std::next pour contourner le fait que ++conteneur.begin() ne compile pas avec certains conteneurs. Je pense que cela complique inutilement l'apprentissage de la programmation générique en C++.

[dalfab]

Je poserais plutôt la question inverse :
Pourquoi peut-on appeler une fonction membre non constante sur une rvalue objet non constante alors que l'on ne peut normalement pas modifier une rvalue ?

Modifier une rvalue est une source d'erreur, la ligne ++set.begin(); compile et elle pourrait tromper un débutant.

Une fonction ou un opérateur peut produire une rvalue, mais ne devrait pas permettre d'en modifier une. Les opérateurs des conteneurs devraient être : T& operator++() & et T const& operator++()const & pour n'accepter que les lvalues.

[Pyramidev]

Pourquoi peut-on appeler une fonction membre non constante sur une rvalue objet non constante alors que l'on ne peut normalement pas modifier une rvalue ?

Cela permet :

• d'éviter une copie inutile de l'objet et
• d'utiliser le named parameter idiom.

Du coup, je viens de répondre à ma propre question, étant donné que, pour les non-objets :

• la copie est peu coûteuse et sera probablement optimisée par le compilateur et
• le named parameter idiom ne s'applique qu'aux objets.

Mais je trouve toujours dommage que cela complique l'apprentissage de la programmation générique.

[gb_68]

auto setIt = ++set.begin(); // Compile, car std::set<int>::iterator est un objet.

Attention, ce n'est pas parce que std::set<int>::iterator est un objet que ce code compile, mais parce que l'implémentation de l'opérateur ++ a été réalisé ici en tant que fonction membre.

S'il avait été défini en tant que fonction libre sous la forme iterator & operator++(iterator &), ce code ne compilerait pas non plus (sauf à définir une surcharge acceptant iterator &&).

[Médinoc]

Donc en gros, on ne peut pas passer un temporaire non-nommé à une fonction attendant une référence non-const, mais on peut appeler une fonction membre non-const sur un temporaire non-nommé?

[Pyramidev]

@Médinoc : Ça dépend quelle fonction membre non-const :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
struct A {
    void foo   ()          {}
    void fooLV () &        {}
    void fooRV () &&       {}
    void fooC  () const    {}
    void fooCLV() const &  {}
    void fooCRV() const && {}
};
 
void barLV (A&        a) {}
void barRV (A&&       a) {}
void barCLV(const A&  a) {}
void barCRV(const A&& a) {}
 
int main() {
    A{}.foo   ();
//  A{}.fooLV (); // Ne compile pas.
    A{}.fooRV ();
    A{}.fooC  ();
    A{}.fooCLV();
    A{}.fooCRV();
//  barLV (A{}); // Ne compile pas.
    barRV (A{});
    barCLV(A{});
    barCRV(A{});
    return 0;
}

Les opérateurs des conteneurs devraient être : T& operator++() & et T const& operator++()const & pour n'accepter que les lvalues.

T const& operator++()const & accepte les rvalues à cause du const.
Mais une telle fonction n'a pas de raison d'être const, car elle sert habituellement à modifier l'objet.
Même std::back_insert_iterator::operator++ n'a pas de surcharge const alors qu'il ne fait rien.