Discussion :

[zais_ethael]

Salut à tous.
Je me posais une question sur le standard, voici un exemple de code:

Code :

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

1
2
3
void un_truc(string& argument);
...
un_truc(string("quelque chose"));

Le fait que j'aie choisi la classe string n'a aucune importance, de même j'aurais pu utiliser une fonction renvoyant un string plutot qu'un constructeur.
Donc la difficulté est que cette fonction prend en argument une réfèrence. Comme je lui passe le résultat d'un constructeur au lieu d'une variable locale le compilateur n'apprécie pas.
Mon problème est que ce code compile (et fonctionne) sous visual C++ mais pas sous gcc. Ma question est donc: "que dicte le standard à ce sujet?".
Merci d'avance pour ceux qui me répondront.

[roulious]

Le standard dit qu'on ne doit pas créer de référence non constante sur un temporaire. Donc VisualC++ est trop laxiste à ce sujet.

[Patriarch24]

En effet c'est illégal. Par contre, on a le droit à :

Code :

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

1
2
3
4
 
void toto(const string&).......
....
toto(string("lalalère"));

[zais_ethael]

Ok merci, va falloir que j'apprene à jouer un peu plus avec les const moi .

[loufoque]

Le constructeur de std::string est implicite. Inutile de l'appeler explicitement.

[zais_ethael]

J'ai marqué que c'était pour l'exemple

[Luc Hermitte]

Ceci est probablement l'argument le plus efficace en faveur de la const-correction auprès des gens qui y sont rétissants -- à supposer qu'ils aient déjà accepté d'utiliser des références ...

[zais_ethael]

Faut dire que quand on voit le nombre effarant de trucs qui existent en C++ rien que dans la syntaxe, sans même considérer les apis, on comprend qu'on n'aie pas envie de tout utiliser.
Pour ce qui est du const, je ne vois à priori aucun raison technique ou conceptuelle qui le rendent plus utile en C++ que dans un autre langage comme le java. Pourtant ca n'existe pas du tout en java et on se débrouille très bien comme ca.

[Médinoc]

Pour commencer, ça contribue à l'auto-documentation du code.
Mais il faut que la gestion de la const-correctness soit assez complète. En C++, on a droit aux méthodes const. En .Net, on n'a pas de const-correctness et le readonly du C# n'arrive pas à la cheville du const du C++ natif...

[zais_ethael]

Soit, il est vrai que les attributs en C# et les accesseurs en java sont moins paramètrables que le const en C++.
Mais a-t'on vraiment besoin d'un tel niveau de personnalisation? C'est un peu la vocation d'un langage de haut niveau que de nous épargner les détails inutiles. Faut quand même admettre que si on doit mettre des const partout ca représente au bas mot (mais vraiment bas) 50% de nos fonctions/méthodes/arguments, c'est assez fastidieux d'en taper partout.
Et comme je le disais, en Java comme en C# on s'en tire de facon très satisfaisante, il existe les classes immuables pour ça.