Why the operator << for ostream not overloaded for containers, such as vector , set , map ?

And if there are problems with overloading the operator << for ostream , then why not add a print or print_container function that could output containers.

I ask more because of curiosity and because such a trifle has to be realized by myself. Moreover, in many other languages, displaying containers is not difficult.

  • Because it is not "other languages" :) - Sublihim
  • 2
    Because to write such a conclusion is a matter of seconds ... But how exactly to draw the same vector is a moot point. The standard is the law: what is written with a pen, the horse-radish is then cut down ... And here it is impossible to be mistaken. - Harry
  • Yes, the implementation of such pieces is too opinion-based =) - vp_arth
  • one
    Притом, что во многих других языках выводить контейнеры не составляет труда. A well-known topic is that programmers with ++ easily solve tasks that Delphi programmers do not even know about;) - Oleg GranRCM
  • one
    In fact, this problem was solved long ago - louisdx.imtqy.com/cxx-prettyprint (there is one h file to be connected) - KoVadim

4 answers 4

Tell me how to correctly output vector<int> - separated by commas? with a fixed field width? Maybe take everything in brackets?

And vector<string> - do you need to put strings in quotes? or not?

And list<double> - with what exact accuracy and in what format to display?

Note that you decide this not for yourself, but for all C ++ programmers ...

Are you ready for such holy wars?

And write your conclusion - the second thing. Well, as a last resort, write copy(c.begin(),c.end(),ostream_iterator<int>(cout,",")) :-)

"I think so" (c) Pooh

  • For list<double> there are fixed and setprecision , but the vector of lines is really a problem, but even then you can get out. You can add the quotes flag, which will enclose the string in quotation marks, and " replace the symbols inside the string with \" . Although this will reduce the speed ... With the vector of lines is really a problem. - pank
  • one
    And to select an array in heap second business, and lines to compare with the help second strcmp ? Why are there! Someone parser to write a second thing or buffering with caching. Therefore, "second matter" is not an argument And your example is not a second at all. A vehicle case says. - Cerbo
  • 3
    “Tell me, how to display vector <int> correctly - comma-separated?” - for some reason this problem does not arise in other languages. - KoVadim
  • four
    And to make a wretched monster ... Have you ever wondered why, actually, in the C ++ library there are no masses of functions that exist in other languages? :) Understand ... you or a programmer in C ++, and then you will soon have questions - why the hell have you stuck so much extra into the standard library? or you are a programmer, roughly speaking, in Java, and then you have questions - why there is no separate function to remove all vowels from a word - after all, the teacher asked this particular task! It's just a worldview ... And, by the way, notice - what holy wars have already gone. And you also want to put it in the standard ... :) - Harry
  • one
    @ixSci It is not you and no offense, be it said, but ... Somewhere it was said that a person readily admits his unqualification in a particular issue, but everyone considers himself to be geniuses in politics, love and war, it seems ... I I would add - those who have learned a little programming, also believe that they would have made the language much better than Straustrup, and the standard would have written much better than accepted ... Hence, all these holy wars. Once again - this is not for you, so, your comment thought ... - Harry

First, containers consist of many elements, so it is not clear in what format to display the elements of the container. For example, you can display each item on a new line. You can display all elements on a single line, separated by spaces. And you can display all elements on a single line, separated by a comma or a semicolon, etc.

Secondly, containers can contain not only fundamental types, but also user-created types. In this case, it is generally impossible to predict in advance what the output of container elements should look like.

Therefore, in fact, it all comes down to operator overloading to display the elements of the container themselves. Responsibility for operator overloading for user-created types lies with the user. Having such an overloaded operator, it is not difficult to derive all elements of the container. And there are several such methods: you can use standard algorithms, such as std::copy , std::copy_if and others. Or you can use the usual cycles: for , while , do-while . Either use a range-based loop. And you can also set the conditions by which elements will be selected for withdrawal from the container.

As for other languages, this issue is usually solved by the fact that all objects are inherited from one basic object that has a virtual (or non-virtual) function toString (or ToString ). That is, any object that is created by the user already has a default output function to the stream. Or, the newly created objects already have some minimal interface, which also includes the function of converting an object to a string.

In C ++, there is no single object from which all other objects originated, and therefore there is no predetermined function for converting an arbitrary object to a string that can be output to a stream.

  • I hope you’re joking about different types in containers. This is all rulitsya templates. - Cerbo
  • @Cerbo And how does this "rulitsya templates" when you can not even know in advance what data members a custom type has? - Vlad from Moscow
  • @VladfromMoscow, whether a programmer should worry about how and how his data types are displayed. - pank
  • @pank I have it written in the answer. - Vlad from Moscow
  • one
    @VladfromMoscow So I’m talking about this to you and saying that you have a contradiction. On the one hand, you "cannot predict at all," but on the other hand, "it all comes down." If you cannot predict something, then it cannot be reduced to anything. If it is possible to reduce all the same, then what prevents the operator from implementing << for containers? Nothing! Therefore you justify that which has no justification. - Cerbo

There are no technical problems. For separators, parentheses and other decorations, nothing prevents you from adding the same modifiers as for integral types. The release would look like this:

 template<typename T> std::ostream & operator << ( std::ostream & printer , const std::vector<T> & items ) { printer << std::begin_scope(); std::copy( items.begin() , items.end () , std::ostream_iterator<T>( printer , std::delimeter()) ); printer << std::end_scope(); return printer; }

In terms of input / output, they reproduced the functionality of the standard C library only in C ++ :) It is assumed that the programmer will write with his hands as he needs.

    I think the problem of implementing output to stream for standard containers is much more serious than the choice of output format and separators. Suppose the operator << has been implemented in STL containers. Of course, the simplest thing you can think of is that it bypasses all items and puts them into the output stream with the same << operator. Hence, a reasonable requirement for all types used in containers is the presence of a stream output operator. Agree, not very flexible

    • one
      Well, as if everything is flexible ideone.com/yAigAh - KoVadim
    • Now put a custom type in the vector - a simple structure from one field fits perfectly, and see if your code will be compiled or not - Malov Vladimir
    • Of course it is composited. - KoVadim
    • You must be joking. Your foo structure does not have a stream output operator, it will not apply to a compilation error - Malov Vladimir
    • @KoVadim place the vector x on the output stream - Malov Vladimir