You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There exist terminals that can only display Unicode via a "native Unicode API", and terminals that can display Unicode simply via the normal means of dumping output. The intent of the issue is that only the former require the determination if a stream refers to such a terminal, and require flushing the "normal" output before invoking such a "native Unicode API" to output Unicode.
In real world terms, "native Unicode API" means "WriteConsoleW on Windows". Non-Windows platforms are supposed to ignore these instructions but it wasn't clear to them that they should, so the issue is trying to clarify that intent.
Of course there are also terminals on Windows that are capable of displaying Unicode via the normal output mechanisms. My machine with the "Beta: Use UTF-8 for language support" feature activated defaults to codepage 65001 in terminals and doesn't need "native Unicode API" to output Unicode. At some point we should start detecting this condition and avoiding the mess of flushing stdout and transcoding to UTF-16 to call WriteConsoleW.
TLDR: We don't need to do anything for correctness with regard to LWG-4044, we may want to make changes for performance.
The text was updated successfully, but these errors were encountered:
Quick-and-dirty bit of investigation I did yesterday after posting the comment:
diff --git a/stl/src/print.cpp b/stl/src/print.cpp
index 77c31478..d4aceb7d 100644
--- a/stl/src/print.cpp+++ b/stl/src/print.cpp@@ -46,6 +46,13 @@ extern "C" {
return __std_unicode_console_retrieval_result{._Error = __std_win_error::_File_not_found};
}
+ if (GetConsoleOutputCP() == CP_UTF8) {^M+ // The console is set up to output UTF-8 normally. We don't need to route through WriteConsoleW;^M+ // we can perform normal output without flushing the stream buffers and transcoding to UTF-16.^M+ // Lie about the result, so the caller will avoid the "native Unicode API" code path.^M+ return __std_unicode_console_retrieval_result{._Error = __std_win_error::_File_not_found};^M+ }^M+^M
return __std_unicode_console_retrieval_result{
._Console_handle = static_cast<__std_unicode_console_handle>(
reinterpret_cast<_STD underlying_type_t<__std_unicode_console_handle>>(_Console_handle)),
This needs a lot of investigation to make sure we're cutting the correct corners and not the wrong ones. And maybe we could improve the naming of the functions to make it clear that the intent has changed from "do Unicode things" to "only do Unicode things when we must".
At the November 2024 meeting, LWG-4044 "Confusing requirements for
std::print
on POSIX platforms" was resolved in the C++ Working Paper.In #5109 (comment), @CaseyCarter explained:
The text was updated successfully, but these errors were encountered: