Shouldn't get_<type> for number be more flexible?

[lvella]

Strictly speaking, JSON has only one numerical type, probably best represented in C++ by double, but numbers inputted without decimal point are regarded as integers by the parser, and as unsigned if an integer is positive. I think it a nice feature, because those are the types supported by C, but it may complicate the handling of numbers.

The creator of the JSON data has no obvious reason to write 1.0 instead of 1, even if she knows the value is semantically a real number, after all, JSON standard makes no distinction between numbers, and every integer is also a real. So, to write a portable application parsing such data, the programmer must account that what he expects as a real might come as double, signed or unsigned, and what he expects as integer might come either as signed or unsigned. So, I suggest that:

• Create 2 new types, REAL and INTEGER, and their respective get_<type> and is_<type>;
• get<type::REAL>() and get_real() returns the value cast as double if it is either DOUBLE, SIGNED or UNSIGNED, and only throw exception for non-numbers;
• get<type::INTEGER> and get_integer() returns the value cast as int64_t if it is either SIGNED or UNSIGNED. I am not sure if it is worth to consider DOUBLEs that are exactly a whole number, or too close to one.

[d-frey]

You are looking at the wrong interface. The j.get<T>()-method is just a pure forwarder to the j.get_*()-methods. The more appropriate interface is j.as<T>() and j.extract(v). The latter two are using the traits to convert between the internal representation and the external type.

Have a look at https://github.com/taocpp/json/blob/master/include/tao/json/traits.hpp at line 60, there's a helper function unchecked_extract_number. It is used in the following traits. You can override this behavior by using your own traits class and catching narrowing conversions, etc. (sometimes at a run-time cost). This provides the flexibility to adjust to your use-case as you described it above.

I know that we still lack documentation, we are currently focusing on finishing the PEGTL 2.0.0 release. After that, we plan to give taocpp/json a lot more attention, including documentation. I hope the above is enough to get you started, if you need more help feel free to re-open the issue or simply write an email to taocpp@icemx.net.