property_tree write_json should output correct types in JSON

[Egbert van der Wal <ewal@…>]

When using boost::property_tree::write_json it will write all types as strings, which is unwanted when wanting to preserve the correct types for data.

• The boolean value is stored as the string "true" or "false",
• Null is stored as the string "null"
• Numeric values are also stored as strings
• Floating point values might end up in their scientific, lossy representations

For my purposes, I need to transfer numeric values (unix timestamps represented as double) in their most accurate representation using JSON and boolean values to represent correct boolean values without writing another text-to-bool converter.

I will attach a patch that fixes this. For every value in the property_tree, it will

• try to match is with boolean true or false, and write that value unquoted to the JSON output
• try to read it as an integer and if that succeeds, write it unquoted to the JSON output
• try to read it as a double value and if that succeeds, write it unquoted with appropriate numeric precision (based on std::numeric_limits) to the JSON output
• try to see if the string matches 'null' and if it does, it will write null unquoted to the JSON output
• if all else fails, write the value as a quoted string to the JSON output

This will make it a lot easier to interpret the JSON on the receiving and, and greatly improve accuracy for double values.

[Egbert van der Wal <ewal@…>]

Patch on SVN Trunk to improve the JSON output of the boost::property_tree::write_json function

[anonymous]

Any idea if/when this will be merged for a new release of Boost?

[Sebastian Redl]

I'm not going to include this.

With or without this patch the behavior is not right: without it, everything becomes a string when reading, and is written as such. With it, everything still turns into a string on reading, but now some strings suddenly become not-strings when writing.

In other words, this makes the writer harder to understand, and possibly incorrect - what if I actually want to write "2.0" to the JSON file? Maybe the JSON represents a music collection which contains the album by Garbage of that name.

I do hope to eventually support a ptree that uses a variant value type to accurately represent JSON, but until then I will stick with pure strings as the simple and obvious thing. If that is insufficient for your needs, I'm afraid you'll have to use a real JSON library.

[Egbert van der Wal <ewal@…>]

While your response definitely shows a flaw in my patch, this does not invalidate the ticket, does it? It still remains an unwanted generalization of everything to string in using Boost's property_tree.

Of course there are alternative libraries that will output JSON. My choice for using Boost property_tree is mainly based on my quest to minimize dependencies. Since my code already depends on Boost anyway, it's quite convenient to use as much from Boost as possible.

A patch that actually remembers the type of data that was stored in the property_tree would have a chance to be accepted?

[Sebastian Redl]

Yes, it would be, now that I have time to work on PTree again. But I've only started going through the bug list, so keep ​https://svn.boost.org/trac/boost/ticket/4786 in mind before you start working on this; I'm not sure, but it might contain patches to that effect.

[Sebastian Redl]

Actually, if you do anything, please add it to ​https://svn.boost.org/trac/boost/ticket/6351, which is exactly about that.