How strong is PropertyTree JSON support
Hello, I have a requirement to support parsing JSON, and while I could potentially pull together a Spirit Qi (or even X3, possibly) based grammar, I wonder with all the idiosyncrasies, i.e. particularly strings, escape sequences, Unicode, etc, is it worth it. Then there's the Boost.PropertyTree JSON support, which I think may be an adequate fit. However, just how robust is this support when it comes to handling some of the nuanced corner cases? The harder ones I think are the potential for escape sequences, Unicode, etc, embedded within a String. i.e. https://json.org/ or, http://es5.github.io/x7.html It seems with Property Tree there are also these limitations: <docs> The property tree dataset is not typed, and does not support arrays as such. Thus, the following JSON / property tree mapping is used: * JSON objects are mapped to nodes. Each property is a child node. * JSON arrays are mapped to nodes. Each element is a child node with an empty name. If a node has both named and unnamed child nodes, it cannot be mapped to a JSON representation. * JSON values are mapped to nodes containing the value. However, all type information is lost; numbers, as well as the literals "null", "true" and "false" are simply mapped to their string form. * Property tree nodes containing both child nodes and data cannot be mapped. </docs> It seems to me that much of the limitation is in adapting the PropertyTree to the JSON structure, but mostly vice versa. Not quite fitting a square peg in a round hole, but coming quite close, I think: "If a node has both named and unnamed child nodes, it cannot be mapped to a JSON representation." We're talking about the mapping from PropertyTree to JSON here? Seems like a potentially problematic issue depending on desired usage, 'all type information is lost; numbers, as well as the literals "null", "true" and "false" are simply mapped to their string form'. I'm not sure what "nodes containing both child nodes and data" means? https://www.boost.org/doc/libs/1_69_0/doc/html/property_tree/parsers.html#pr... Besides these concerns, I should think a grammar is fairly straightforward to construct, if push came to shove. It's either living with the Boost.PropertyTree or rolling my own AST, which is not outside the realm of possibility for my purposes. Thoughts? Suggestions? Thanks! Michael Powell
You might want to take a look at https://github.com/nlohmann/json ________________________________ From: Boost-users <boost-users-bounces@lists.boost.org> on behalf of Michael Powell via Boost-users <boost-users@lists.boost.org> Sent: Tuesday, January 8, 2019 6:50:52 PM To: boost-users@lists.boost.org Cc: Michael Powell Subject: [Boost-users] How strong is PropertyTree JSON support Hello, I have a requirement to support parsing JSON, and while I could potentially pull together a Spirit Qi (or even X3, possibly) based grammar, I wonder with all the idiosyncrasies, i.e. particularly strings, escape sequences, Unicode, etc, is it worth it. Then there's the Boost.PropertyTree JSON support, which I think may be an adequate fit. However, just how robust is this support when it comes to handling some of the nuanced corner cases? The harder ones I think are the potential for escape sequences, Unicode, etc, embedded within a String. i.e. https://json.org/ or, http://es5.github.io/x7.html It seems with Property Tree there are also these limitations: <docs> The property tree dataset is not typed, and does not support arrays as such. Thus, the following JSON / property tree mapping is used: * JSON objects are mapped to nodes. Each property is a child node. * JSON arrays are mapped to nodes. Each element is a child node with an empty name. If a node has both named and unnamed child nodes, it cannot be mapped to a JSON representation. * JSON values are mapped to nodes containing the value. However, all type information is lost; numbers, as well as the literals "null", "true" and "false" are simply mapped to their string form. * Property tree nodes containing both child nodes and data cannot be mapped. </docs> It seems to me that much of the limitation is in adapting the PropertyTree to the JSON structure, but mostly vice versa. Not quite fitting a square peg in a round hole, but coming quite close, I think: "If a node has both named and unnamed child nodes, it cannot be mapped to a JSON representation." We're talking about the mapping from PropertyTree to JSON here? Seems like a potentially problematic issue depending on desired usage, 'all type information is lost; numbers, as well as the literals "null", "true" and "false" are simply mapped to their string form'. I'm not sure what "nodes containing both child nodes and data" means? https://www.boost.org/doc/libs/1_69_0/doc/html/property_tree/parsers.html#pr... Besides these concerns, I should think a grammar is fairly straightforward to construct, if push came to shove. It's either living with the Boost.PropertyTree or rolling my own AST, which is not outside the realm of possibility for my purposes. Thoughts? Suggestions? Thanks! Michael Powell _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
You might also want to look at https://github.com/Tencent/rapidjson It's a little hard to use (restrictions put in to make it run crazy fast) but it's almost impossible to use INCORRECTLY because the compiler won't let you make most mistakes (violations of the restrictions) you would make. From: Boost-users <boost-users-bounces@lists.boost.org> On Behalf Of Stian Zeljko Vrba via Boost-users Sent: Tuesday, January 08, 2019 11:15 AM To: boost-users@lists.boost.org Cc: Stian Zeljko Vrba <vrba@quine.no> Subject: [EXTERNAL] Re: [Boost-users] How strong is PropertyTree JSON support You might want to take a look at https://github.com/nlohmann/json ________________________________ From: Boost-users <boost-users-bounces@lists.boost.org<mailto:boost-users-bounces@lists.boost.org>> on behalf of Michael Powell via Boost-users <boost-users@lists.boost.org<mailto:boost-users@lists.boost.org>> Sent: Tuesday, January 8, 2019 6:50:52 PM To: boost-users@lists.boost.org<mailto:boost-users@lists.boost.org> Cc: Michael Powell Subject: [Boost-users] How strong is PropertyTree JSON support Hello, I have a requirement to support parsing JSON, and while I could potentially pull together a Spirit Qi (or even X3, possibly) based grammar, I wonder with all the idiosyncrasies, i.e. particularly strings, escape sequences, Unicode, etc, is it worth it. Then there's the Boost.PropertyTree JSON support, which I think may be an adequate fit. However, just how robust is this support when it comes to handling some of the nuanced corner cases? The harder ones I think are the potential for escape sequences, Unicode, etc, embedded within a String. i.e. https://json.org/ or, http://es5.github.io/x7.html It seems with Property Tree there are also these limitations: <docs> The property tree dataset is not typed, and does not support arrays as such. Thus, the following JSON / property tree mapping is used: * JSON objects are mapped to nodes. Each property is a child node. * JSON arrays are mapped to nodes. Each element is a child node with an empty name. If a node has both named and unnamed child nodes, it cannot be mapped to a JSON representation. * JSON values are mapped to nodes containing the value. However, all type information is lost; numbers, as well as the literals "null", "true" and "false" are simply mapped to their string form. * Property tree nodes containing both child nodes and data cannot be mapped. </docs> It seems to me that much of the limitation is in adapting the PropertyTree to the JSON structure, but mostly vice versa. Not quite fitting a square peg in a round hole, but coming quite close, I think: "If a node has both named and unnamed child nodes, it cannot be mapped to a JSON representation." We're talking about the mapping from PropertyTree to JSON here? Seems like a potentially problematic issue depending on desired usage, 'all type information is lost; numbers, as well as the literals "null", "true" and "false" are simply mapped to their string form'. I'm not sure what "nodes containing both child nodes and data" means? https://www.boost.org/doc/libs/1_69_0/doc/html/property_tree/parsers.html#pr... Besides these concerns, I should think a grammar is fairly straightforward to construct, if push came to shove. It's either living with the Boost.PropertyTree or rolling my own AST, which is not outside the realm of possibility for my purposes. Thoughts? Suggestions? Thanks! Michael Powell _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto:Boost-users@lists.boost.org> https://lists.boost.org/mailman/listinfo.cgi/boost-users
On Wed, 9 Jan 2019 at 01:15, Stian Zeljko Vrba via Boost-users < boost-users@lists.boost.org> wrote:
You might want to take a look at https://github.com/nlohmann/json
I concur. After looking for a full implementation with a strong and useful interface I settled on this one. The provision of _json and _json_pointer literals is a very nice touch. Also the ability to create JSON objects using initialiser lists allows the programmer to be almost as expressive as when writing javascript.
------------------------------ *From:* Boost-users <boost-users-bounces@lists.boost.org> on behalf of Michael Powell via Boost-users <boost-users@lists.boost.org> *Sent:* Tuesday, January 8, 2019 6:50:52 PM *To:* boost-users@lists.boost.org *Cc:* Michael Powell *Subject:* [Boost-users] How strong is PropertyTree JSON support
Hello,
I have a requirement to support parsing JSON, and while I could potentially pull together a Spirit Qi (or even X3, possibly) based grammar, I wonder with all the idiosyncrasies, i.e. particularly strings, escape sequences, Unicode, etc, is it worth it.
Then there's the Boost.PropertyTree JSON support, which I think may be an adequate fit. However, just how robust is this support when it comes to handling some of the nuanced corner cases? The harder ones I think are the potential for escape sequences, Unicode, etc, embedded within a String.
i.e. https://json.org/ or, http://es5.github.io/x7.html
It seems with Property Tree there are also these limitations:
<docs> The property tree dataset is not typed, and does not support arrays as such. Thus, the following JSON / property tree mapping is used:
* JSON objects are mapped to nodes. Each property is a child node. * JSON arrays are mapped to nodes. Each element is a child node with an empty name. If a node has both named and unnamed child nodes, it cannot be mapped to a JSON representation. * JSON values are mapped to nodes containing the value. However, all type information is lost; numbers, as well as the literals "null", "true" and "false" are simply mapped to their string form. * Property tree nodes containing both child nodes and data cannot be mapped. </docs>
It seems to me that much of the limitation is in adapting the PropertyTree to the JSON structure, but mostly vice versa. Not quite fitting a square peg in a round hole, but coming quite close, I think:
"If a node has both named and unnamed child nodes, it cannot be mapped to a JSON representation." We're talking about the mapping from PropertyTree to JSON here?
Seems like a potentially problematic issue depending on desired usage, 'all type information is lost; numbers, as well as the literals "null", "true" and "false" are simply mapped to their string form'.
I'm not sure what "nodes containing both child nodes and data" means?
https://www.boost.org/doc/libs/1_69_0/doc/html/property_tree/parsers.html#pr...
Besides these concerns, I should think a grammar is fairly straightforward to construct, if push came to shove. It's either living with the Boost.PropertyTree or rolling my own AST, which is not outside the realm of possibility for my purposes.
Thoughts? Suggestions?
Thanks!
Michael Powell _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212 (this will be *expensive* outside Andorra!) skype: madmongo facebook: hodges.r
participants (4)
-
Dalbey, Keith -
Michael Powell -
Richard Hodges -
Stian Zeljko Vrba