Skip to content

feature?: ignored characters `'_ / allowing prefixs 0x and 0b etc... #124

Open

Description

@Andersama

This isn't a performance related feature, but I've found it odd that the charconv spec goes out of its way to avoid parsing what would otherwise be necessary to handle c++'s own floating point literals. What would you think about having some additional utility from_chars like functions to handle those formats?

Ages ago I modified microsoft's charconv to do this for myself, but it broke at some point because headers changed and some utility functions went missing. The core idea is roughly this:

if (fmt is prefixed) {
  //bump pointer forward past the prefix for the format
}

//continue parsing like charconv would except skip over specified characters
uint64_t mantissa = 0;
for (;begin != end; ++begin) {
if ((*begin == some_template_pack) || ...)
  continue;
const unsigned char digit = char_table[*begin];
if (digit >= base)
  break;
//so on...
}

Not used your library, but it seems like hex formatted floats have the enum for the format but aren't supported? Could also be the opportunity to add that in.

Activity

  1. lemire commented on Jan 20, 2022

    @lemire
    Member

    @Andersama We want the from_chars function to abide by the standard as much as possible. It should be close to a "drop-in" replacement for whatever the standard library provides.

    However, we also have the from_chars_advanced function which is an extension. There is no limit to what we could do there.

    Support for other data types and formats is certainly welcome. Please consider providing a pull request, or many pull requests.

  2. Andersama commented on Feb 9, 2022

    @Andersama
    Author

    It looks like parse_number_string is the underlying function that from_char_advanced is using. Were you expecting the drop in to handle hex floats? Currently it seems like it doesn't, and it seems like I'm about to add a fairly large if / else block otherwise with an extra flag integer to parse_options. Pretty sure that'll be a bit of a performance hit.

  3. lemire commented on Feb 9, 2022

    @lemire
    Member

    We have decent benchmarks so we can assess performance issues. I would not necessarily be overly concerned at first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions