On Wed, 30 Apr 2025 at 09:41, Sebastian Wittmeier via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> parse_float("1.3e2", "1");
>
> would probably be a hexadecimal number 0x13E2 with '.' as thousand separator?

The proposed API I was talking about is the one in:
https://lists.isocpp.org/std-proposals/2025/04/13522.php
A string containing '.' and 'e' is not valid for the integer part.

You seem to be talking about some other hypothetical API that I can't
comment on because I have no idea what it's supposed to do.

Anyway, it seems to me that the design space is quite large, and so
not ready for standardization. Maybe it belongs in the fast_float
library, because if the proposed API really is already a required
low-level piece of that library, then it wouldn't be a problem to
factor it out and expose it as a public interface.


>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Jonathan Wakely via Std-Proposals <std-proposals_at_[hidden]>
> Gesendet: Mi 30.04.2025 10:34
> Betreff: Re: [std-proposals] Low-level float parsing functions
> An: C++ Proposals <std-proposals_at_[hidden]>;
> CC: Jonathan Wakely <cxx_at_[hidden]>;
>
>
> 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.
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals