search

Tencent / rapidjson

A fast JSON parser/generator for C++ with both SAX/DOM style API
http://rapidjson.org/
Other
14.06k stars 3.51k forks source link

Can a release be create please? #1976

Open phunkyfish opened 2 years ago

phunkyfish commented 2 years ago

Many of the PVR add-ons for Kodi (https://github.com/xbmc/xbmc) use rapidjson. However the last release from 2016 no longer works with Windows UWP.

If we could get an updated release that would be great. Thanks!

dinomight commented 2 years ago

I don't know why there hasn't been a proper release in several years, but is there any reason those projects can't pull in the latest from the git repo (or choose a specific revision to align with)? Since RapidJSON is header only, those add-ons would need to rebuild to get the newer version.

dinomight commented 2 years ago

Just digging into the XBMC source a bit, it looks like the RapidJSON source is hosted over on a Kodi server. Could consider just grabbing a source snapshot of the repo and using that zip instead of relying on an official release on this end.

phunkyfish commented 2 years ago

We are already using a commit ref to build. It has never been an issue before as the previous release always worked as intended.

The problem with not having a release is that our reference point is arbitrary, making it difficult to reason about capabilities in relation to previous releases.

gvollant commented 2 years ago

https://github.com/Tencent/rapidjson/issues/1881 https://github.com/Tencent/rapidjson/issues/1862 https://github.com/Tencent/rapidjson/issues/1820 https://github.com/Tencent/rapidjson/issues/1774 https://github.com/Tencent/rapidjson/issues/1006 https://github.com/Tencent/rapidjson/issues/1919 https://github.com/Tencent/rapidjson/issues/1976

dinomight commented 2 years ago

I completely agree there should be releases and as @gvollant has pointed out, the community has wanted releases for quite some time now. I'm not sure what's up with the process. I think there's only one person, @miloyip with the power to cut a release (or to do anything like close tickets, merge PRs, etc.) and they aren't doing it. The project is certainly not dead yet since PRs have been merged and Milo does stop by from time to time. If more help is needed, I can be that help.

Livius90 commented 2 years ago

Use nlohmann C++ json lib, it is much better in releasing and documentation. I gave up waiting for new rapidjson release, i am using this other from now. https://github.com/nlohmann/json

phunkyfish commented 2 years ago

Use nlohmann C++ json lib, it is much better in releasing and documentation. I gave up waiting for new rapidjson release, i am using this other from now. https://github.com/nlohmann/json

I did the same. I use nlohmann json in any new projects.

gvollant commented 2 years ago

Use nlohmann C++ json lib, it is much better in releasing and documentation. I gave up waiting for new rapidjson release, i am using this other from now. https://github.com/nlohmann/json

I did the same. I use nlohmann json in any new projects.

Do you compare performace?

phunkyfish commented 2 years ago

Use nlohmann C++ json lib, it is much better in releasing and documentation. I gave up waiting for new rapidjson release, i am using this other from now. https://github.com/nlohmann/json

I did the same. I use nlohmann json in any new projects.

Do you compare performace?

I did not. But the use cases thus far have been simple so perf not a large decision factor.

dinomight commented 2 years ago

nlohmann is middle of the group when it comes to performance. The high performance libraries are simdjson and DAW JSON link, but they focus primarily on read, I believe, and DAW requires the JSON layout to be known ahead of time.

In terms of memory layout efficiency, I have to guess, but simdjson and RapidJSON win there. There are probably a few other libraries that are efficient about the memory layout, those are just the two I know have their own map-like and vector-like objects optimized for memory layout efficiency (and insert speed) at the cost of look up time. There are also some libraries, like ArduinoJSON, that are a little better when it comes to controlling dynamic memory allocations for embedded platforms.

One of my niche requirements is being able to add data (line and column information) to each JSON value and key. As far as I can tell, that's not easily done in any library but RapidJSON.

You also have to consider API stability and compiler support. If nlohmann decides to drop your old compiler in the chase for staying modern, you may lose out on future releases. RapidJSON is trying to stay compatible with quite old compilers. That doesn't really excuse the lack of docs or releases, but does mean it's better for certain applications. I'm not a huge fan of this either as I want to see more adoption of modern C++ techniques, but I can understand certain platforms having compilers that can't or won't be updated.

As with anything, you just have to measure if a library is "good enough" for your application, but keep in mind what you expect your application to do in terms of scaling and if that JSON element will grow large enough to become a bottleneck or memory issue. If you do it right, you should be able swap JSON libraries with the right abstraction in your app, so it's not going to matter if you find later that "insert JSON library here" doesn't fit your application anymore.

I don't think there's any silver bullet. There are about 27 different C++ JSON libraries (as of today) listed on cppreference, so the fun part is picking one 😃 .

gvollant commented 2 years ago

Pehaps the solutions is creating a fork just to validate sometime a point of release