Why Cin and Cout?

I don't understand what cin and cout accomplish in C++ that isn't already accomplished in C's similar functionality like fgets, scanf, etc... Of course they're probably also compatible with std::string, but does anyone know why they went with the >> << formatting syntax stuff rather than a typical print function?

The syntax for these two constructs just seems bizarre and out-of-place compared to most other things in the language. I also come from C and don't quite understand the purposes of having them.

Can someone give a brief history lesson on why cin and cout were created? And why there's "endl" rather than \n? Although I would assume in endl's case that the particular endline char changes platform to platform so endl is an abstraction which takes care of that.

This might be mentioned in Stroustrup's The Design and Evolution of C++, but I'm afraid I never got round to reading that myself so I can't say for sure. My guess is that Stroustrup thought they expressed the direction of "streams", and the operator chaining does allow the streams to be manipulated midway in a statement that looks more linear (like a flowing stream?) than when expressed as nested function calls.

On the flip side, I've heard the argument that that syntax is an example of misuse of operator overloading. Yet, it's already ingrained into the "C++ culture", which means similiar overloading for other kinds of "resource I/O streams" (databases? Network communication?) has become arguably acceptable.

As for endl: note that it explicitly flushes the output stream, whereas printing a newline only causes an output stream that will be flushed on encountering a newline to be flushed (unless the stream is due to be flushed anyway, in which case it doesn't matter what you print). The abstraction for different platforms having different newline sequences already occurs in C for text mode versus binary mode streams.

Working backwards (sort of)....endl is known as a manipulator, while "\n" is just a literal character. As a manipulator, endl also flushes the stream.

Before I move more to your question, I'd point out that your puzzlement is shared by many developers of considerable experience. cin and cout are from among the first versions of the language, exhibit some of the earliest thought on the subject, and leave much to be desired under a number of use case circumstances. With so much code using the printf family, you still find considerable use of fprintf even though it is known to have safety issues and promotes bugs. You don't find cin and cout used much in professional code because they are the standard out and standard in of the console, which is not popular usage in modern work. Experiment shows iostreams using the << & >> operators is not high performance. The most code usage I know of is in student work, because they are safe, reliable and demonstrate something about object behavior.

fgets, for example, only gets strings. If used to get numbers, one must resort to atoi, atof, etc. The parameter, taking a char *, is a paradigm typical of C which historically we know promotes bugs. That does not mean one should favor the stream operators just due to this point. In my own opinion, coming from decades of development, a good or proper reaction to the discomfort one might have with stream operations, and acknowledging the bug inducing habits of the older C style functions, is to create objects for file operations which may better suit one's interests, making file operations safer and faster. Although one can use the iostream library for, say, image catalogs (say, for a group of images in a 3D rendering / materials manager), it may well be better design to focus on a container like operation that expresses the intent more logically, which is then managed to disk I/O in a hidden manner (which can then mutate to the best approach for a particular operation system/platform).

The stream operators are, however, a demonstration from the early versions of C++ of object behavior. One can send various types of data to cout, and provide operator overloads for custom types, which have no simple counterpart in the C style functions. That is cout << i and cout << s both work where i is an integer and s is a string. The operator adapts to type - or, perhaps it is better to say selects the specific operation appropriate for the type.

In a further demonstration of object behavior, the stream operators may apply to strings as well as files. That is, the same code that sends data to a file could send it to a string. This is obviously not a world shattering accomplishment, and perhaps you'll see that more in student level code than in professional work, but the consistency is not to be found in the operator chosen (it was foreshadowing other similar differences we would come to know, like templates), but that the behaviors invoked by type selection is consistent over various usage cases. To a degree it wouldn't matter if the stream is a file, an Internet connection, a string...the code would be all but the same. Merely choosing the appropriate stream (or a custom stream) would suffice, providing indirection.

The stream operators were, indeed, a new selection - because, rather precisely, it had no conflict with C's existing operators. It is actually less the fact it looks odd "<<" or ">>", but that it is an operator and not a member function of the iostream class with a more recognizable name. There are some behaviors we expect from operators that differ from function calls. In particular, a = b = c, which isn't all that illuminating on it's own, is not all that different from cout << a << b << c. Imagine a member function call in place of each "<<" operator (member of cout), and perhaps it seems clearer the motivation.

As to the point of a typical print function, printf formatting is historically known to be a source of several types of bugs associated with matching the parameters to the format string, even though it has been widely used and well known. It is still used, and still available (in forms considered 'safer' than the original). There are newer ideas about formatting which have been demonstrated from the Boost library which give rise to proposals for the upcoming C++ releases (perhaps C++ 20). These ideas combine the concepts in a better way than we've had up to now, but are not the basic examples we see in student code using cout for streaming output. They can't easily handle, say, comma separated numeric values, but then did that ever work well in fprintf? The new proposals can do that (see Boost for the proposed ideas).

@laserlight, that's just an example of two well trained members posting similar or related answers at the same time, and not realizing it until both have posted.