According to bug #12149, the non-pretty version of write_json should not
print the trailing endl. This patch only prints the endl in the pretty
case, and only does the flush component of the endl in the non-pretty
version.
Signed-off-by: Erich Keane <erich.keane@intel.com>
This project's CMakeLists.txt must exist in the boost ecosystem. In
order to avoid ambiguity of target names across boost libraries, targets
in this project are prefixed with boost_property_tree-
The build files in this directory are neither maintained nor tested. They
are already outdated (VS 2008 projects) and will only get more so. I have
no intention of maintaining them.
The new file contains lots of small unit tests for the new JSON parser, far more extensive than the old one.
Keep the old file too, though, because it contains writing and round-trip tests.
TL;DR: The new parser fixes long-standing bugs and has full Unicode support, but removes non-standard extensions
of the old parser, which could break code:
- String concatenation: the old parser concatenated adjacent string literals like C does.
- Comments: the old parser supported C and C++-style comments. JSON doesn't allow comments.
The JSON writer hasn't been changed; it still has all the Unicode-related problems.
The old JSON parser had quite a few problems:
- Slow to compile.
- Based on the obsolete Spirit.Classic.
- Inherited a multithreading bug from Spirit.Classic (see bug #5520).
- Poor to no support for Unicode.
- Weird departures from standard JSON.
- Tightly bound to string-based property trees.
The new parser has the following features:
- Hand-written recursive descent parser - few template instantiations, fast to compile.
- Parses through a pair of iterators with support for input iterators - can parse directly from streambuf_iterators.
Doesn't need to load the entire file into memory first.
- Push-based stream model.
- Full support for Unicode. Assumes that char is UTF-8. If wchar_t is 16 bits, assumes UTF-16, with support for surrogate pairs.
- Pluggable encoding support. The public interface doesn't expose this yet. Currently, narrow input streams are assumed to use
UTF-8 both internally and externally, and wide streams are assumed to use UTF-16 or UTF-32, depending on the bit width of wchar_t.
Malformed encodings are not accepted.
The pluggable support allows inserting other external encodings, or making narrow streams parse into wide internal trees, etc.
- Replaceable event handlers. Also not exposed by the public interface, the replaceable event handlers allow parsing into non-string
property trees and preserving type information of the JSON.
