[libcxx-commits] [PATCH] D146398: [libcxx] Fix using std::wcout/wcin on Windows with streams configured in wide mode

[Tom Honermann via Phabricator via libcxx-commits]

tahonermann added a comment.

> It does something somewhat reasonable at least; `fopen(); fputwc()` ... on Linux writes the wchars as plain ASCII, anything outside of the ASCII range seems to produce literal ? chars.

The `fputwc` man page claims conversion to the locale encoding; which defaults to "C" unless `setlocale()` has been called. So ASCII by default, but maybe not.

> Can you show examples on how one could experimentally try out imbuing a nondefault locale for the wcout/wcerr/wcin streams, to experimentally see how MS STL behaves in that case?

Here you go: https://godbolt.org/z/esP1535P4. Interesting, it looks like the Microsoft and libc++ implementations both call the `codecvt` members for each individual character while libstdcxx batches them. (I had to test MSVC locally; I look forward to someday being able to run MSVC generated code on godbolt.org again!)

> So with that in mind, I guess we should try to keep the current codepaths that do conversions but either avoid hitting them or keeping the original wchar form around if noconv is returned... I guess I should sit down with the MS STL implementation and see if I can trace what codepaths it ends up using for e.g. wcout.

I would expect that `noconv` will never be true when the internal and external character types differ since, at a minimum, a (potentially narrowing) copy has to be performed.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146398/new/

https://reviews.llvm.org/D146398