Date: Wed, 23 Oct 2024 14:50:44 +0800 (GMT+08:00)
Hi Jens,
I admit that it's my carelessness to forget that explicit conversion operator is in C++11; thanks for that.
Initially I think it's proper to be discussed in SG16 since P1253 mentions that formatting-related paper should be forwarded to SG16 for review. So if it's considered only suitable for LEWG, it's Okay for me to not present this paper in the meeting :).
Liang Jiaming
From: Jens Maurer <jens.maurer_at_[hidden]>
Date: 2024-10-23 14:11:29
To: sg16_at_[hidden]
Cc: "梁家铭" <liangjiaming_at_[hidden]>,tom <tom_at_[hidden]>
Subject: Re: [isocpp-sg16] Agenda for the 2024-10-23 SG16 meeting>
>I think it is off-topic for SG16 to discuss this proposal at all.
>There are no encoding concerns beyond those already answered for
>std::format, and what the components of a std::fpos<T> are and
>which sequence of characters is used to represent it and whether
>you can (hypothetically) parse the representation to recover a
>std::fpos<T> are all good questions --- that belong to LEWG, not SG16.
>
>And a data point: The convertibility requirement for std::fpos to
>std::streamoff (C++98) predates the introduction of explicit conversion
>operations (C++11), thus the only way to reasonably satisfy the explicit
>conversion requirement was for implementations to provide an implicit
>conversion.
>
>Jens
>
>
>On 23/10/2024 02.06, 梁家铭 via SG16 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`.
>>
>> 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 admit that it's my carelessness to forget that explicit conversion operator is in C++11; thanks for that.
Initially I think it's proper to be discussed in SG16 since P1253 mentions that formatting-related paper should be forwarded to SG16 for review. So if it's considered only suitable for LEWG, it's Okay for me to not present this paper in the meeting :).
Liang Jiaming
From: Jens Maurer <jens.maurer_at_[hidden]>
Date: 2024-10-23 14:11:29
To: sg16_at_[hidden]
Cc: "梁家铭" <liangjiaming_at_[hidden]>,tom <tom_at_[hidden]>
Subject: Re: [isocpp-sg16] Agenda for the 2024-10-23 SG16 meeting>
>I think it is off-topic for SG16 to discuss this proposal at all.
>There are no encoding concerns beyond those already answered for
>std::format, and what the components of a std::fpos<T> are and
>which sequence of characters is used to represent it and whether
>you can (hypothetically) parse the representation to recover a
>std::fpos<T> are all good questions --- that belong to LEWG, not SG16.
>
>And a data point: The convertibility requirement for std::fpos to
>std::streamoff (C++98) predates the introduction of explicit conversion
>operations (C++11), thus the only way to reasonably satisfy the explicit
>conversion requirement was for implementations to provide an implicit
>conversion.
>
>Jens
>
>
>On 23/10/2024 02.06, 梁家铭 via SG16 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`.
>>
>> 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 06:50:53