std::wcout, std::wformat_string, std::format wide string overloads and many
more already exist. wprint is the only one missing anyway.

On Sun, 30 Mar 2025, 12:41 Tymi, <tymi.cpp_at_[hidden]> wrote:

> I understand all that. But it is definitely possible to make an overload
> that accepts std::wostream, since there already exists with std::ostream. I
> only work with Windows specific code, and I consider wprint to be a
> necessity in C++.
>
> On Sun, 30 Mar 2025, 12:39 Tiago Freire, <tmiguelf_at_[hidden]> wrote:
>
>> I know that this is something that looks like a good idea, but isn't,
>> once you understand the underlying details.
>>
>>
>>
>> This would not make for portable code, it would at most only work on
>> Windows and even at that not universally.
>>
>> I’m assuming that what you are trying to use is the (W)ide versions of
>> Windows API’s such as “WriteConsoleW”.
>>
>>
>>
>> First things first this would never work on Linux because the only means
>> of output is an 8bit per character interface, and wchar_t can be 32bit per
>> character (or 16bit depending on compiler options), so you would need to
>> convert a text sequence from wchar_t to a char type.
>>
>> What is the encoding of text in “wchar_t” sequence?
>>
>> The encoding of “char” is not even consistent other than “system
>> encoding” (whatever that means), “wchar_t” is definitely not defined. Good
>> luck sorting that one out!
>>
>>
>>
>> You would think that the encoding of wchar_t would at least be more
>> defined on Windows, surely it must be UTF-16 right? Wrong! It’s not! It is
>> not only not consistent from system to system, it is not consistent with
>> application running in the same machine, even worse; an application could
>> change at runtime what “wchar_t” means when you pass it to “WriteConsoleW”,
>> it’s a feature, please see “SetConsoleCP”.
>>
>>
>>
>> Now, why is it named “Write”-“Console” and not just “Write”-“Out”? And
>> how is it possible that “WriteConsoleW” is able to pass 16bit per character
>> streams when cout is definitely 8bit per character stream?
>>
>> Because they are actually 2 separate streams bundled in the same output
>> interface! (cout)
>>
>> “WriteConsoleW” only works when the parent process has created a special
>> “Console” buffer output (which a console does) which has the twin streams,
>> and when you use “WriteConsoleW” it asks to use the alternative 16bit
>> stream bundled on the output channel.
>>
>> If you tried to use a pipe (for example to write out to a file) and the
>> application “WriteConsoleW” is used, “WriteConsoleW” will fail (because the
>> twin 16bit stream doesn’t exist) and none of those messages will be seen.
>>
>>
>>
>> “WriteConsoleW” is only meant to work if an application is attached to a
>> console (or a console like application, that specifically provides console
>> like features).
>>
>> It is not meant for general use applications.
>>
>>
>>
>> This is a mess. To much operating system specific behavior. You don’t
>> want to touch it.
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> *From:* Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf
>> of Tymi via Std-Proposals <std-proposals_at_[hidden]>
>> *Sent:* Sunday, March 30, 2025 11:30:31 AM
>> *To:* std-proposals_at_[hidden] <std-proposals_at_[hidden]>
>> *Cc:* Tymi <tymi.cpp_at_[hidden]>
>> *Subject:* Re: [std-proposals] std::wprint/std::wprintln
>>
>>
>>
>> I mean, I am up to making std::print just accept std::wformat_ string but
>> I am aware many members would not like that...
>>
>>
>>
>> On Sun, Mar 30, 2025 at 11:19 AM Tymi <tymi.cpp_at_[hidden]> wrote:
>>
>> wide string support for std::print/std::println would be neat. I need it
>> in my projects.
>>
>> I can write a proposal & possible implementation if enough people support
>> this!
>>
>>
>>
>> tymi.
>>
>>
>>
>