Est-il raisonnable de prendre std :: istream && comme argument?

Un std :: istream n'est pas déplaçable , il n'y a donc aucun avantage pratique à ceci.

Cela signale déjà que l'objet peut être "modifié", sans la confusion de suggérer que vous transférez la propriété de l'objet std :: istream (ce que vous ne faites pas et que vous pouvez ' t faire).

Je peux en quelque sorte voir le raisonnement derrière l'utilisation de ceci pour dire que le flux est logiquement déplacé, mais je pense que vous devez faire une distinction entre "la propriété de cette chose est en cours de transfert", et "Je garde la propriété de cette chose mais je vous laisserai consommer tous ses services". Le transfert de propriété est assez bien compris comme une convention en C ++, et ce n'est pas vraiment ça. Que pensera un utilisateur de votre code lorsqu'il devra écrire parse (std :: move (std :: cin)) ?

Votre chemin n'est cependant pas "dangereux"; vous ne pourrez rien faire avec cette référence rvalue que vous ne pouvez pas faire avec une référence lvalue.

Il serait beaucoup plus auto-documenté et conventionnel de prendre simplement une référence à lvalue.

std :: move produit simplement une référence rvalue à partir d'un objet et rien de plus. La nature d'une rvalue est telle que vous pouvez supposer que personne d'autre ne se souciera de son état une fois que vous en avez terminé. std :: move est alors utilisé pour permettre aux développeurs de faire cette promesse sur les objets avec d'autres catégories de valeurs. En d'autres termes, appeler std :: move dans un contexte significatif équivaut à dire "Je promets que je ne me soucie plus de l'état de cet objet".

Puisque vous allez rendre l'objet essentiellement inutilisable et que vous voulez vous assurer que l'appelant n'utilisera plus l'objet en utilisant une référence rvalue applique cette attente dans une certaine mesure. Cela oblige l'appelant à faire cette promesse à votre fonction. Le fait de ne pas tenir la promesse entraînera une erreur du compilateur (en supposant qu'il n'y ait pas d'autre surcharge valide). Peu importe que vous vous déplaciez réellement de l'objet ou non, seulement que le propriétaire d'origine a accepté de renoncer à sa propriété.

Ce que vous essayez de faire ici n'est pas «dangereux» dans le sens où, étant donné l'interface actuelle std :: istream , il ne semble pas y avoir de circonstances dans lesquelles un rvalue référence ici conduirait nécessairement à un comportement indéfini lorsque la prise d'une référence lvalue n'aurait pas. Mais la sémantique de tout cet engin est à mon humble avis au mieux très discutable. Que signifie pour le code d'appel «céder la propriété» mais en même temps «ne pas la transférer»? Qui "possède" le flux après le retour de parse () !? De quelle manière exactement parse () rend-il le flux "inutilisable"? Que faire si l'analyse échoue en raison d'une erreur avant que le flux entier ne soit «consommé»? Le flux est-il "inutilisable" alors !? Personne n'est autorisé à essayer de lire le reste? La «propriété» est-elle en quelque sorte «rendue» au code d'appel dans ce cas?

Un flux est un concept abstrait. Le but de l'abstraction de flux est de servir d'interface à travers laquelle quelqu'un peut consommer des entrées sans avoir à savoir d'où proviennent les données, vivent ou comment elles sont accessibles et gérées. Si le but de parse () est d'analyser les entrées provenant de sources arbitraires, alors il ne devrait pas être concerné par la nature de la source. S'il s'intéresse à la nature de la source, il devrait alors demander un type de source spécifique. Et c'est là, à mon humble avis, que votre interface se contredit. Actuellement, parse () prend une source arbitraire. L'interface dit: je prends le flux que vous me donnez, peu m'importe comment il est implémenté. Tant que c'est un flux, je peux travailler avec. En même temps, il oblige l'appelant à abandonner l'objet qui implémente réellement le flux. L'interface nécessite que l'appelant remette quelque chose que l'interface elle-même empêche toute implémentation derrière l'interface de connaître, d'accéder ou d'utiliser de quelque manière que ce soit. Par exemple, comment puis-je lire parse () à partir d'un std :: ifstream ? Qui ferme le dossier après? Si ne peut pas être l'analyseur. Cela ne peut pas non plus être moi, car appeler l'analyseur m'a obligé à remettre l'objet. En même temps, je sais que l'analyseur ne pourrait même jamais savoir qu'il devait fermer le fichier que j'ai remis…

Il fera toujours la bonne chose à la fin car il n'y avait aucun moyen qu'une implémentation de l'interface ait pu réellement faire ce que l'interface suggérait de faire et donc mon std :: ifstream destructor exécutera et fermera simplement le fichier. Mais qu'avons-nous gagné exactement en nous mentant comme ça!? Vous avez promis de prendre en charge l'objet quand vous n'alliez jamais, j'ai promis de ne plus jamais toucher l'objet alors que je savais que je devrais toujours le faire…

Votre hypothèse selon laquelle le paramètre de référence rvalue implique "s'approprier" est complètement incorrecte. La référence Rvalue est juste un type de référence spécifique, qui vient avec ses propres règles d'initialisation et de résolution de surcharge. Ni plus ni moins. Formellement, il n'a aucune affinité particulière avec le «déplacement» ou la «prise de possession» de l'objet référencé.

Il est vrai que la prise en charge de la sémantique de déplacement est considérée comme l’un des principaux objectifs des références rvalue, mais vous ne devez pas supposer que c’est leur seul objectif et ces caractéristiques sont en quelque sorte inséparables. Comme toute autre fonctionnalité du langage, il peut permettre un nombre important d'utilisations idiomatiques alternatives bien développées.

Un exemple de citation similaire à ce que vous venez de citer est en fait présent dans la bibliothèque standard elle-même. Ce sont les surcharges supplémentaires introduites dans C ++ 11 (et C ++ 17, selon certaines nuances)

#include <string>
#include <sstream>

int main() 
{
  std::string s;
  int a;

  std::istringstream("123 456") >> a >> s;
  std::istringstream("123 456") >> s >> a;
  // Despite the obvious similarity, the first line is well-formed in C++03
  // while the second isn't. Both lines are well-formed in C++11
}

Leur objectif principal est de «combler» la différence comportement entre les surcharges membres et non membres de l'opérateur

template< class CharT, class Traits, class T >
basic_ostream< CharT, Traits >& operator<<( basic_ostream<CharT,Traits>&& os, 
                                            const T& value );

template< class CharT, class Traits, class T >
basic_istream<CharT,Traits>& operator>>( basic_istream<CharT,Traits>&& st, T&& value );

Il tire parti du fait que la référence rvalue peut se lier à des objets temporaires et les voir comme des objets modifiables . Dans ce cas, la référence rvalue est utilisée à des fins qui n'ont rien à voir avec la sémantique de déplacement. C'est parfaitement normal.