comment cout << fonctionnent réellement?

Je me demandais comment std::cout est en mesure d'utiliser << comme il le fait.

Ma principale de la perplexité est de savoir si std::cout comme un exemple de quelque chose. En gros, comment est << défini? Si je fais cela pour une classe personnalisée, j'ai besoin d'une instance de la sorte...

J'ai pu voir de la mettre en œuvre comme une sorte de hack avec le vide des pointeurs ou quelque chose, mais je tiens à voir la façon dont c'est fait.

Ce que quelqu'un ici sait?
Grâce

  • Si vous voulez vraiment voir beaucoup sur iostreams, vous voudrez peut-être jeter un oeil à une copie de amazon.com/Standard-IOStreams-Locales-Programmers-Reference/dp/...
  • Le cout << et cin >> expressions sont les raisons pour lesquelles C++ est donc pas intuitif et difficile à apprendre.
  • Si vous choisissez une langue en raison de la façon dont on écrit à la console, vous avez le choix de la langue pour les mauvaises raisons. Je suis d'accord la iostream bibliothèque est complexe, mais il ya beaucoup de superbes aspects de la langue qui ne sont pas liées à iostream à tous (c'est à dire la STL). (Si vous n'aimez pas iostream, alors ne l'utilisez pas. Utiliser les bits de <cstdio> ou des morceaux spécifiques à votre plate-forme.)
  • Ce n'était pas la console d'écriture dont je parlais, c'était le fait qu'un débutant doit savoir surcharge des opérateurs avant qu'il ne puisse même commencer à comprendre ce qui se passe réellement...
  • En outre, a << b; doit pas avoir été autorisé déclaration; il est juste de dire 2 + 3;, qui-même si elles sont valides -- n'a pas de sens. Si quoi que ce soit, ils devraient ai fait a <<= b; de sorte qu'il pourrait au moins donner l'impression au lecteur que certains types de travaux est actuellement en place.
  • Dire que quelque chose est mauvais parce que vous ne comprenez pas il ne suffit pas de raisonnement pour prouver qu'il est mauvais. 2 << 3 n'invoquent pas la surcharge d'opérateur à tout. Comme pour la rendant illégale, vous pouvez écrire n'importe quoi dans n'importe quelle langue. La langue de travail n'est pas de vous empêcher de faire des choses stupides.
  • Err.. vous avez modifié votre commentaire et maintenant la mienne, au-dessus de ne pas faire comme beaucoup de sens. Mais le point d'arrivée est encore vrai. Pouvez-vous faire de mauvaises choses avec la surcharge d'opérateur? Assurez-vous. Mais juste parce que vous pouvez faire de mauvaises choses avec une fonctionnalité ne veut pas dire que la fonction ne devrait pas exister.
  • Les ruisseaux se sentir incroyablement pas intuitif, surtout quand il s'agit de formaté IO et des flux de manipulateurs. @Billy: c'est Drôle que vous mentionner que (à propos de l'utilisation de style C IO), j'ai demandé à un question à propos de le faire et la réponse de C++ - dessus des lois ont été essentiellement "C'est faux, vous n'êtes pas à l'aide de C++ la façon dont il est destiné à être utilisé".
  • La surcharge d'opérateur et de la définition de "déclaration" étaient de distinct les questions que je faisait allusion, à la fois avec leurs propres usages. Et juste parce que vous comprenez cela ne veut pas dire que c'est bon, soit... je comprends tout à fait ce qui se passe mais je pense toujours que c'est mauvais: de même que la phrase Two plus three n'a pas de sens en tant que phrase en anglais, le code 2 + 3; ou a << b; ne fait pas vraiment beaucoup de sens en tant que déclaration soit, et le fait qu'il est valide de fait rend le C++ est vraiment difficile à apprendre (pour ne pas mentionner faire plus facile pour vous de se tirer dans le pied).
  • Eh bien, hardcore C++ les gars, comme moi, sont allez vouloir vous d'utiliser iostreams bien sûr, mais il ya beaucoup de gens qui ne les aiment pas. C++ n'est pas une langue qui force beaucoup sur vous. Si vous n'aimez pas la bibliothèque, alors ne l'utilisez pas.
  • Ce n'est pas une langue de travail à faire du mal à tirer une balle dans le pied. C'est la langue de travail à proprement exprimer ses pensées sous une forme que l'ordinateur peut comprendre. Dans une langue où l'on peut adresser la mémoire et de provoquer des erreurs de segmentation et de dépassements de la mémoire tampon et de toutes sortes de choses désagréables, rendant difficile tout-à-tirer-en-footness aurait été (et est) une folle objectif de conception. Si vous voulez une langue avec de tels objectifs, puis descendre notre pelouse et allez utiliser Java ou C#.
  • Ce n'est pas le flux d'e/S de la bibliothèque à la question. Compte tenu de ce que le C++ a, la bibliothèque est assez bien écrit, en fait. Le problème est que le langage permet pour à peu près n'importe quelle expression à une déclaration -- quelque chose que beaucoup d'autres langues ne permettent pas, parce que honnêtement n'a pas de sens - à-dire 2 + 3;, et il conduit à la confusion de deux le programmeur et le lecteur. Avaient-ils réellement forcé l'utilisation de certains affectation opérateur comme cout <<= "hi"; au lieu de cout << "hi";, à mon humble avis, la langue (et, par conséquent, la bibliothèque d'e/S) aurait été beaucoup mieux.
  • Il ne fait pas de sens de faire a.Select((x) => x) (où a est un IEnumerable) en C#, mais la langue vous permet de le faire. Si vous voulez être stupide, vous pouvez être muet n'importe où. Si vous voulez "intuitif pour un débutant" comme une exigence de la langue, alors n'utilisez pas le C++.
  • Ce n'est pas une question de langue... Select ne fait pas partie du langage C#.
  • Pourquoi importe-t-il si c'est un problème de langue? Pas intuitif n'est pas intuitif.
  • C'est drôle de voir comment beaucoup de langues ont emprunté de style C IO (Ruby, Python, Shell, Allez, Java, C# [dans une mesure]), mais je ne peux pas penser à un qui utilise le C++de style.
  • Oui, vous avez entièrement raison, c'est juste aussi mauvais pour a.Select((x) => x) en C# comme il est d'écrire a << b; en C++, parce que ni vraiment de sens comme une déclaration. Pas sûr de ce que vous essayez de dire, mais... il vient soutenir mon point de plus. 🙂
  • Mon point est que le fait de dire "je peux faire en fonction de x faire n'importe quoi!" n'est pas une justification pour la suppression de cette fonctionnalité (au moins en termes de but générale des langages de programmation). N'importe qui peut écrire du code dans n'importe quelle langue à l'aide de la plupart de toute fonction qui ne fait de bêtises. Vous pouvez écrire des bêtises quand vous le souhaitez. La langue n'a pas besoin que du code soit de haute qualité; c'est le programmeur de la responsabilité.
  • En fait je suis d'accord avec vous, là -- je ne suis pas un fan de iostreams -- la principale raison que je le préfère sur cstdio est que iostreams rend l'écriture de code de tests facile; cstdio ne fournit pas une façon de faire (par exemple) un FILE * point d'une chaîne de caractères.
  • Je ne dis pas I can make feature x do nonsense!; je dis la Caractéristique x est non-sens!, où x est la capacité des déclarations comme a << b;. Je ne suis pas opposés à la surcharge d'opérateur, je ne suis rien dire à propos de la bibliothèque d'e/S. Ce que je dis, c'est que, a << b; doit être syntaxiquement invalide comme une déclaration pour la même raison que C++ needs. est pas valide phrase en anglais: ni fait beaucoup de sens. S'il avait été a <<= b;, il aurait effectivement fait sens, parce que = implique l'effet secondaire d'une cession, alors que << ne l'est pas.
  • Alors, comment voulez-vous le soutien a << b << c?
  • Je crois que vous avez manqué le point: a << b << c devrait être valide, mais a << b << c; ne pas. (Avis de la ;.)
  • Ok, a << b << c; ensuite. Il est de la forme expression;, que vous ne pouvez pas supprimer parce que c'est pourquoi (par exemple) a++; œuvres.
  • C'est facile: vous n'avez pas. (Voir C#, Java, D, et toute une flopée d'autres langues que l'obtenir parfaitement sans elle.)
  • Pouvez-vous être un peu plus précis? Je pense que nous pouvons tous les deux d'accord que a << b doit être une expression possible. Je pense que nous pouvons tous les deux d'accord que expression; ne peuvent pas aller, comme je l'ai déjà illustré. Exactement comment voulez-vous résoudre ce problème?
  • Oui, nous avons tous deux d'accord que a << b doit être possible expresssion. Non, nous ne sommes pas d'accord tous les deux que toute expression doit être une instruction valide; en particulier, a << b; ne doit pas être une instruction valide, parce que le << opérateur de ne pas transmettre le fait qu'il est à l'origine d'une cession. Et par la manière, C# pas le permettent.
  • Mais il n'est pas causant une cession. C'est l'appel d'une fonction. De laquelle l'utilisateur peut surcharge de faire ce qu'ils veulent.
  • Jetez un oeil à cette C# erreur lorsque vous tapez dans 1 << 2;, ou quoi que ce soit de la forme a << b, pour cette question: error CS0201: Only assignment, call, increment, decrement, and new object expressions can be used as a statement
  • Si vous avez été la conception d'une nouvelle version de l'anglais, serait vous laisser la phrase C++ is not very. être une phrase grammaticalement correcte?
  • Bon, alors nous sommes en désaccord. Revenir à 1978 changement de Dennis Ritchie, l'esprit, et alors il peut être changé. La langue n'est pas conçu pour faire des bêtises invalide parce que quelqu'un est un idiot. Il est conçu pour quelqu'un qui sait ce qu'ils font pour exprimer des idées. C# et le C et le C++ ont différents objectifs de conception. C# a la prévention des non-sens comme un objectif. Le C et le C++ ne le font pas.
  • Je ne vois pas comment votre anglais exemples ont rien à voir avec le C++ exemples.
  • La connexion est, a + b; en C++, c'est comme A plus B. en anglais. Ce dernier n'a pas de sens en tant que phrase, et donc ne doit pas non plus comme une déclaration... je pense qu'il suit de très logiquement, étant donné que les humains sont censés être la lecture de code et de ne pas les ordinateurs.
  • comme Billy dit, a << b n'est pas nécessairement causer une cession. Quand il s'agit de cours d'eau, le débutant que vous êtes si soucieux de protéger doit être pensée de ce "flux de b à travers une", de sorte que le vaguement ressemblant à des flèches directionnelles et de la nature de la moins-que le caractère est utile, et pour cout ils ne se soucient pas de mise en mémoire tampon: ils savent juste les données envoyées et disparu, de sorte que la cession serait trompeur ("hey, n'est-il pas de se coincer dans le cout? je ne peux pas le récupérer?"). Et les autres langues adopter style C++: exemple: Ruby: $stdout << 99 << " red balloons"... semble familière?
  • Auriez-vous l'esprit la lecture de la quatrième gras paragraphe ici? Il dit: Ne pas être intelligent lors de la définition de la surcharge de l'opérateur. La surcharge d'opérateur est utile dans les cas où il est immédiatement évident que le résultat de l'opération sera. Par exemple, il est logique d'être en mesure de soustraire un objet DateTime à partir d'un autre objet DateTime et d'obtenir un objet TimeSpan. Cependant, il est pas est approprié d'utiliser la logique de l'union de l'opérateur à l'union de deux requêtes de base de données ou utiliser l'opérateur de décalage à écrire à un flux de données. (l'emphase est mienne)
  • et merci de ne pas la dénoncer comme C#spécifiques. Elle s'applique à beaucoup plus de langues que juste C#, et la raison derrière le "ne pas faire le malin", c'est à dire de lisibilité -- s'applique partout. Il n'y a pas de raison pour rendre les choses plus compliquées qu'elles ne devraient l'être; c'est là que le C++ a échoué, avec des choses comme l'utilisation abusive de la surcharge d'opérateur et le mauvais choix de permettre une expression que ce soit pour être considérée comme une déclaration.
  • MSDN est cheapshot est exactement ça. "C++" échec? Je suis désolé, mais je n'accepte pas votre auto-nomination à titre de juge. La lisibilité est importante, et compte tenu de la mains sur l'expérience de l'enseignement de Stroustrup a eu, je suis sûr qu'il aurait fait quelque chose au sujet de << si les nouveaux développeurs ont eu de la difficulté avec elle. Vous êtes juste être mélodramatique, mais n'hésitez pas à utiliser le C++0x variadic macros pour mettre en œuvre un type-safe "print(a, b, c)" si vous manquez de BASE. ;-P
  • Si vous pensez que MSDN juste dit que pour promouvoir C# contre? Si oui, comment est-elle une promotion -- est-ce parce que (à Dieu ne plaise!) c'est un bon conseil? Si non, alors pourquoi avait-il dit cela? Juste pour tromper les gens? Aussi, vous êtes à la nouveau à côté du fait que je ne parle pas des I/O! Je fais allusion à la façon dont les expressions et les instructions sont traitées en général... je ne suis pas sûr de savoir pourquoi vous toujours le problème d'e/S, parce que je suis en aucune façon de distinguer iostream contre toute autre partie du C++.
  • Essayez de prendre un coup d'oeil à cette page, d'avoir à faire avec le C++ lui-même: Si vous constructive opérateurs, ils ne devrait pas changer leurs opérandes. Par exemple, x + y ne devrait pas changer x. (Idem avec les <<.)
  • Hein??? Given the hands-on teaching experience Stroustrup has had I'm sure he'd have done something about << if new developers had trouble with it. Vous pensez donc que les débutants n'ont aucune difficulté avec elle? Pour une chose, j'ai eu du mal avec elle quand j'étais un débutant. Pour une autre chose, je ne suis pas vraiment seul; mes amis me posent la même question quand ils sont en train d'apprendre le C++, et même d'autres demandent à cette même question sur DONC. Je doute que Stroustrup avait les yeux d'un débutant quand il a conçu le C++, et je ne suis pas à voir pourquoi vous avez appelé ce un cheapshot.

InformationsquelleAutor Ori | 2011-04-01
  1. 46

    std::cout est une instance de std::ostream. std::cout << "something" appelle l'un de l' operator<< surcharges comme il devrait le faire pour n'importe quelle instance de std::ostream.

    C'est "spécial", en ce qu'elle fait référence à la console, mais sinon, il se comporte exactement comme un ofstream ou un ostringstream serait.

    MODIFIER: Chaînage fonctionne comme il fonctionne pour tous les autres opérateurs. Considérer:

    class MyType
{
    friend std::ostream& operator<<(std::ostream& target, const MyType& source);
    int val;
public:
    MyType()
        : val(0)
    { }
    MyType& Add(int toAdd)
    {
        val += toAdd;
        return *this;
    }
};

MyType& operator+(MyType& target, int toAdd)
{
    return target.Add(toAdd);
}

std::ostream& operator<<(std::ostream& target, const MyType& source)
{
    target << source.val;
    return target; //Make chaining work
}

int main()
{
    MyType value1;
    value1 + 2 + 3 + 4;
    std::cout << value1 << " and done!" << std::endl;
}

    Dans ce cas, le chaînage de +s sur MyType travaillent pour la même raison, le <<s de travail sur le dessus de std::ostream. Les deux + et << sont associatifs gauche, ce qui signifie qu'ils sont évaluées de gauche à droite. Dans le cas de la surcharge des opérateurs, l'opérateur est remplacé par l'équivalent de l'appel de fonction.

    EDIT2: Dans un peu plus en détail:

    Disons que vous êtes le compilateur et vous êtes l'analyse

    std::cout << value1 << " and done!" << std::endl;

    D'abord, << est associativité à gauche, afin de vous lancer sur la gauche. Vous l'évaluation de la première << et de le transformer en l'appel de la fonction:

    operator<<(std::cout, value1) << " and done!" << std::endl;

    Vous voyez alors que vous une fois de plus, un std::ostream (le résultat de l'appel à operator<<), et un char *, qui une fois de plus vous tournez dans l'appel de la fonction:

    operator<<(operator<<(std::cout, value1)," and done!") << std::endl;

    et ainsi de suite jusqu'à ce que vous avez traité l'ensemble de la déclaration.

    • +1, Mais (pour jouer à un avocat), comment le chaînage de travail? (par exemple,std::cout << a << b ...)
    • Est-il aussi revenir un std::ostream? Je veux dire que vous pouvez aussi le faire cout << "quelque chose" << "autre chose". Comment fonctionne le deuxième opérateur<< utiliser?
    • Tous les operator<< surcharges sont de la forme std::ostream& operator<<(std::ostream& target, TYPE& source), et ils retournent la référence transmise en tant que source. C'est, std::cout << a << b; est le même que operator<<(operator<<(std::cout, a), b);
    • cplusplus.com/reference/iostream/ostream/operator%3C%3C fournit quelques détails de ce qui se passe.
    • Ajout d'un peu plus de la réponse à expliquer un peu plus clairement (je l'espère)
    • cout ne faisant pas référence à la console, il se réfère au système d'exploitation par défaut de sortie. Dans certains systèmes d'exploitation, cela arrive à être une console.
    • C'est vrai. Mais je ne pense pas aller dans cette discussion qui fait sens pour une réponse comme cela vise principalement à des débutants.
    • C++ Primer par Prata détails comment et pourquoi. J'ai lu une édition plus ancienne, même si, avec le C++ 03, je pense, ou à proximité de cette époque.
    • Pour ceux qui étaient encore confus au sujet de l'enchaînement (comme je l'ai été): Comme nous le savons, les opérations sont fondamentalement rien de plus que les méthodes des classes. Cela signifie qu'ils ont une valeur de retour, qui en quelque sorte ils peuvent être "remplacé par" (par exemple, l'écriture 3 + 5 peut être remplacé par 8). Dans le coutet cin de l'objet de cas, ces retour-les valeurs sont toujours des références à *this (dans ce cas, la référence est la même cout/cin-objet que vous avez effectué l'opération sur). Donc, lorsque vous écrivez: cout << 'a' << 'b', la première instruction (cout << 'a') renvoie "cout" qui laisse cout << 'b'
    • Avis: Le 3 + 5-l'exemple n'est pas du même concept (ne pas conclure d'objets), mais vous obtenez le point...
    • Est la << à l'intérieur de l'opérateur << le original, << opérateur de elle est de la récursivité?

    InformationsquelleAutor Billy ONeal