C++ 23 Does std::print or std::println flush the output stream?

Question

Prior to C++ 23, when using std::cout to send output to stdout, there is a distinction between the following two ways of adding a new line at the end of the printed string:

• std::cout << "Hello World\n";
• std::cout << "Hello World" << std::endl;

The second of these is often preferable as it causes the output stream to flush, rather than requiring a call to std::cout.flush().

With C++ 23 there are now two new functions for printing, along with a new component to the standard library. We have std::print and std::println.

Do either of these functions make a distinction when it comes to flushing the output stream?

Or, is it the case that flushing the output stream is no longer a concept which is relevant in these new implementations?

Documentation from cppreference does not mention flushing:

• cppreference: print
• cppreference: println

Answer 1

As far as I can tell, the standard doesn't specify explicitly; however, the function call is the equivalent of vprint_nonunicode or vprint_unicode with stdout as it's first parameter. These in turn have the effect of writing vformat to the stream. Since vformat would not flush, it stands to reason that vprint_(non)unicode would not, and thus print would not.

See print.fun

Note: not in the html version, but the updated .tex file for the standard does state that there is a flush prior to the print. https://github.com/cplusplus/draft/blob/main/source/iostreams.tex

If the native Unicode API is used, the function flushes \tcode{os} before writing \tcode{out}

Answer 2

The standard does not specify this.

I have looked at Microsoft STL sources of print and MS print flushes streams if they output to an Unicode console. It seems they want to avoid undesired splitting bytes of multibyte characters when several streams output to a console.

Answer 3

The stream is not explicitly flushed, except if the ordinary literal encoding is UTF-8 and the stream is connect to a Unicode-aware terminal (as determined in an implementation-defined matter). This is a special case where the new <print> additions guarantee correct encoding for the terminal (which the old C++ IO does not guarantee). See P2093.

But in that case the stream is only flushed before writing the output and only to avoid potential synchronization issues with the underlying stream. See P2539.

Of course the underlying stream is usually line-buffered if connected to an interactive terminal, so that writing '\n' to it implies a flush. But that is implementation-defined. It seems that with the Windows CRT there is even a flush after every library call if connected to a character device, according to P2539 above.

So it behaves like printf or the single << in the old C++ IO API in that regard. If a flush is required outside of the implementation-defined buffering behavior mentioned above, then it must be done manually as before, using std::flush or std::fflush.

Maybe relevant is that std::print/std::println without explicit stream/FILE* argument will print to stdout, not std::cout, so if sync_with_stdio was set to false, only std::fflush(stdout) should be ok.