rapidjson за/против
От: dosik Россия www.dosik.ru
Дата: 19.12.16 21:57
Оценка:
До сих пор пользовал jsoncpp, все устраивало, но вот тут понадобилась валидация по схеме.
Посмотрел вот это обзор:
https://github.com/miloyip/nativejson-benchmark
В котором автор rapidjson восхваляет свою библиотечину.
Так ли это на самом деле? Кто юзает, поделитесь впечатлениями.
Или быть может есть более достойные альтернативы rapidjson?
Пока требования к библиотеке таковы: unicode, DOM, Schema validation.
Re: rapidjson за/против
От: dosik Россия www.dosik.ru
Дата: 17.02.17 10:45
Оценка:
Ну раз молчание, то в таком случае быть может расскажите, какое JSON библиотеке отдаете предпочтение, и почем?
Re: rapidjson за/против
От: frymode  
Дата: 17.02.17 12:01
Оценка:
Здравствуйте, dosik, Вы писали:

D>Так ли это на самом деле? Кто юзает, поделитесь впечатлениями.


Из неприятных моментов, доступ к элементу по имени в DOM — O(n). Для случаев частого динамического обращения приходится строить свой DOM c хэш-таблицами на основе rapidjson-всокго же SAX парсера.

В остальном впечатления только положительные.
Re[2]: rapidjson за/против
От: dosik Россия www.dosik.ru
Дата: 17.02.17 14:06
Оценка:
Здравствуйте, frymode, Вы писали:

F>Из неприятных моментов, доступ к элементу по имени в DOM — O(n).


До этого использовал JsonCPP, ну там та же ситуация, что не очень сильно напрягало, хотя и Json были не большине. Не понятно, что мешает использовать там unordered_map вместо map, тупо нравиться что все сортируется по алфавиту, вероятность потерять итераторы из-за рехэшинга, или тут замешана религия ?
Re[3]: rapidjson за/против
От: _NN_ www.nemerleweb.com
Дата: 18.02.17 14:11
Оценка:
Здравствуйте, dosik, Вы писали:

D>Здравствуйте, frymode, Вы писали:


F>>Из неприятных моментов, доступ к элементу по имени в DOM — O(n).


D>До этого использовал JsonCPP, ну там та же ситуация, что не очень сильно напрягало, хотя и Json были не большине. Не понятно, что мешает использовать там unordered_map вместо map, тупо нравиться что все сортируется по алфавиту, вероятность потерять итераторы из-за рехэшинга, или тут замешана религия ?


Просто боятся сломать код.
Это же не смельчаки из GCC, которые поменяли реализацию memcpy и поломали несколько програм

Ok. I'll add a note that sorting is not guaranteed. A new method means a minor-version bump, so we can do that later. Switching to hashmap was a suggestion of @blep too, but we'd have to be very careful to maintain binary-compatibility. I'd worry most about the iterators.

https://github.com/open-source-parsers/jsoncpp/issues/237

И Allow hashmap via compilation flag
http://rsdn.nemerleweb.com
http://nemerleweb.com
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.