4 ms·

What's fun is, because everything is decided in papers, we can find out why! https://github.com/cplusplus/papers/issues/884 https://github.com/cplusplus/papers/

What's fun is, because everything is decided in papers, we can find out why! https://github.com/cplusplus/papers/issues/884 https://github.com/cplusplus/papers/issues/884 Accepted paper here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2093r14.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p20... > The proposed std::print function improves usability, avoids allocating a temporary std::string object and calling operator<< which performs formatted I/O on text that is already formatted. The number of function calls is reduced to one which, together with std::vformat-like type erasure, results in much smaller binary code (see § 13 Binary code). Additionally, > Another problem is formatting of Unicode text: > std::cout << "Привет, κόσμος!"; > If the source and execution encoding is UTF-8 this will produce the expected output on most GNU/Linux and macOS systems. Unfortunately on Windows it is almost guaranteed to produce mojibake despite the fact that the system is fully capable of printing Unicode

gavinray 3y ago
Whoever thought that the idiomatic approach to "Hello, World!" in their language ought to involve using special overloaded operators as symbols to act on pipes must've been on something very strange.
- steveklabnik 3y ago
  I don't disagree that iostreams feels like a mistake in retrospect, though you have to put yourself in the time period to understand why people make decisions the way that they do. Bjarne wrote the first version of that library in 1984! And it was moved into the standard in '98. https://stackoverflow.com/a/4854358/24817 https://stackoverflow.com/a/4854358/24817 is the canonical explanation for why >> and <<, apparently. Nearby, this is also mentioned: > C’s printf family of functions is an effective and often convenient I/O mechanism. It is not, however, type safe or extensible to user− defined types (classes). Consequently, I started looking for a type safe, terse, extensible, and efficient alternative to the printf family. Part of the inspiration came from the last page and a half of the Ada Rationale [Ichbiah,1979], which is an argument that you cannot have a terse and type− safe I/O library without special language features to support it. I took that as a challenge. The result was the stream I/O library that was first implemented in 1984 and presented in [Stroustrup,1985]. and > The stream I/O facility is implemented exclusively using language features available to every C++ programmer. Like C, C++ does not have any I/O facilities built into the language. The language simply didn't have the advanced tools that ended up being used in more modern solutions yet. It was too early.
- vitaut 3y ago
  It is weird but not unique to C++. For example, python used the % operator for string formatting. It's a simple but hacky way to feed arbitrary number of arguments in a type-safe way if you don't have variadics.
gettodachoppa 3y ago
I know you think this sounds like a good reason, but all I can think is that C++'s continues its mutation into a new language and adding to the developer's cognitive load, all for the purpose of a minor performance optimization. In what is already a very performant language. As usual, C++'s priorities are wrong for anyone who's not writing an OS, web browser, game engine, or otherwise rare type of project.
- steveklabnik 3y ago
  I agree with you that evolving languages that have been around for a long time is very difficult, with hard tradeoffs and unclear answers. I think calling formatted printing “cognitive load” is a bit much though. If anything this is easier to understand and use than stdio and iostreams. It’s closer to other languages in this area. I probably would have voted yes on this if I were on the relevant committee.

gavinray 3y ago

Whoever thought that the idiomatic approach to "Hello, World!" in their language ought to involve using special overloaded operators as symbols to act on pipes must've been on something very strange.

steveklabnik 3y ago
I don't disagree that iostreams feels like a mistake in retrospect, though you have to put yourself in the time period to understand why people make decisions the way that they do. Bjarne wrote the first version of that library in 1984! And it was moved into the standard in '98. https://stackoverflow.com/a/4854358/24817 https://stackoverflow.com/a/4854358/24817 is the canonical explanation for why >> and <<, apparently. Nearby, this is also mentioned: > C’s printf family of functions is an effective and often convenient I/O mechanism. It is not, however, type safe or extensible to user− defined types (classes). Consequently, I started looking for a type safe, terse, extensible, and efficient alternative to the printf family. Part of the inspiration came from the last page and a half of the Ada Rationale [Ichbiah,1979], which is an argument that you cannot have a terse and type− safe I/O library without special language features to support it. I took that as a challenge. The result was the stream I/O library that was first implemented in 1984 and presented in [Stroustrup,1985]. and > The stream I/O facility is implemented exclusively using language features available to every C++ programmer. Like C, C++ does not have any I/O facilities built into the language. The language simply didn't have the advanced tools that ended up being used in more modern solutions yet. It was too early.
vitaut 3y ago
It is weird but not unique to C++. For example, python used the % operator for string formatting. It's a simple but hacky way to feed arbitrary number of arguments in a type-safe way if you don't have variadics.

gettodachoppa 3y ago

I know you think this sounds like a good reason, but all I can think is that C++'s continues its mutation into a new language and adding to the developer's cognitive load, all for the purpose of a minor performance optimization. In what is already a very performant language. As usual, C++'s priorities are wrong for anyone who's not writing an OS, web browser, game engine, or otherwise rare type of project.

steveklabnik 3y ago
I agree with you that evolving languages that have been around for a long time is very difficult, with hard tradeoffs and unclear answers. I think calling formatted printing “cognitive load” is a bit much though. If anything this is easier to understand and use than stdio and iostreams. It’s closer to other languages in this area. I probably would have voted yes on this if I were on the relevant committee.