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

[xiaowen64]

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]

The function you are citing is customizable via RealPolicies.

[xiaowen64]

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]

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]

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

[Kojoley]

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?