You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One advantage is that the lexer could handle arbitrarily long ints and floats. The parser would later flag an error when data do not fit the datatypes. (Technically, very few Json parsers satisfy the JSON standard, which does not limit numerics.)
Also, lazy parsing becomes possible, which in some scenarios leads to much quicker sparse access than with most Json parsers available today.
It is also possible to stream the lexer to the parser.
Json parser, templated on <Int, Float, String> and maybe also list and dict types.
If list/dict are also template arguments, then STL allocators are automatically included.
An API for providing converters between array-of-char and those template-arg types
Several lexers, specializations, and converters could be provided. There could be obvious defaults, so convenience should not be the issue.
(For the record, I maintain JsonCpp, which is not even close to what I would want in standard C++.)
The text was updated successfully, but these errors were encountered:
In my opinion, there should be several pieces:
<Int, Float, String>
and maybe also list and dict types.Several lexers, specializations, and converters could be provided. There could be obvious defaults, so convenience should not be the issue.
(For the record, I maintain JsonCpp, which is not even close to what I would want in standard C++.)
The text was updated successfully, but these errors were encountered: