On Fri, 18 Sep 2020 at 09:40, Eduardo Quintana via Boost < boost@lists.boost.org> wrote:
// i want speed boost::json::parser< int > p_int;
// i want accuracy boost::json::parser< boost::multiprecision::cpp_int > p_infinity;
By this example, can we assume you only care about this flexibility at parsing level and not necessarily in the DOM-like object (json::value)?
That what just for illustration purposes. I see that there are several objects involved.
My point is: the concept of JSON is independent of the underlying types used for representing strings and numbers. That's, in my opinion, a strong suggestion for using templates, and a solution to the "precision vs speed" conundrum.
Of course a json::parser<T>, has to produce a json::value<T> and yet json::value<T> can exists independently of a json::parser<T> or json::serializer<T>. Is up to the developers to choose how the abstraction is implemented.
Anyways that was just a comment and a suggestion. If I was writting a json library I would have used templates.
Vinnie might have covered this already but here's my 2c. JSON is in the main used as a language and platform agnostic data interchange format. The *de-facto* reality is that every other platform and language implementation that I can think of limits real numbers to doubles and integers to the range +-2^63, so it seems to me that going beyond that will achieve little in terms of general utility. This is the situation today. I understand the argument that this library could be an opportunity to push the boundaries and lead other languages to better practice. On the other hand, this is not the stated intent of the library - it's intent (in summary) is to meet the needs of the majority of C++ programmers who wish to interoperate with the world wide web today. Along with others here I am sure, I have significant experience in dealing with financial and cryptocurrency data interchange using JSON. The *reality* is that one learns *not to rely on the various interpretations of number values at all*. If you're sending an important value (such as a price) you very quickly learn to encode it as a JSON string representing the exact value and precision you want. In reality, JSON would be a perfectly useful data format if it did not have numeric, boolean or null types at all. For this reason, it seems to me that arguing over the precision of the API representation of these types is not likely to lead to increased utility in practice. Although I appreciate that some niche use cases would appreciate the ability, it is my impression that these will be rare and in any case can be worked around with strings. R
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212