Date: Thu, 1 May 2025 07:23:59 +0000
Not that I support the approach of passing a single integer representing the digits.
But if you wanted to do that you can just provide an offset number of where those digits are in relation to the decimal separator.
-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Magnus Fromreide via Std-Proposals
Sent: Thursday, May 1, 2025 8:42 AM
To: Jonathan Wakely via Std-Proposals <std-proposals_at_lists.isocpp.org>
Cc: Magnus Fromreide <magfr_at_[hidden]>
Subject: Re: [std-proposals] Low-level float parsing functions
On Wed, Apr 30, 2025 at 09:33:36AM +0100, Jonathan Wakely via Std-Proposals wrote:
> On Wed, 30 Apr 2025, 05:16 Jan Schultke via Std-Proposals, <
> std-proposals_at_lists.isocpp.org> 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.
I might just be stupid here but how do you plan to handle leading zeroes in the fractional part of your all integers interface?
/MF
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
But if you wanted to do that you can just provide an offset number of where those digits are in relation to the decimal separator.
-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Magnus Fromreide via Std-Proposals
Sent: Thursday, May 1, 2025 8:42 AM
To: Jonathan Wakely via Std-Proposals <std-proposals_at_lists.isocpp.org>
Cc: Magnus Fromreide <magfr_at_[hidden]>
Subject: Re: [std-proposals] Low-level float parsing functions
On Wed, Apr 30, 2025 at 09:33:36AM +0100, Jonathan Wakely via Std-Proposals wrote:
> On Wed, 30 Apr 2025, 05:16 Jan Schultke via Std-Proposals, <
> std-proposals_at_lists.isocpp.org> 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.
I might just be stupid here but how do you plan to handle leading zeroes in the fractional part of your all integers interface?
/MF
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-05-01 07:24:02