iod
Languages and libraries
json library
SHOW HN2014
How HN took it
1 positive, 6 neutral or asking, 0 mixed, 4 critical, out of 11 comments about the project. Thread score -0.18.
Performance: 0 for, 3 againstDocs: 0 for, 1 againstIdea: 1 for, 0 against
The thread, comment by comment
Each row is a top-level comment and its replies, in HN's order. Select a cell to open that comment on HN.
positive neutral or mixed critical about another commenter or something else the maker
What HN said
What people liked
Clever use of C++ metaprogramming for generating parsers
From 2 comments
> As of today, all json parsers rely dynamic data structures to parse and store the json objects. I'm not sure that's entirely fair. Callback-based parsers like YAJL leave the…
haberman on HN> This makes its performances impossible to match in other languages such as C or Java that do not provide static introspection. A CHALLENGE! So, er, who's up for it? You could…
twic on HN
Objections
Uses std::string and vector, so it is not truly malloc-free
From 2 comments
This uses std::string all over the place, which allocates memory under the hood. I'm not sure how any JSON parser could avoid memory allocation without a difficult to use…
jlarocco on HNIt also uses vector, which is almost certainly using malloc and/or placement new even if the SIO somehow really does reserve space for a single object. Its also using the heap…
Iftheshoefits on HN
Hand-written callback parsers like vurtun's may be faster
From 2 comments
On one hand this is undoubtedly a very clever use of ++ features. On the other hand that heck of a lot of scaffolding (just look in /iod directory) and the more scaffolding there…
huhtenberg on HNNo, I meant of course that vurtun + all the callbacks are going to be at least as fast as iod. You'd basically pass a bit of context to every callback, so that the app would know…
huhtenberg on HN
Requests
Better documentation of the concepts
From 1 comment
> As of today, all json parsers rely dynamic data structures to parse and store the json objects. I'm not sure that's entirely fair. Callback-based parsers like YAJL leave the…
haberman on HN
Questions
How does the compile-time object introspection and codegen work?
From 1 comment
> As of today, all json parsers rely dynamic data structures to parse and store the json objects. I'm not sure that's entirely fair. Callback-based parsers like YAJL leave the…
haberman on HN
Does malloc-free mean stack allocation with security risks?
From 1 comment
Sorry, didn't read the code yet. But malloc free means stack allocation, thus dangerous to stack attacks. Please clarify.
rurban on HN
Alternatives named
jsmn
From 1 comment
jsmn is a nice JSON tokenizer. You malloc a chunk of memory up front, but that's it. It gives you pointers to the tokens and you can do what you like with them. I am using it in…
pjungwir on HN
vurtun/json
From 1 comment
I wrote a JSON-Parser in C with minimal validation in ~250 LOC that does not allocate memory, but leaves the type check and conversion to the user. https://github.com/vurtun/json
areop on HN
sajson
From 1 comment
sajson allocates once: it turns out you can structure your parse tree such that each byte of input only requires one machine word of output.…
chadaustin on HN
RapidJSON
From 1 comment
RapidJSON claims to support "in-situ parsing", which is presumably mostly zero copy, and presumably doesn't allocate much either. I'd like to see benchmarks over comparable code.
nly on HN
YAJL
From 1 comment
> As of today, all json parsers rely dynamic data structures to parse and store the json objects. I'm not sure that's entirely fair. Callback-based parsers like YAJL leave the…
haberman on HN