Thanks John for your nice lib and more so for the regular updates and support you give us.
Since JSON is a subset of YAML, could your lib be extended to support YAML 1.2 or maybe as a seperate lib? Would that be a big effort for you?
I would need YAML but I'm not proficient enough to code it in Spirit or ANTLR without help.
Just a simple question, is possible to change the output to xml format (to read and write in a valid xml format)? If yes then how this support the attributes and so on?
This library uses Classic Spirit for note. Spirit2.1 (currently in Boost Trunk and will be in Boost 1.41) is fully complete (they are just finishing documentation and building up a useful set of components). Spirit2.1 is a *great* deal faster then Classic Spirit.
I have already created a completely header file based json parser in Spirit2.1 (that I intend to add to the Spirit2.1 external components section) that vastly outperforms anything that can be created in Classic Spirit. Value in my version is just a Boost.Variant with all the normal Boost.Variant power (can directly pull out a value as with the article in this version, as well as able to to compile time visitation on it for absolute speed), and it takes a *lot* less memory use then the Value class in this article (why did the article writer not use boost::variant?). It uses boost::unordered_map for the map object (since the json standard specifies that it is an unordered map, seems the most logical to use since it is so efficient), int64 (based on the JSON standard), double (based on the JSON standard), etc... I tried to base everything on the JSON standard as much as possible. I am waiting to commit it until I write the karma version (Spirit.Karma in Spirit2.1 is the output version of the normal Spirit.QI input, so it will be able to output as well as input). You can expect it in Boost Trunk when I get around to finishing the karma part, or you can wait until Boost 1.41 when it is fully released. I have already released the parser part (not the karma part yet) on the Spirit mailing list a while back, but I am cleaning up the interface as well. It is also input agnostic, as long as the iterator is a back-tracking iterator it will store the characters in whatever format it is, so if you give it an std::string iterator, you get you a JSON Value using char's to store string, or if you use unicode, you will get whatever the embedded char type is, etc... and so forth. Only thing you do is set a macro to the encoding type you will use (ascii, wide, etc...) as-is supported by Spirit2.1 and it will use whatever you give it to parse, much more powerful. And, as stated, it is header-only, so no needing to include any cpp files in your project (and when it is added to the Spirit components then you will just include like any normal part of spirit anyway).
I am getting the switch statement warning. Version 4.01 appears to address this but when downloading the source using the link at the top of the page I get v4.00.
If warning flags are enabled in gcc (as they should be), compiling json_spirit produces a lot of warning messages (too many to list here), though it still compiles successfully. Some of the warning are simple (unhanded switch statements), while others are template related (hard to read/decipher). Compiler flags can be enabled by including a line such as
in your toplevel CMakeLists.txt file (after the CMAKE_MINIMUM_REQUIRED line for example). I think its fair to say that including -Wall and -ansi is generally good practice.
Although the library is working nicely for me so far and has the nicest interface of the C++ json libraries I've looked at, this number of warning makes me weary of using the library in my projects or at work.
When I downloaded and tried to compile, it said some boost header files were missing.
So I searched and download Boost Spirit from http://spirit.sourceforge.net/[^]. But the code structure is different. Also some files are missing such as shared_ptr.hpp etc.
When I try to compile the source (and the demo) with threading enabled [boost 1.39.0 / cmake 2.6 / CentOS 5 x86_64 / gcc 4.1.2], I get the following error message:
I have added "thread" to the json_spirit and json_demo's "CMakeFile.txt" => FIND_PACKAGE(Boost 1.37 REQUIRED thread)
I even tried to manually add pthread in the CMakeFiles.txt => TARGET_LINK_LIBRARIES(json_demo json_spirit pthread)
Of course I have uncommented the "//#define BOOST_SPIRIT_THREADSAFE // uncomment for multithreaded use, requires linking to boost.thead= " in json_spirit_reader.cpp.
This is a nice bit of code which would be quite useful for a variety of open source projects, thank you for making it available. I would like to use the code but our licensing attorney here at Red Hat says the The Code Project Open License (CPOL) is a bad open source license and he has added it to the prohibited list of licenses (https://fedoraproject.org/wiki/Licensing) after I asked him to review it.
The problem seems to be compounded by the fact there is no licensing information in the distributed sources other than the following comment block at the top of each file
/* Copyright (c) 2007-2009 John W Wilkinson
json spirit version 4.00
This source code can be used for any purpose as long as
this comment is retained. */
This is clearly not the same license as CPOL. Did you intend to license the code under CPOL or was that an unintentional artifact of posting on the Code Project web site?
So there are two problems:
1) There is a discrepancy between the license in the code and the license referenced on the project page, the two are quite different. The source distribution should have specific licensing information.
2) No one in Fedora can use your code under the current CPOL license
We have suggestions for you regarding the license which we believe would preserve your original licensing indent as evidenced by your license comment block.
I would have written to you privately to resolve these issues but for the life of me I couldn't figure out how to send an email directly to the project owner, so this seems the best alternative. We can either continue the discussion here so others can benefit or we can take it off line, I may be reached at jdennis at redhat.com
Once again, thank you for your open source contribution!
I updated and rebuilt with the new version of JSON, using solution and project files converted to VS2008 - and there were errors. The project for json_demo was missing an include directory path for ..\json_spirit. Add that and everything seems to compile just fine.
I'm using your excellent package to process JSON produced by a number of different sources. One of the sources, written in Ada, is taking a number like 3.0 and writing it into the JSON stream as 3. This is a valid <number>. As the consumer, using your package, I am expecting a real value, so I call get_real. This asserts. The <number> is parsed as an integer, so the type is int_type - not real_type.
This seems like a bug. A number with no decimal is ambiguous. It's certainly a valid real number. I think that the get_real method on Value_Impl should make a check. If the type is int_type, then it should cast the integer to a double and return the value.
In my project, we need to write unsigned long int and size_t data type values. Currently, "json_spirit" doesn't support these. Please help me. We need following data types to read & write:
1. i have written cmake files for json_spirit. They work fine on Mac OS X for command line builds and for Xcode builds . If you are interested i will send you a copy.
2. would it be possible to create an repository (for example on Sourceforge) for json_spirit? It will be much easier to include json_spirit in MacPorts, if an repository is available.
3. Do you know if the license is compatible with the GPL? If not, is it possible to re-license or double-license json_spirit?
In order to get v3.0 to compile in Linux (Fedora 10) I had to add the following line to json_spirit_writer_test.cpp, json_spirit_reader_test.cpp, and json_spirit_value_test.cpp in order for GCC 4.3.2 to find INT_MIN, INT_MAX, and LLONG_MAX:
#include <limits.h>
Also, since I'm here. Here is what I typed on the command line to build the projects:
Hi! First of all, I'd like to say thanks for this great lib.
However, I was surprised when I've found so many uses of assert functions included from standart <cassert>. IMHO closing program when parsing fails due to some input stream errors is not the best way of behaviour. If you find support of asserts usefull, why not to replace <cassert> with the one defined in boost.spirit library ( <boost/spirit/home/classic/core/assert.hpp> )? Then the user can control with #define what to use - boost::exception or standart assert function.
P.S.: English is not my native language, so sorry if there are any mistakes
Thanks for the library.
I have been playing with the code - its simple to use and understand.
However I was wondering why you chose to use a vector of pairs to model an Object.
A very common use case [for us] is to have the c++ code query the json structure for various objects/properties and the currrent impl is pretty cumbersome to use ( an iteration based find ) and slow compared to a std::map<string,value> backed object - this seems to be most common approach taken by other c++ json impls.
Can you please explain the reason for the choice and how you see the performance/usability impact?
Thanks for this great code just hoping for a bit of "idiot" support. I am fairly new to C++ and I am having trouble extracting the actual data from the JSON message.
Wouldn't it have been better to implement this as part of the boost serialization library (you would still use spirit for the parsing - as the xml serializer does).
The main beneifit is that you could serialize a c++ object to/from a javascript one (jolly useful from an activex point of view and from an embedded scripting language point of view).
Would you consider accepting the Object_impl I have added in the code below (or something similar)? I think it is a good compromise between complexity, functionality, and your goal to maintain Object order for printing.