It would be good to have simple Value and Array constructor from boost::variant. As I know it can easily be done by writing boost::static_visitor<Value>, boost::static_visitor<Array> what do you think? If it is a good idea I can do it (I need it anyway) and provide patch.
Thanks for the suggestion and the offer of writing a patch, but can you clarify some details please. Are you suggesting the the json_spirit::Value_impl::Variant type be made public and that a constructor for this type is added to Value_impl? I don't understand then where the static_visitor is used.
Regards
John
At the moment I need to perform some additional actions to put my boost::variant variables to json_spirit::Object. Taking into account that this library is anyway written using boost, it might be good to have such functionality inside it.
At the moment I use the following auxiliary class to convert boost::variant value.
1. As for me, writing template visitor looks reasonable in case you have multiple Value types. I've seen there is, at least Unicode compatible modification. Frankly speaking I am not very familiar with json spitit inner structure (small not, you forgot to replace, Value with Value_t in 7th line). 2. Right, ideally it would be good to have constructor which will accept boost variant parametrized by any set of supported types and collections (not necessary std::vector) of that supported types. I am not sure it is easily feasible. But, I think, I worth trying OK, anyway, should I try to prepare, or you already have something?
What it doesn't do is support any type of collection, it only supports vectors. It is an interesting problem I will keep working on it. Have you been looking at it?
Hi,
I am trying to compile the code on 64 bit ubuntu but the building process never completes. It works fine on 32 bit machine. Am I doing something wrong.
Hi Ashish,
I have just double checked and it builds fine on my 64 bit Ubuntu. (I have only just got your message. I hope you have already solved the problem.)
Regards
John
The http://www.json.org/[^] mentions that even forward slash must be escaped. Which json_spirit doesn't seem to be doing.
I encountered problem where I had to send date of the following format to a .Net service - "\/Date(1212233230000)\/" with escaped forward slashes. But json_spirit converted that to "\\/Date(1212233230000)\\/".
I solved it by adding the following line in the function add_esc_char of the file json_spirit_writer_template.h.
case'/': s += to_str< String_type >( "\\/" ); returntrue;
If you have any suggestion. Please do update your library if you think it as appropriate.
The JSON RFC, http://www.ietf.org/rfc/rfc4627.txt?number=4627[^], says that "quotation mark, reverse solidus, and the control characters (U+0000 through U+001F)" must be escaped, (a "reverse solidus" is what they call a back-slash). A solidus, i.e. a forward-slash, may be escaped but doesn't have to be.
On reading a string JSON Spirit recognises when a solidus has been escaped and removes the back slash. JSON Spirit doesn't however escape forward slashes. For example "home/john/work" is output as "home/john/work" not "home\/john\/work" although both would be valid according to the JSON standard.
This can be seen by the following code that prints:
in ["\/Date(1212233230000)\/"]
out ["/Date(1212233230000)/"]
Value value;
string s_in = "[\"\\/Date(1212233230000)\\/\"]";
cout << "in " << s_in << endl;
read( s_in, value );
std::string s_out = write( value );
cout << "out " << s_out << endl;
I will probably add escaping forward slashes as an option to the write functions in the next release.
Some parts of your article are very misleading, because you confuse Unicode (probably UTF-16/32) with std::wstring. You can have Unicode with std::string in the form of UTF-8.
I wouldn't say that the article is particularly misleading as I would think that wstrings are often used to hold unicode, and yes you can use std::string for UTF-8, in fact the JSON Spirit's raw_utf8 option is for this case.
I've been using json_spirit for a while, and it's great! I recently tried compiling it under MinGW's implementation of C++0x. There was only one problem:
"function" is now part of the std namespace, so whenever using _both_ "namespace boost" and "namespace std", there will be an ambiguity on "function". To fix this, lines (roughly) 450 to 454 in json_spirit_reader.c should be given the "boost::" prefix, like so:
typedef boost::function< void( Char_type ) > Char_action;
typedef boost::function< void( Iter_type, Iter_type ) > Str_action;
typedef boost::function< void( double ) > Real_action;
typedef boost::function< void( int64_t ) > Int_action;
typedef boost::function< void( uint64_t ) > Uint64_action;
Unfortunately, I am using version 4.02 of json_spirit, and I realize that you've updated since then. I downloaded the new source (4.03), but after a quick search was unable to find the corresponding offending lines (your notes say you moved the implementation into the headers?). I'm afraid I just don't have the time for a thorough search at the moment. I will try to compile the new source this weekend, if possible.
Just wanted to give you a heads up on this. If you've already fixed it, then great! I've read that you've gotten the library to compile on VS2010. From my understanding, GCC (e.g., MinGW) has _more_ of the new standard implemented than VS, so this namespace collision may eventually show up in VS as well.
Best of luck, and thanks again for a great library!
I would think these errors will have gone away in 4.03. As you have noticed I have moved the implementation into headers so have replaced any "using namespace" statements that would have been in the headers with explicit prefixes.
However if there are still problems please let me know.
First of all, thank you for this awesome peace of code, easy to use and very interesting to read I just point out that I had to disable gcc warnings (-Wall -Wextra) to avoid gcc to vomit on my tty Is this easy to fix ?
Thank you for your generous words about the code. The warnings are concerned with unused parameters in some functions in json_spirit_reader_template.h. For example the function throw_not_array does not use the second parameter:
staticvoid throw_not_array( Iter_type begin, Iter_type end )
{
throw_error( begin, "not an array" );
}
The second parameter is required by the Spirit framework. You can prevent the warning by not giving the second parameter a name, i.e.:
This perhaps make the code less easy to understand, without a comment. I keep meaning to release a new version of the code with some minor mods. I'll ensure the warning no longer occur when that happens.
I am trying to use json_spirit to parse a large (~1.5gb) json structure into memory. It ran and finished without any error in 250 secs. However when I do a simple count of the internal array size it was only 10% of the actual size. I am using the mValue to store the data and boost 1.44. I think the issue is lack of memory in the system. Should the library throw any bad allocation exception when the array allocation fails?
Are you reading the data into a single array? If so you are probably exceeding the vector's maximum size, as per vector::max_size, but in this case a bad_alloc exception is thrown. The code below throws when 'i' reaches 17937985, on my 32 bit system.
mArray a;
cout << a.max_size() << endl;
try
{
for( boost::uint64_t i = 0; i < 100000000; ++i )
{
a.push_back( i );
}
}
catch( std::bad_alloc e )
{
cout << "std::bad_alloc\n";
}
Indeed that is what I was expecting. However the parsing finished without any exception and yield incorrect result... that is what is weird. Is here a good place for me to look at if the parsing exited prematurely?