Date: Wed, 23 Oct 2024 20:25:20 +0200
fyi I won't be attending tonight. I need to take care of my mental health.
please let me know if p3258 is something you are interested in pursuing or
if I should not bother.
cheers
On Wed, Oct 23, 2024, 17:10 Victor Zverovich via SG16 <sg16_at_[hidden]>
wrote:
> Fully agree with Tom.
>
> - Victor
>
> On Wed, Oct 23, 2024 at 8:03 AM Tom Honermann via SG16 <
> sg16_at_[hidden]> wrote:
>
>> Concerns about std::mbstate_t fall under our purview. I expect LEWG to
>> look to us for a recommendation of how to handle features that concern it.
>>
>> Tom.
>>
>> On 10/23/24 2:11 AM, Jens Maurer via SG16 wrote:
>> > 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
>> >>
>> >>
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
please let me know if p3258 is something you are interested in pursuing or
if I should not bother.
cheers
On Wed, Oct 23, 2024, 17:10 Victor Zverovich via SG16 <sg16_at_[hidden]>
wrote:
> Fully agree with Tom.
>
> - Victor
>
> On Wed, Oct 23, 2024 at 8:03 AM Tom Honermann via SG16 <
> sg16_at_[hidden]> wrote:
>
>> Concerns about std::mbstate_t fall under our purview. I expect LEWG to
>> look to us for a recommendation of how to handle features that concern it.
>>
>> Tom.
>>
>> On 10/23/24 2:11 AM, Jens Maurer via SG16 wrote:
>> > 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
>> >>
>> >>
>> --
>> SG16 mailing list
>> SG16_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>>
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
>
Received on 2024-10-23 18:25:35