Conversion of string values to numeric and boolean

[ah-oh-uh]

Currently asInt, asDouble, asBool are able to convert numeric values between each other, but in cases when you have a numeric or a boolean value wrapped into a string they throw an exception.

It does look like as methods are in general conversion methods and not the real representation of an underlying value, so I'm wondering if there is any reason to not support conversion or values like "999.9" or "true".

It would have been super helpful and will reduce some duplicated extra code in the places where it is used.

If there is no some huge violation in something by adding it then I am even willing to code it and send as a pull request.

[fregloin]

Yes, it is bizarre, why not try to convert string to integer if the user asks it explicitly? Some JSON libs (in Java for example) encode integers as strings or real values only. I wasted some time to solve the issue, why my binary crashes on a valid JSON document until I looked into the sources.

[BillyDonahue]

I would argue that parsing string scalar values into numerics should not be JSON's job.

It does look like as methods are in general conversion methods and not the real representation of an underlying value, so I'm wondering if there is any reason to not support conversion or values like "999.9" or "true".

That's not quite right, I think. The asInt etc casts are there as conveniences to convert among numerics where the type differences are not so profound, and because JSON doesn't natively distinguish between integer and floating point, so it's common for a JSON "number" scalar to be shoehorned into a C++ type by the parsing app (see json.org grammar diagram).

If you want to parse the string value again as JSON using a JSON reader, you can do that, I guess?

If the app failure is hard to diagnose that's a problem though. You will get a std::runtime_exception containing an error report from jsoncpp when the asString fails. If you're handling exceptions you should see what the problem is pretty soon, I think.

[dmitryrechkin]

The are two main issues:

• Why do these methods do any kind of conversion?
• If we say that JSON can't distinguish between integer and floating point then why not only give access to the numeric value and let users do their own conversion as they need?
• How can the user possibly know what these methods can convert and can't, without looking at the library's source code?
  For example, if I see asDouble I have no way of knowing what it can convert.
• If we want to offer some convenience, then why not for string -> anything as well? Arguably it is just a few lines of extra code.

[BillyDonahue]

That's 4 issues?

If you think the methods should be deprecated I agree.

The existence of a few type-converting convenience functions doesn't mean that the full matrix of such functions should exist.

"If we say that JSON can't distinguish between integer and floating point then why not only give access to the numeric value and let users do their own conversion as they need?"

How do you suggest to "give access to the numeric value" in C++? We have the lower level accessors for type, and the non-converting getters for when the type is known.

As for what the user can possibly know, that's a documentation issue. Users shouldn't have to look at source code.
If it's underdocumented we should fix that gap.

stirng -> anything is more than a few lines of code. We are not offering convenience for its own sake here. These functions are, I believe, intended only to make an abstraction to handle the disconnect between JSON's and C++'s numeric types.