Accessing parsed numbers

[boostorg]

Accessing parsed numbers

[vinniefalco]

Yes I agree that we need something, I am just not sure on what it should be or what we should call it. Although I think a separate number class might not be great (I had it that way originally but it was clumsy). How about this

auto jv = parse( "42 ");
std::cout << number_cast<short>(jv);

?

[vinniefalco]

Give this a whirl? https://github.com/vinniefalco/json/pull/19

[PkmX]

LGTM functionality-wise, though I'd prefer it to be a member function and it should also mirror the accessor functions of other value kinds:

const auto jv = json::parse("42");
jv.is_number<T>(); // check if the number fits into T
jv.as_number<T>(); // checked conversion to T
jv.get_number<T>(); // unchecked conversion to T
jv.if_number<T>(); // pointer access

Then we can get rid of the *_int64, *_uint64 and *_double functions or simply make them simply to *_number functions.

[vinniefalco]

I'd prefer it to be a member function

Hmm...I see some problems with this interface. First of all in generic contexts you would have to write jv.template is_number<T>() which isn't pretty. But the bigger problem is that these functions have different semantics but the same names as other functions (e.g. is_object).

For example this cannot be implemented:

jv.if_number<short>()

Because a json::value doesn't store a short internally, only a std::int64_t.

value::get_number<T> has different semantics from value::get_object. The first one performs a conversion while the second one returns a reference.

numeric_cast is more readily understood by users since it uses the same interface as static_cast and duration_cast.

Finally, the implementation of numeric_cast uses only public members of json::value, making it an ideal candidate for treatment as a free function.

This is why I went with numeric_cast.