As part of our web application framework (currently being ported from Windows to Linux) we have a JSON parser and library that might be of interest to a wider community as part of the Boost libraries. It uses a Spirit parser that deals correctly with embedded UTF-16 inside strings. The JSON blobs themselves are built on Boost.Variant and can store null, booleans, strings, int64_t, doubles and arrays & objects. The strings are our Unicode string implementation -- how this should be dealt with in Boost is an open question maybe only cleanly soluble when Boost has it's own proper Unicode string handling. A templated adapter layer could be used I think for both the string and the numeric types. There is also the internal implementation of the array and objects which could be moved to a policy based design. At the moment we use std::vector and std::map with boost::shared_ptr< json > as the value type. The JSON objects are immutable and use a thread safe CoW implementation when changes are required (handled through a separate jcursor object). One thing that is missing is a good EDSL for creating JSON blobs within C++ source code. The latest implementations is where we are using it to create an ACID JSON database and is here: http://svn.felspar.com/public/fost-base/branches/dbschema/Cpp/include/fost/j... The parser itself is here: http://svn.felspar.com/public/fost-base/branches/dbschema/Cpp/include/fost/j... There's a lot of room for improvement, but hopefully it's a good start. K
On Sun, 21 Dec 2008 08:51:37 +0100, Kirit Sælensminde <kirit.saelensminde@gmail.com> wrote:
As part of our web application framework (currently being ported from Windows to Linux) we have a JSON parser and library that might be of interest to a wider community as part of the Boost libraries.
The JSON file format is supported by the Boost.PropertyTree library (see property_tree_rev5.zip at http://www.boostpro.com/vault/). While I use this library for quite some time I don't remember anymore if it has already been accepted or if it's still waiting for a review to be accepted. Boris
[...]
Boris wrote:
On Sun, 21 Dec 2008 08:51:37 +0100, Kirit Sælensminde <kirit.saelensminde@gmail.com> wrote:
As part of our web application framework (currently being ported from Windows to Linux) we have a JSON parser and library that might be of interest to a wider community as part of the Boost libraries.
The JSON file format is supported by the Boost.PropertyTree library (see property_tree_rev5.zip at http://www.boostpro.com/vault/). While I use this library for quite some time I don't remember anymore if it has already been accepted or if it's still waiting for a review to be accepted.
Judging by the documentation[1] the parser seems to target a different use case. Mine includes a full JSON object, rather than the only partially compatible property tree -- for example, mine won't lose null, true or false type information (so can write back out the exact equivalent JSON after it has been parsed). I didn't see anything for how the Boost.PropertyTree implementation dealt with Unicode either -- I guess it just makes use of narrow characters, but I couldn't check as the implementation isn't there. Mine has a Spirit based parser which makes the parser itself usable directly in other parsers much more easily. The Boost.PropertyTree implementation is probably fine for the use that Boost.PropertyTree has, but it means that it doesn't really cover lots of use cases where you actually need to process JSON. [1] http://kaalus.atspace.com/ptree/doc/index.html#json_parser K
On Sunday 21 December 2008 11:49:05 am Kirit Sælensminde wrote:
Judging by the documentation[1] the parser seems to target a different use case. Mine includes a full JSON object, rather than the only partially compatible property tree -- for example, mine won't lose null, true or false type information (so can write back out the exact equivalent JSON after it has been parsed).
Not having downloaded the code ... would it preserve comments or could it be easily extended in order to preserve comments ? Davide Bolcioni -- There is no place like /home.
Davide Bolcioni wrote:
On Sunday 21 December 2008 11:49:05 am Kirit Sælensminde wrote:
Judging by the documentation[1] the parser seems to target a different use case. Mine includes a full JSON object, rather than the only partially compatible property tree -- for example, mine won't lose null, true or false type information (so can write back out the exact equivalent JSON after it has been parsed).
Not having downloaded the code ... would it preserve comments or could it be easily extended in order to preserve comments ?
It does not preserve comments, in fact it will throw a parse error if comments are encountered. I guess JavaScript style comments are an obvious extension, but I can't see that they are part of the standard. I can't help but think that trying to store comments with the the rest of the representation is anything other than opening a can of worms. If the JSON is processed then output again what happens to comments? It seems to me that the preservation of comments is going to be hard without a load of examples and use cases, and even then is it going to be worth it? Not sure, but for what I use JSON for (mostly web services) I can't see it. That the parser should skip comments that it finds I guess there could be a argument for. K
On Sun, Dec 21, 2008 at 3:49 AM, Kirit Sælensminde <kirit.saelensminde@gmail.com> wrote:
Boris wrote:
On Sun, 21 Dec 2008 08:51:37 +0100, Kirit Sælensminde <kirit.saelensminde@gmail.com> wrote:
As part of our web application framework (currently being ported from Windows to Linux) we have a JSON parser and library that might be of interest to a wider community as part of the Boost libraries.
The JSON file format is supported by the Boost.PropertyTree library (see property_tree_rev5.zip at http://www.boostpro.com/vault/). While I use this library for quite some time I don't remember anymore if it has already been accepted or if it's still waiting for a review to be accepted.
Judging by the documentation[1] the parser seems to target a different use case. Mine includes a full JSON object, rather than the only partially compatible property tree -- for example, mine won't lose null, true or false type information (so can write back out the exact equivalent JSON after it has been parsed).
I didn't see anything for how the Boost.PropertyTree implementation dealt with Unicode either -- I guess it just makes use of narrow characters, but I couldn't check as the implementation isn't there. Mine has a Spirit based parser which makes the parser itself usable directly in other parsers much more easily.
The Boost.PropertyTree implementation is probably fine for the use that Boost.PropertyTree has, but it means that it doesn't really cover lots of use cases where you actually need to process JSON.
[1] http://kaalus.atspace.com/ptree/doc/index.html#json_parser
Interesting timing. If you have been watching the spirit lists, a few days ago I created a JSON parser in Spirit2x to both test for the vast speed enhancements of Spirit2x and to donate as an example. Mine is templated on the string and allows you to override the character class parsing with any Spirit supported type (which does not include Unicode yet, but will include it later, we have been talking about it, but does currently support wide_chars). One question, you have int64_t as a supported type, but from my research the Number type in the current JSON spec is a 52/12-bit floating-point type, double in other words. Mine is basic, a single header file, and it stuffs it all into a Value type, which is a Boost.Variant of a null_type, false_type, true_type (empty structs I made, those are specified as types in the JSON standard, not bool's for the true/false), double, StringType (whatever the templated String type is), Object (an boost::unordered_map since the JSON standard stats that it is an unordered map), and Array (which is just an std::vector). All the types are not used in any special way and just changing their declaration should keep compatibility with the rest of the code. My code just returns the Value directly, not fancy wrapper for pulling things out, but I left that open, would just require a one line change of code to wrap it, but figured I might just do open functions instead, allowing for a class style wrapper later, that way it could be exported in a C style as well. I did not make mine to be a 'real' library though, as stated, just an example code, but I did try to make it as accurate to the spec as I saw. As soon as karma is finished for Spirit2x I was planning to make a writer for my Value object as well, both as a condensed (efficient) printer and a pretty printer. As for comments, in my version it would be simple to change, the whitespace skipping parser could easily be extended to catch other things, such as comments, which would always be saved out. As stated, was just making it as an example of the magic of Spirit2x.
OvermindDL1 wrote:
On Sun, Dec 21, 2008 at 3:49 AM, Kirit Sælensminde <kirit.saelensminde@gmail.com> wrote: Interesting timing. If you have been watching the spirit lists, a few days ago I created a JSON parser in Spirit2x to both test for the vast speed enhancements of Spirit2x and to donate as an example. Mine is templated on the string and allows you to override the character class parsing with any Spirit supported type (which does not include Unicode yet, but will include it later, we have been talking about it, but does currently support wide_chars).
I'm not even sure that I knew there was a Spirit list. Do you have a link to yours? One complication with JSON is that although the transmission can be UTF-8, UTF-16 or UTF-32, the Unicode escaping in the strings is always UTF-16, which is why I build into a UTF-16 buffer and then convert it from there. My string class uses UTF-16 on Windows and UTF-8 on Linux. So far nearly all of the JSON that I've seen in the wild in practice uses ASCII with everything above 0x7f escaped using the \uXXXX notation. This is what my unparser does too.
One question, you have int64_t as a supported type, but from my research the Number type in the current JSON spec is a 52/12-bit floating-point type, double in other words.
I don't think that the JSON specification determines what the representation should be for any of the stored values, for example, there is no limit on the number of digits that make up the integer part of a number. It is true that JavaScript has only a floating point type though with all integer operations being emulated. Here is the number definition from RFC4627: number = [ minus ] int [ frac ] [ exp ] decimal-point = %x2E ; . digit1-9 = %x31-39 ; 1-9 e = %x65 / %x45 ; e E exp = e [ minus / plus ] 1*DIGIT frac = decimal-point 1*DIGIT int = zero / ( digit1-9 *DIGIT ) minus = %x2D ; - plus = %x2B ; + zero = %x30 ; 0
Mine is basic, a single header file, and it stuffs it all into a Value type, which is a Boost.Variant of a null_type, false_type, true_type (empty structs I made, those are specified as types in the JSON standard, not bool's for the true/false), double, StringType (whatever the templated String type is), Object (an boost::unordered_map since the JSON standard stats that it is an unordered map), and Array (which is just an std::vector). All the types are not used in any special way and just changing their declaration should keep compatibility with the rest of the code. My code just returns the Value directly, not fancy wrapper for pulling things out, but I left that open, would just require a one line change of code to wrap it, but figured I might just do open functions instead, allowing for a class style wrapper later, that way it could be exported in a C style as well.
It seems to me that the parser is always going to be quite closely coupled with its output type, although some sort of skeleton parser could be envisaged that would be able to talk to an API for building the internal JSON representation. This is one of the reasons I posit mine as a JSON library with the parser as just one part of it. I suppose it ought to be possible though to decompose the parser enough that the components could be used to write to a number of different internal representations.
I did not make mine to be a 'real' library though, as stated, just an example code, but I did try to make it as accurate to the spec as I saw.
As soon as karma is finished for Spirit2x I was planning to make a writer for my Value object as well, both as a condensed (efficient) printer and a pretty printer.
I have a pretty printer, which I'm not unhappy with, but also think it would be better in some ways to be able to separate out better the pretty printing strategy from the structure walking.
As for comments, in my version it would be simple to change, the whitespace skipping parser could easily be extended to catch other things, such as comments, which would always be saved out. As stated, was just making it as an example of the magic of Spirit2x.
I'm not sure that I can see where the comments would be stored in my structure so that it made any sense. To have the parser skip them as whitespace is certainly doable. For that I guess the JavaScript grammar is the place to look for a specification. K
Kirit Sælensminde wrote:
I did not make mine to be a 'real' library though, as stated, just an example code, but I did try to make it as accurate to the spec as I saw.
As soon as karma is finished for Spirit2x I was planning to make a writer for my Value object as well, both as a condensed (efficient) printer and a pretty printer.
I have a pretty printer, which I'm not unhappy with, but also think it would be better in some ways to be able to separate out better the pretty printing strategy from the structure walking.
As for comments, in my version it would be simple to change, the whitespace skipping parser could easily be extended to catch other things, such as comments, which would always be saved out. As stated, was just making it as an example of the magic of Spirit2x.
I'm not sure that I can see where the comments would be stored in my structure so that it made any sense. To have the parser skip them as whitespace is certainly doable. For that I guess the JavaScript grammar is the place to look for a specification.
I suggest porting the parser to Spirit2. It is so much faster and flexible. Attribute handling of recursive types is built-in. Your grammars will be a lot better and simpler. I'll be accepting a set of (peer reviewed) reusable grammars as part of Spirit2 distrib. I'd be interested in having a JSON grammar. OvermindDL1's grammar is a good candidate. It would be super if you both can iron out the details. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Joel de Guzman wrote:
Kirit Sælensminde wrote: I suggest porting the parser to Spirit2. It is so much faster and flexible. Attribute handling of recursive types is built-in. Your grammars will be a lot better and simpler.
Sounds great. Is it part of Boost yet? So far I've not done any optimisation (actually the only thing I think I want to do is to be able to parse directly from an istream and to print directly to an ostream). I've also not added in the error checking in the grammar so the error messages aren't very helpful -- it basically amounts to "unknown parse error". Should be holding off doing these things until I can use Spirit 2? I don't really want to do it twice.
I'll be accepting a set of (peer reviewed) reusable grammars as part of Spirit2 distrib. I'd be interested in having a JSON grammar. OvermindDL1's grammar is a good candidate. It would be super if you both can iron out the details.
I also have another couple of parsers that I've been working on that are nowhere near finished yet. There is a host name parser at: http://svn.felspar.com/public/fost-base/branches/inet/Cpp/include/fost/parse... Which should parse machine names like: miro miro.felspar.net 10.0.2.32 2130706433 I've not added ipv6 to it yet, and whether you really want the final "raw ipv4 number" or not is maybe a matter of some debate. There's also the start of a URL parser: http://svn.felspar.com/public/fost-base/branches/inet/Cpp/include/fost/parse... The 3 members to a closure limit is killing me on that one though :) There's probably a smarter way of going about it. At some point I'm also going to have to build something for a MediaWiki like markup syntax. My current recursive descent parser is a mess :( K
Kirit Sælensminde wrote:
Joel de Guzman wrote:
Kirit Sælensminde wrote: I suggest porting the parser to Spirit2. It is so much faster and flexible. Attribute handling of recursive types is built-in. Your grammars will be a lot better and simpler.
Sounds great. Is it part of Boost yet?
Yes. It's in beta, but a lot of folks are already using it. The beta status is simply due to documentation. I do have some tutorials here: http://tinyurl.com/79c2hh So far I've not done any
optimisation (actually the only thing I think I want to do is to be able to parse directly from an istream and to print directly to an ostream).
I've also not added in the error checking in the grammar so the error messages aren't very helpful -- it basically amounts to "unknown parse error".
Should be holding off doing these things until I can use Spirit 2? I don't really want to do it twice.
I suggest using spirit2 now. Don't let the beta tag scare you. The API is more or less stable. There will be some minor changes here and there until we have release, but I can assure you that such changes aill only be cosmetic.
I'll be accepting a set of (peer reviewed) reusable grammars as part of Spirit2 distrib. I'd be interested in having a JSON grammar. OvermindDL1's grammar is a good candidate. It would be super if you both can iron out the details.
I also have another couple of parsers that I've been working on that are nowhere near finished yet.
These are all cool candidates. My goal is to have a set of reusable grammars people can use and learn from.
The 3 members to a closure limit is killing me on that one though :) There's probably a smarter way of going about it.
No more closures in spirit2. You can consider that a relief, if you don't know what I mean yet ;-) Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
First off, my grammar accepts anything that Spirit2 can parse (so everything from ascii to wide_char strings, unicode support will hopefully be added soon, no changes will be needed to my header to support it). I only accept Unicode16 in the strings as well, as per the standard. I am also quite sure that I read that JSON, in the current form, only stores doubles internally as a number representation, although it would be simple to support integers as well. I initially had it try to parse out a 64-bit integer first, if that failed it tried to parse out a double (with perfect accuracy), if neither were sufficient to represent the number then it just stored it as a string to allow the user to parse it as they wish (I also had a hook where a custom container type could be stored into the variant that accepted a string to construct from, such as if using some big number library), but I commented all that out and just had it support parsing doubles once I read that, helped with the speed of the parsing as well. For comment parsing, I only say it would be easy in mine because Spirit2 grammars are very simple to alter in such ways; once you learn Spirit2, you will see why. Also, feel free to contact me directly if you want help; I have been dealing with Spirit2 exclusively for quite some time now so I have learned it quite well. For IM's, I support MSN, Yahoo, ICQ, XMPP (through a couple server's, including anything Google's supports, such as GTalk), and a few others, so if you want immediate communication, feel free to email me with what you prefer to use and I can add you. Also, due to my use of variants, and no shared pointers (which I did use initially, but it proved rather inefficient, especially in light of Spirit2s attribute passing being *vastly* more efficient than in Classic Spirit), the method I used has no cycle issues (everything is by value, built in-place, a lot more efficient in this design then it initially sounds). And yes, Spirit2 is in the latest Boost distribution, and yes, it is complete sans documentation. Spirit2x is Spirit2, but just in the Spirit SVN, not yet in Boost, and it compiles to the same vastly-more-efficient-than-Classic-Spirit code, but also compiles a great deal faster (Spirit2, like Classic Spirit, compiles hellishly slow). Spirit2x is not yet feature complete. Spirit2x.QI, the parser part, is complete, what is lacking is Spirit2x.Karma, the reverse parser and such. I took a look at your other parsers, and yes, they would be vastly cleaner if reimplemented in Spirit2(x), and I could help to help you learn the new syntax, just catch me on IM or what-not (for note, just adding OvermindDL1 at hotmail.com, or at gmail.com, or at yahoo.com, and so forth will usually catch me if you just want to add me directly, I do not check any of those other emails though, only gmail and my own websites email). Do note, Spirit2x does have 'some' enhancements, like accepting near any callable object for an action and so forth, simplifies code even far greater... :) *Note: Whenever I say 'string', I mean the templated string type that is based on the input, so it may be a basic_string<char>, wchar, whatever.
OvermindDL1 wrote:
I am also quite sure that I read that JSON, in the current form, only stores doubles internally as a number representation, although it would be simple to support integers as well. I initially had it try to parse out a 64-bit integer first, if that failed it tried to parse out a double (with perfect accuracy), if neither were sufficient to represent the number then it just stored it as a string to allow the user to parse it as they wish (I also had a hook where a custom container type could be stored into the variant that accepted a string to construct from, such as if using some big number library), but I commented all that out and just had it support parsing doubles once I read that, helped with the speed of the parsing as well.
I was wondering about doing something very similar. I suppose that passing in the number parser is an option here.
For comment parsing, I only say it would be easy in mine because Spirit2 grammars are very simple to alter in such ways; once you learn Spirit2, you will see why. Also, feel free to contact me directly if you want help; I have been dealing with Spirit2 exclusively for quite some time now so I have learned it quite well. For IM's, I support MSN, Yahoo, ICQ, XMPP (through a couple server's, including anything Google's supports, such as GTalk), and a few others, so if you want immediate communication, feel free to email me with what you prefer to use and I can add you.
Thank you for the offer, I'll do so. Looking at the Spirit 2 examples it looked like it should be simple enough to use a skip parser for the comments -- I guess there's probably one for C++ style comments already that would work perfectly.
Also, due to my use of variants, and no shared pointers (which I did use initially, but it proved rather inefficient, especially in light of Spirit2s attribute passing being *vastly* more efficient than in Classic Spirit), the method I used has no cycle issues (everything is by value, built in-place, a lot more efficient in this design then it initially sounds).
I'm using the shared pointers for other reasons in the json objects themselves, but they should be hidden internally (they're not fully yet) so it won't be possible to make cycles.
And yes, Spirit2 is in the latest Boost distribution, and yes, it is complete sans documentation. Spirit2x is Spirit2, but just in the Spirit SVN, not yet in Boost, and it compiles to the same vastly-more-efficient-than-Classic-Spirit code, but also compiles a great deal faster (Spirit2, like Classic Spirit, compiles hellishly slow). Spirit2x is not yet feature complete. Spirit2x.QI, the parser part, is complete, what is lacking is Spirit2x.Karma, the reverse parser and such. I took a look at your other parsers, and yes, they would be vastly cleaner if reimplemented in Spirit2(x), and I could help to help you learn the new syntax, just catch me on IM or what-not (for note, just adding OvermindDL1 at hotmail.com, or at gmail.com, or at yahoo.com, and so forth will usually catch me if you just want to add me directly, I do not check any of those other emails though, only gmail and my own websites email).
Do note, Spirit2x does have 'some' enhancements, like accepting near any callable object for an action and so forth, simplifies code even far greater... :)
Yes, I saw that in the examples -- very nice :) All I need to do then I think is to work out how to get Spirit2x on my include path so that it occludes the Spirit2 library that ships with Boost and I should be good to go. K
on Thu Dec 25 2008, OvermindDL1 <overminddl1-AT-gmail.com> wrote:
for note, just adding OvermindDL1 at hotmail.com, or at gmail.com, or at yahoo.com, and so forth will usually catch me if you just want to add me directly, I do not check any of those other emails though, only gmail and my own websites email
While we're on the topic, would you mind putting your real name (or make up a consistent and plausible name!) in your address? Boost is not a culture of anonymous posters, and it's a bit jarrying to converse with someone whose email makes him sound like he's the central processing unit for the borg hive. ;-) Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Thu Dec 25 2008, OvermindDL1 <overminddl1-AT-gmail.com> wrote:
for note, just adding OvermindDL1 at hotmail.com, or at gmail.com, or at yahoo.com, and so forth will usually catch me if you just want to add me directly, I do not check any of those other emails though, only gmail and my own websites email
While we're on the topic, would you mind putting your real name (or make up a consistent and plausible name!) in your address? Boost is not a culture of anonymous posters, and it's a bit jarrying to converse with someone whose email makes him sound like he's the central processing unit for the borg hive. ;-)
Interesting. I already asked that same question from "Overmind" in the Spirit list. It turns out that people in the real world really calls him "Overmind". So, it's a real pseudonym, FWIW. Not a concocted for anonymity. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
On Sat, Dec 27, 2008 at 9:24 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
David Abrahams wrote:
on Thu Dec 25 2008, OvermindDL1 <overminddl1-AT-gmail.com> wrote:
for note, just adding OvermindDL1 at hotmail.com, or at gmail.com, or at yahoo.com, and so forth will usually catch me if you just want to add me directly, I do not check any of those other emails though, only gmail and my own websites email
While we're on the topic, would you mind putting your real name (or make up a consistent and plausible name!) in your address? Boost is not a culture of anonymous posters, and it's a bit jarrying to converse with someone whose email makes him sound like he's the central processing unit for the borg hive. ;-)
Interesting. I already asked that same question from "Overmind" in the Spirit list. It turns out that people in the real world really calls him "Overmind". So, it's a real pseudonym, FWIW. Not a concocted for anonymity.
Correct. I can give you my 'legal' name if that is what you are inquiring for, but a google search of my real name will not find me (I just did such a search, tried adding my city name, some other personal info, as far as I can tell Google thinks that I do not exist...). Basically everyone knows me as OvermindDL1, been almost ten years now.
on Tue Dec 30 2008, OvermindDL1 <overminddl1-AT-gmail.com> wrote:
On Sat, Dec 27, 2008 at 9:24 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
David Abrahams wrote:
on Thu Dec 25 2008, OvermindDL1 <overminddl1-AT-gmail.com> wrote:
for note, just adding OvermindDL1 at hotmail.com, or at gmail.com, or at yahoo.com, and so forth will usually catch me if you just want to add me directly, I do not check any of those other emails though, only gmail and my own websites email
While we're on the topic, would you mind putting your real name (or make up a consistent and plausible name!) in your address? Boost is not a culture of anonymous posters, and it's a bit jarrying to converse with someone whose email makes him sound like he's the central processing unit for the borg hive. ;-)
Interesting. I already asked that same question from "Overmind" in the Spirit list. It turns out that people in the real world really calls him "Overmind". So, it's a real pseudonym, FWIW. Not a concocted for anonymity.
Correct. I can give you my 'legal' name if that is what you are inquiring for, but a google search of my real name will not find me (I just did such a search, tried adding my city name, some other personal info, as far as I can tell Google thinks that I do not exist...). Basically everyone knows me as OvermindDL1, been almost ten years now.
OK, if you show up at BoostCon next year I expect you to ask for "OvermindDL1" on your nametag ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Tue, Dec 30, 2008 at 6:22 PM, David Abrahams <dave@boostpro.com> wrote:
on Tue Dec 30 2008, OvermindDL1 <overminddl1-AT-gmail.com> wrote:
On Sat, Dec 27, 2008 at 9:24 PM, Joel de Guzman <joel@boost-consulting.com> wrote:
David Abrahams wrote:
on Thu Dec 25 2008, OvermindDL1 <overminddl1-AT-gmail.com> wrote:
for note, just adding OvermindDL1 at hotmail.com, or at gmail.com, or at yahoo.com, and so forth will usually catch me if you just want to add me directly, I do not check any of those other emails though, only gmail and my own websites email
While we're on the topic, would you mind putting your real name (or make up a consistent and plausible name!) in your address? Boost is not a culture of anonymous posters, and it's a bit jarrying to converse with someone whose email makes him sound like he's the central processing unit for the borg hive. ;-)
Interesting. I already asked that same question from "Overmind" in the Spirit list. It turns out that people in the real world really calls him "Overmind". So, it's a real pseudonym, FWIW. Not a concocted for anonymity.
Correct. I can give you my 'legal' name if that is what you are inquiring for, but a google search of my real name will not find me (I just did such a search, tried adding my city name, some other personal info, as far as I can tell Google thinks that I do not exist...). Basically everyone knows me as OvermindDL1, been almost ten years now.
OK, if you show up at BoostCon next year I expect you to ask for "OvermindDL1" on your nametag ;-)
Actually I have done that at other conferences. :) Any conference may be out of my capabilities for at least another year though, I have practically no free time, and traveling is out of the question...
Mathias Gaunard wrote:
Kirit Sælensminde wrote:
At the moment we use std::vector and std::map with boost::shared_ptr< json > as the value type.
What about cycles?
Not push bikes? :) The API makes it very hard (but not impossible) to introduce a cycle into the JSON tree. To do so you would need to create a json::array_t or json::object_t and then place the same shared_ptr into the right locations to make the cycle. I could do something so that these types are not exposed thus making it impossible to introduce a cycle in the first place. The unparser makes no attempt to detect a cycle in the tree, but other operations should work if you do force one in, but you'll likely see odd behaviour in other places depending on what is going on in the levels of code above the library. K
participants (7)
-
Boris -
David Abrahams -
Davide Bolcioni -
Joel de Guzman -
Kirit Sælensminde -
Mathias Gaunard -
OvermindDL1