picojsonはシンプルでいいけど、大きいjsonだと重かったりデメリットが多くなる。
どうせ慣れるならrapidjson がよいようです。
github.com
ChatGPTの回答
✅ 概要
| 項目 | rapidjson | picojson |
| 性能（速度） | 🚀 非常に高速（名前通り） | 🐢 遅い（特にパース・シリアライズ） |
| 構造 | DOM / SAX 両対応 | DOMのみ |
| 順序保持 | ✅ **保持される**（配列・オブジェクト） | ❌ `std::map`使用のため**ソートされる** |
| ヘッダーのみ | ✅ ヘッダーオンリー | ✅ ヘッダーオンリー |
| 依存なし | ✅ STLのみ | ✅ STLのみ |
| ドキュメント | 豊富・サンプル多数 | 最小限（READMEレベル） |
| C++11 必須か | ❌（C++03でも動く） | ✅ C++11必須 |
| Unicode対応 | ◯（UTF-8前提、WCHAR非対応） | ◯（UTF-8前提） |
| 設計思想 | パフォーマンス重視 | 最小限・シンプル実装 |
| 可読性 | ◯（冗長な分、明示的） | ◎（シンプルな構文） |
✅ rapidjson のメリット・デメリット
🔷 メリット
・圧倒的に高速（名前の通り本気で早い）
・ 順序保持（`Object` のキー順や `Array` の順序が維持される）
・ SAXパーサ付き（巨大JSON処理に便利）
・ 豊富なサンプルと公式ドキュメント
・ `Allocator` で柔軟なメモリ制御ができる
・ JSON整形出力（`PrettyWriter`）
🔶 デメリット
・APIが冗長（`AddMember()` や `StringRef()` など煩雑）
・テンプレート・アロケータ管理がやや面倒
・Value["key"]` で値がないとクラッシュする（要 `HasMember()`）
✅ picojson のメリット・デメリット
🔷 メリット
・極限まで軽量でシンプル**（単一ヘッダ）
・ APIが直感的（`.get
・ コンパイル通ればすぐ使える
・ ちょっとしたツールやプロトタイプに最適
・ `std::map`, `std::vector` ベースで STLライク
🔶 デメリット
・遅い（特に文字列構築とパース）
・ オブジェクトが `std::map` なので **勝手にソートされる**
・JSON構造が大きいとパフォーマンスが激落ち
・ 日本語リソース・ドキュメントほぼなし
・ 厳密な型チェックがない（型違いで落ちやすい）
✅ どっちを選ぶべき？
| 用途 | おすすめ |
| GUIアプリ（MFCなど）で順序付きJSON処理したい | ✅ rapidjson |
| 順序関係なく小さな設定ファイルを読みたい | ✅ picojson |
| 速度・大規模データが重要 | ✅ rapidjson 一択 |
| ヘッダー1枚で最小構成がいい | ✅ picojson でも可 |
| JSONを書き換えず読むだけ | picojsonでもOK（順序気にしないなら） |
✅ 実際の現場での使い分け例
| シーン | 使用例 | 推奨ライブラリ |
| 設定ファイルの読み書き | `.json`で保存 | picojson（軽量） |
| ブラウザ通信結果（REST API） | JSON構造が複雑 | rapidjson（順序維持） |
| 巨大なログ分析ツール | 数百MBのJSON処理 | rapidjson（SAX） |
| MFCアプリの設定UI | 順序重視 | rapidjson（安全） |
| スクリプト風の実験コード | 簡単に書きたい | picojson（気軽） |
✅ 結論
📌 順序が大事・本番アプリで使うなら `rapidjson`
📌 シンプルな用途・ツール系なら `picojson`
