Date: Wed, 30 Apr 2025 09:52:41 +0100
On Wed, 30 Apr 2025 at 09:33, Jonathan Wakely <cxx_at_[hidden]> wrote:
>
>
>
> On Wed, 30 Apr 2025, 05:16 Jan Schultke via Std-Proposals, <std-proposals_at_[hidden]> wrote:
>>
>> > Which begs the question: if you need this type of configurability, why don't
>> > you just use libdouble-conversion?
>>
>> It would be pretty ridiculous if you pulled in a third-party
>> dependency just because you have a comma as a radix point instead of
>> a dot.
>>
>> Also, keep in mind that this is about extending the standard library.
>> The standard library should provide the low-level, hard-to-implement
>> parts so that libraries such as double-conversion can be built on top
>> of it.
>>
>> The class you've referenced provides a large amount of fluff that the
>> user can easily do themselves. It's trivial to detect if the string is
>> "NaN" or "inf" and treat that as a NaN or infinity float. It's trivial
>> to add flags in our parser for case sensitivity, it's trivial to
>> remove a leading "0x", etc. There are a million flags and options you
>> could add here.
>>
>> What's not trivial is turning digit sequences into a floating-point
>> number. That is the low-level part of the problem that needs to be
>> supported by the standard library.
>
>
>
> If you have already found the boundaries of the integer part and fractional part, represented as sequence of digits, isn't converting those digits to integers also easy for the user to do efficiently? Does that part belong in the lowest level interface?
>
> If your interface takes integers for all three arguments, then the user is doing the parsing steps that might need to handle digit separators.
>
> Taking strings also presents a problem for hex floats. What base is the string in?
>
> parse_float("1", "23");
>
> Is this 1.23e0 or 0x1.23p0?
>
> If the user has to convert "1" and "23" to integers then they can do so for the right base.
Oh sorry, my eyes apparently glazed over the separate parse_float_hex
for precisely this purpose.
Still it seems like we wouldn't need two functions if the user
pre-parsed those string_view arguments and obtained integers from
them.
>
>
>
> On Wed, 30 Apr 2025, 05:16 Jan Schultke via Std-Proposals, <std-proposals_at_[hidden]> wrote:
>>
>> > Which begs the question: if you need this type of configurability, why don't
>> > you just use libdouble-conversion?
>>
>> It would be pretty ridiculous if you pulled in a third-party
>> dependency just because you have a comma as a radix point instead of
>> a dot.
>>
>> Also, keep in mind that this is about extending the standard library.
>> The standard library should provide the low-level, hard-to-implement
>> parts so that libraries such as double-conversion can be built on top
>> of it.
>>
>> The class you've referenced provides a large amount of fluff that the
>> user can easily do themselves. It's trivial to detect if the string is
>> "NaN" or "inf" and treat that as a NaN or infinity float. It's trivial
>> to add flags in our parser for case sensitivity, it's trivial to
>> remove a leading "0x", etc. There are a million flags and options you
>> could add here.
>>
>> What's not trivial is turning digit sequences into a floating-point
>> number. That is the low-level part of the problem that needs to be
>> supported by the standard library.
>
>
>
> If you have already found the boundaries of the integer part and fractional part, represented as sequence of digits, isn't converting those digits to integers also easy for the user to do efficiently? Does that part belong in the lowest level interface?
>
> If your interface takes integers for all three arguments, then the user is doing the parsing steps that might need to handle digit separators.
>
> Taking strings also presents a problem for hex floats. What base is the string in?
>
> parse_float("1", "23");
>
> Is this 1.23e0 or 0x1.23p0?
>
> If the user has to convert "1" and "23" to integers then they can do so for the right base.
Oh sorry, my eyes apparently glazed over the separate parse_float_hex
for precisely this purpose.
Still it seems like we wouldn't need two functions if the user
pre-parsed those string_view arguments and obtained integers from
them.
Received on 2025-04-30 08:52:57