Pourquoi pas référence non-const aux objects temporaires?

C ++ permet d’affecter des objects temporaires uniquement à la référence const. Il ne permettra pas d’affecter des objects temporaires à la référence.

Par exemple:

Ssortingng& a = Ssortingng("test"); // Error const Ssortingng& a = Ssortingng("test"); // Ok 

Partout je google pour ce résultat, je ne vois que les réponses suivantes

  1. La modification d’objects temporaires entraînerait des problèmes non identifiables
  2. Modifier des objects temporaires est dangereux
  3. À un moment donné, vous oublierez que c’est une variable temporaire

Cela a été dit, les objects temporaires disparaissent après la déclaration. Donc, vous ne devriez pas le modifier.

Si C ++, est tellement enclin à bloquer la modification des objects temporaires, cela aurait dû bloquer la lecture des objects temporaires, n’est-ce pas? Si l’object temporaire est disparu, alors il est inutile de lire le contenu à partir de là non? Les cas possibles, où un droit peut survenir, peuvent également impliquer la lecture.

Alors pourquoi elle bloque-t-elle l’écriture seule et permet-elle la lecture?

S’il vous plaît donnez-moi une explication de code c ++ solide.

Veuillez ne pas dévier la question en pointant des alternatives. S’il vous plaît donnez-moi une réponse solide avec le code pourquoi const int & est autorisé et int & n’est pas autorisé pour les objects temporaires.

On dit que && est là. Ma question est différente. Autrement dit, changer ne reflétera pas. Changer ne reflétera pas même quand il est const. Par exemple: double a; Const int & i = a; a ++; n’affectera pas i ..

Le cas original de ne pas autoriser les références aux éléments temporaires concernait les parameters de fonction. Supposons que cela était autorisé:

 void inc(double& x) { x += 0.1; } int i = 0; inc(i); 

Pourquoi est-ce que i n’ai pas changé?

Si C ++, est tellement enclin à bloquer la modification des objects temporaires, cela aurait dû bloquer la lecture des objects temporaires, n’est-ce pas? Si l’object temporaire est disparu, alors il est inutile de lire le contenu à partir de là non?

Non, la lecture de l’object est parfaitement sensée. Le simple fait que cela disparaisse dans le futur ne signifie pas que la lecture des données est inutile.

 open_file(std::ssortingng("foo.txt")); 

std::ssortingng("foo.txt") est un std::ssortingng("foo.txt") temporaire qui cessera d’exister après l’appel à open_file() mais les données qu’il contient pendant qu’il existe ont beaucoup d’importance.

Le fait de ne pas autoriser la liaison temporelle à des références non-constantes n’est en fait pas un problème fondamental avec l’écriture dans les provisoires. En fait, dans de nombreux endroits, C ++ est parfaitement heureux de permettre la modification de fonctions temporaires:

 std::ssortingng("foo") = "bar"; 

C’est juste que les concepteurs pensaient que cela causerait un nombre suffisant de problèmes (probablement dû à l’idiome commun des «parameters de sortie») sans permettre quoi que ce soit de valeur similaire. les références.

Avec les références Rvalue, vous pouvez faire exactement ce qui était interdit auparavant:

 void foo(int &&output) { output = 1; } foo(2); 

Cela fonctionne bien, ce n’est pas très utile.

Si vous avez un object temporaire qui coûte très cher à copier, vous pouvez préférer prendre un const& à cet object (par exemple, un retour de fonction) plutôt que de le copier dans une autre variable à utiliser ultérieurement. Prendre une référence constante à un temporaire prolonge la vie de ce temporaire aussi longtemps que la vie de référence, vous permettant d’accéder à tout état lisible.

L’écriture est interdite, car dès que vous souhaitez modifier une variable, vous pouvez également avoir une instance réelle plutôt qu’un temporaire aliasé uniquement en tant que référence non-const.

Il y a une raison logique à cela. Pensez ce que vous voulez réellement dans cette ligne:

 Ssortingng& a = Ssortingng("test"); // Error 

Vous voulez une référence. Une référence se rapporte à l’object auquel elle fait référence. Comme une adresse de l’object (bien que les références ne soient pas des adresses, l’explication est plus claire). Vous essayez réellement d’obtenir quelque chose comme une adresse de Ssortingng("test") . Mais cet object disparaîtra sur la ligne suivante, alors quel est le but de son adresse, si l’object sur lequel il pointe n’existe pas? a maintenant pointe vers quelque chose de dépourvu de sens …

En ce qui concerne votre deuxième question, quel est l’intérêt de permettre des objects temporaires tout à fait, eh bien, il n’y a rien de mal à cela. Prenons par exemple le cas où vous voulez passer un object Ssortingng à une fonction, qui retourne, par exemple, une chaîne modifiée correspondant à cette chaîne. Appelons la fonction DoubleSsortingng, donc au lieu de faire

 Ssortingng s("hello "); Ssortingng s2 = DoubleSsortingng(s); 

Vous pouvez utiliser une forme plus courte et plus pratique

 Ssortingng s2 = DoubleSsortingng(Ssortingng("hello ")); 

Voir, l’object temporaire Ssortingng("hello ") survit à toute la ligne de code, ce qui signifie qu’il est intact lorsqu’il est envoyé à DoubleSsortingng et après. Il n’est détruit que lorsque la ligne entière est terminée.