Hacker News Reader

Comment by bdw5204 | Hacker News Reader

What is the rationale behind changing how print statements work in C++? Is there something broken about using cout or is this just another case of C++ adding extra ways to do the same thing for the sake of adding extra ways to do the same thing?

The only significant difference I see is that std::println automatically includes the newline which may or may not be desired behavior.

View on HN

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

Accepted paper here: 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

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.

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 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.

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.

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.

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.

There are numerous shortcoming of the previous (iostreams) approach:

1. Incompatible with dynamically-generated format strings, in which the order of arguments is different. Example:

   std::cout << month << '/' << day << '/' << year

... but you now want to adapt that for a non-US locale, e.g. a European one where it's

   std::cout << day << '/' << month << '/' << year

with iostreams, you have to change the code. With C-style printf, you don't (but it's not typeafe and not flexible. But with std::print it could be:

   std::printf(my_format_str, day, month, year);

and `my_format_str` could be either "{0}/{1}/{2}" or "{1}/{0}/{2}".

2. The string allocations which other have mentioned.

3. A lot more typing that is easy to confuse: " << ".

4. The iostreams implementation is super-baroque, with buffer classes nobody uses.

and maybe I'm forgetting things.

Std:so std:you std:mix std:iosteam std:and std:printf?

Std:seems std:confusing

20 years ago, I worked on a fairly large C++ code base. Nobody used iostreams even then. We used C-style stdio everywhere. You can still do that.

I have been using iostreams since 1993, they were never the cause for performance problems we actually had to solve.

You've never had to deal with binary size concerns I suppose.

You never coded for MS-DOS and Amiga, I suppose.

Glad you asked. I recently wrote a post about it: https://vitaut.net/posts/2023/print-in-cpp23/.

iostreams were a mistake, is the shortest way to sum it up.

Absolutely! Glad to see it ending

Did you mean endling?

No, he meant backslashend.

Not for everyone, iostreams are great.

As you may imagine, the rationale behind offering a new way to do formatted output is not evidenced in a hello world statement.......

You can answer your own question if you google "println cppreference".

There's std::print

Reply on news.ycombinator.com