Date: Wed, 23 Oct 2024 15:20:45 +0800 (GMT+08:00)
Hi Corentin,
I know that the mbstate_t is deliberately left as a black box, but isn't it unsafe to neglect it at all in formatting? Otherwise if it's set to some state, then the mere integer is basically completely useless.
For adding a member function, I don't see its advantage over explicit conversion.
Liang Jiaming
From: Corentin Jabot <corentinjabot_at_[hidden]>
Date: 2024-10-23 14:14:05
To: "梁家铭" <liangjiaming_at_[hidden]>
Cc: sg16 <sg16_at_[hidden]>,tom <tom_at_[hidden]>
Title: Re: [isocpp-sg16] Agenda for the 2024-10-23 SG16 meeting
On Wed, Oct 23, 2024 at 2:06 AM 梁家铭 <liangjiaming_at_[hidden]> wrote:
Hi Corentin,
The first version of draft (D3374R0) is to format the `fpos` as an integer directly, which can be confirmed by Victor. The reason why I finally add the state type is that Tom reminds me that it's not proper to neglect such a basic component by default and I think that really makes sense. This also makes me reflect that it's possibly not robust for stream to only output the integer, and that's why `.offset` is not thought as the solution. There is no difference for me to cast explicitly or call `.offset`.
I'd like to push back against that.
There is currently no way to observe an mbstate. The only operation C defines on it is to query whether it is in the initial shift state. There is also nothing you can do with it as it is an implementation detail.
Whatever state it might have is non-portable, and not actionable.
That it technically exists does not mean that it should be observable. std::print should not expose things that cannot otherwise be queried. The black box nature of mbstate is very much intentional. It's certainly not deprecated, but it is not user-facing either.
I see two ways forward
- add a function that extracts the offset
- add a simple formatter that outputs the offset, and nothing else.
In today's talk, I'd like to share something about:
+ briefly cover what mbstate_t should do, as you may be already familiar with;
+ why C++ programmers generally think it's enough to use the integer, as a result of illusion from the implementations of streams that do text encoding;
+ we could provide such facility in the standard library for those programmers who concern the state, as long as we think mbstate_t is not a deprecated feature.
For the formatting specification, there could be some better representations if `(pos, mbstate)` is not considered as a good one or even not the default one, and I'd like to discuss with you :). I know that mbstate_t couldn't be expected to be formatted in any meaning way, but it's enough to make it recoverable by the implementation. For me doing a round-trip is possibly the most thing we could do in the standard.
Thanks for the feedback,
Liang Jiaming
I know that the mbstate_t is deliberately left as a black box, but isn't it unsafe to neglect it at all in formatting? Otherwise if it's set to some state, then the mere integer is basically completely useless.
For adding a member function, I don't see its advantage over explicit conversion.
Liang Jiaming
From: Corentin Jabot <corentinjabot_at_[hidden]>
Date: 2024-10-23 14:14:05
To: "梁家铭" <liangjiaming_at_[hidden]>
Cc: sg16 <sg16_at_[hidden]>,tom <tom_at_[hidden]>
Title: Re: [isocpp-sg16] Agenda for the 2024-10-23 SG16 meeting
On Wed, Oct 23, 2024 at 2:06 AM 梁家铭 <liangjiaming_at_[hidden]> wrote:
Hi Corentin,
The first version of draft (D3374R0) is to format the `fpos` as an integer directly, which can be confirmed by Victor. The reason why I finally add the state type is that Tom reminds me that it's not proper to neglect such a basic component by default and I think that really makes sense. This also makes me reflect that it's possibly not robust for stream to only output the integer, and that's why `.offset` is not thought as the solution. There is no difference for me to cast explicitly or call `.offset`.
I'd like to push back against that.
There is currently no way to observe an mbstate. The only operation C defines on it is to query whether it is in the initial shift state. There is also nothing you can do with it as it is an implementation detail.
Whatever state it might have is non-portable, and not actionable.
That it technically exists does not mean that it should be observable. std::print should not expose things that cannot otherwise be queried. The black box nature of mbstate is very much intentional. It's certainly not deprecated, but it is not user-facing either.
I see two ways forward
- add a function that extracts the offset
- add a simple formatter that outputs the offset, and nothing else.
In today's talk, I'd like to share something about:
+ briefly cover what mbstate_t should do, as you may be already familiar with;
+ why C++ programmers generally think it's enough to use the integer, as a result of illusion from the implementations of streams that do text encoding;
+ we could provide such facility in the standard library for those programmers who concern the state, as long as we think mbstate_t is not a deprecated feature.
For the formatting specification, there could be some better representations if `(pos, mbstate)` is not considered as a good one or even not the default one, and I'd like to discuss with you :). I know that mbstate_t couldn't be expected to be formatted in any meaning way, but it's enough to make it recoverable by the implementation. For me doing a round-trip is possibly the most thing we could do in the standard.
Thanks for the feedback,
Liang Jiaming
Received on 2024-10-23 07:20:53