Date: Sun, 30 Mar 2025 13:13:43 +0200
I can add std::wprint to my C++ implementation as a language extension I
guess...
Also really, why can't it just fallback to converting to UTF8 on
unsupported systems??
On Sun, 30 Mar 2025, 13:11 Tiago Freire, <tmiguelf_at_[hidden]> wrote:
> Then that’s very easy, we can make “std::wprint[ln](L"Hi");” a no-op, i.e.
> it does nothing.
>
> Perfectly consistent behavior.
>
>
>
> But I doubt that is what you want.
>
> You want it to do something, you want it to do a very specific thing, you
> want it to print out a message, and if you do that you expect to be able to
> read said message. And now we are back to questions related to “what is the
> encoding” and “how will you make it work and in what circumstances does it
> work”. You may be fine with “I don’t care, just do something” (to which I
> would argue, doing nothing is a something). But I’m not!
>
>
>
> You are free to pursuit this but be aware that these questions will come
> back to you.
>
>
>
> I have tried to go down this road, didn’t even made it to a proposal.
> There’s nothing that stops you right now from trying to implement these
> features as a library, putting this in the standard will not magically make
> the operating system have an interface that it doesn’t currently support,
> it has to be a library feature, so you can start writing it today.
>
> So, you should try it as an exercise, make a portable library. That’s how
> I started, that’s how I stopped.
>
>
>
> *From:* Tymi <tymi.cpp_at_[hidden]>
> *Sent:* Sunday, March 30, 2025 12:55 PM
> *To:* Tiago Freire <tmiguelf_at_[hidden]>
> *Subject:* Re: [std-proposals] std::wprint/std::wprintln
>
>
>
> It is messy I know. Not hopeless though. Why can't std::wprint fallback to
> std::wcout on linux systems? It wouldn't be not compliant. If you think I
> am trying to replicate std::print because I think Windows UTF16 support is
> better, then this is wrong. I want an interface that supports wide string
> formatting with a print function. I don't care if it converts my string to
> UTF8 and prints that even. As long as I can write
> `std::[w]print[ln](L"Hi");` I am fine with it.
>
>
>
> On Sun, 30 Mar 2025, 12:52 Tiago Freire, <tmiguelf_at_[hidden]> wrote:
>
> They do. And I would strongly argue that they shouldn’t.
>
> What is the encoding of std::wformat_string again?.... What should it even
> output?
>
> Not everything in the standard are roses, this is one of the parts that is
> extremely messy.
>
>
>
> I understand that at a distance it looks good, it sounds like a good idea,
> I’ve tried to do something consistent in this field too, but I went mad
> trying to clean this mess. I came to the conclusion that the best solution
> is not to.
>
> The best solution is to throw it all way and just start from scratch. It’s
> hopeless.
>
>
>
>
>
> *From:* Tymi <tymi.cpp_at_[hidden]>
> *Sent:* Sunday, March 30, 2025 12:45 PM
> *To:* Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden]
> *Subject:* Re: [std-proposals] std::wprint/std::wprintln
>
>
>
> 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.
>
>
>
>
guess...
Also really, why can't it just fallback to converting to UTF8 on
unsupported systems??
On Sun, 30 Mar 2025, 13:11 Tiago Freire, <tmiguelf_at_[hidden]> wrote:
> Then that’s very easy, we can make “std::wprint[ln](L"Hi");” a no-op, i.e.
> it does nothing.
>
> Perfectly consistent behavior.
>
>
>
> But I doubt that is what you want.
>
> You want it to do something, you want it to do a very specific thing, you
> want it to print out a message, and if you do that you expect to be able to
> read said message. And now we are back to questions related to “what is the
> encoding” and “how will you make it work and in what circumstances does it
> work”. You may be fine with “I don’t care, just do something” (to which I
> would argue, doing nothing is a something). But I’m not!
>
>
>
> You are free to pursuit this but be aware that these questions will come
> back to you.
>
>
>
> I have tried to go down this road, didn’t even made it to a proposal.
> There’s nothing that stops you right now from trying to implement these
> features as a library, putting this in the standard will not magically make
> the operating system have an interface that it doesn’t currently support,
> it has to be a library feature, so you can start writing it today.
>
> So, you should try it as an exercise, make a portable library. That’s how
> I started, that’s how I stopped.
>
>
>
> *From:* Tymi <tymi.cpp_at_[hidden]>
> *Sent:* Sunday, March 30, 2025 12:55 PM
> *To:* Tiago Freire <tmiguelf_at_[hidden]>
> *Subject:* Re: [std-proposals] std::wprint/std::wprintln
>
>
>
> It is messy I know. Not hopeless though. Why can't std::wprint fallback to
> std::wcout on linux systems? It wouldn't be not compliant. If you think I
> am trying to replicate std::print because I think Windows UTF16 support is
> better, then this is wrong. I want an interface that supports wide string
> formatting with a print function. I don't care if it converts my string to
> UTF8 and prints that even. As long as I can write
> `std::[w]print[ln](L"Hi");` I am fine with it.
>
>
>
> On Sun, 30 Mar 2025, 12:52 Tiago Freire, <tmiguelf_at_[hidden]> wrote:
>
> They do. And I would strongly argue that they shouldn’t.
>
> What is the encoding of std::wformat_string again?.... What should it even
> output?
>
> Not everything in the standard are roses, this is one of the parts that is
> extremely messy.
>
>
>
> I understand that at a distance it looks good, it sounds like a good idea,
> I’ve tried to do something consistent in this field too, but I went mad
> trying to clean this mess. I came to the conclusion that the best solution
> is not to.
>
> The best solution is to throw it all way and just start from scratch. It’s
> hopeless.
>
>
>
>
>
> *From:* Tymi <tymi.cpp_at_[hidden]>
> *Sent:* Sunday, March 30, 2025 12:45 PM
> *To:* Tiago Freire <tmiguelf_at_[hidden]>; std-proposals_at_[hidden]
> *Subject:* Re: [std-proposals] std::wprint/std::wprintln
>
>
>
> 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.
>
>
>
>
Received on 2025-03-30 11:13:57