boostorg/spirit

x3::double_ failed to parse 1.D-3

xiaowen64 opened this issue · 5 comments

xiaowen64 commented

it is pretty common to have double precision floating point numbers to be written as something like 1.D-3. I believe many Fortran run-time libs does that. I traced it to x3/numeric/real_policies.hpp where a small change of below fixed it. should an option be provided to cope with this situation?

        template <typename Iterator>
        static bool
        parse_exp(Iterator& first, Iterator const& last)
        {
            if (first == last || (*first != 'e' && *first != 'E' && *first != 'd' && *first != 'D'))
                return false;
            ++first;
            return true;
        }
Kojoley commented

The function you are citing is customizable via RealPolicies.

xiaowen64 commented

yeah, I thought about that as a work-around. Given that this notation is pretty common, actually just found out it's stipulated by Fortran Standard, it'd be more convenient to support it (and the 'Q' notation) natively.

Kojoley commented

These D and Q are special in a way that they denote a type, it seems wrong to me to allow Q for x3::double_ or D for x3::float_. Anyway atof doesn't support them so I don't see a need to change the default behavior. Again, that's the situation RealPolicies are designed for.

xiaowen64 commented

You are right, 'D' for x3::float_ sounds odd. How about allowing 'D' for x3::double_? It sounds natural.

Kojoley commented

It sounds natural.

No, it's not. It's a Fortran language syntax thing, std::atof and Spirit parsers don't support C and C++ language syntax things like 1.0f, 1.0d, 1.0f64 and etc., why Fortran's should be? Why also not support Fortran's 1.345E-10_8?

  • 👍1