web-dev-qa-db-ja.com

C ++プログラムのデータを保存する最良の方法は何ですか？バイナリとJSONのシリアル化

CADプログラム（C++ではQt）を実装しています。ここで、相互依存クラスがあります。最小のブリックはPatternであり、それは単なるポイントの分布です。次にLayoutsがあり、これには指定された高さのパターンが含まれます（z =定数）。そして最後に、レイアウトの積み重ねであるStacksです。

これらすべてのエンティティには一意のIDがあり、それに適用されるマスクのリストを持つこともできます。

各クラスがツリー構造によってリンクされている（std :: vector of pointers everywhere）ことを知って、複数のスタックをカウントするプロジェクトを保存するための最良の方法は何ですか？保存の目的は、後でプロジェクトを再度ロードして変更することです。

すでにBoost and Qt Serializationを調査しましたが、バイナリシリアライゼーションは（統合するのに時間が必要なため）やりたいことに対しては多すぎるかもしれません。一方、XML/JSONシリアライゼーションについては、次のようなものを考えました。

<Layout>
 <id> 12</id>
 <z> 0</z>
 <patterns>
  <pattern id> pattern0</pattern id>
  <pattern id> pattern1</pattern id>
 </patterns>
</Layout>

それらは他の方法ですか？最高のものは何ですか？なぜですか？この点で私たちは客観性に欠けています。

c++dataserialization
3
ElevenJune

既存のCAD formatを使用するだけでは不十分かどうかを最初に確認します。これにより、ホイールの再発明を防ぐだけでなく、との相互運用性も向上しますその他CADプログラム。さらに、「レイアウト」や「パターン」などの用語を使用する代わりに、「レイヤー」や「エンティティ」などの形式の用語を採用するその他CADシステム）、通信の問題を減らすことができる場合があります。

独自のファイルフォーマットを作成する必要があると本当に感じた場合は、フォーマットをCADシステムの新しいバージョンごとに下位互換性を保つことができることを確認してください。そうしないと、遅かれ早かれ問題が発生します。これは、フォーマットが多くのメタデータを提供する場合、はるかに簡単です。私の経験では、XMLやJSONなどのフォーマットは、独自のバイナリフォーマットよりもこの要件を満たすのを容易にします。これら2つの間の決定は確かにかなり意見が分かれています。XMLはさらに広く使用されていますより多くのサードパーティ製ツールでサポートされています。これにより、他の既存のXMLベースの標準を簡単に統合できます。その一方で、ファイルが非常に大きくなる傾向があり、通常のJSONファイルよりもはるかに大きくなるという欠点があります。同じ情報です。これは、ユースケースで考慮する必要があるトレードオフです。

6
Doc Brown

SQLiteデータベースをグラフィックアプリケーションのファイル形式として使用することで大きな成功を収めました。非常に信頼性が高く、標準形式であるため、そのコンテンツは外部プログラムによって簡単に表示/変換されます。

7
GrandmasterB

JSONはシンプルで移植性があります。外部ツールはそれを読み書きすることに問題はありません。どのアーキテクチャでも、自分でデータを読み書きするときに問題は発生しません。これは非常に素晴らしいことです。また、多くの場合、理解できない項目を無視するだけで、新旧のバージョンとの互換性も非常に簡単です。

長いキーを持つ多くの辞書を保存する場合、JSONは少し冗長です。たとえば、経度と緯度のペアを1000個保存すると、次のように保存できます。

[
  { "longitude": 10.29340, "latitude": 35.34989 },
  { "longitude": 10.29340, "latitude": 35.34989 },
  ... repeat 998 more times
]

データが多すぎて悪影響を及ぼしている場合は、次のようにデータをよりコンパクトに保存することもできます。

{ "latitudes": [10.29340, 10.29340, .. 998 more values], 
  "longitudes": [35.34989, 35.34989, ... 998 more values]
}

もう1つのいい点は、データをよりコンパクトで読みやすい形式で格納できることです。 （行の区切り文字、スペースを削除してコンパクトにします）。

JSONは、配列、辞書（キーと値のペア）、Unicode文字列、数値、ブール値、およびnull値を格納できます。日付を保存することはできませんが、日付をJSONの文字列として保存するための標準があります。

バージョンの互換性が心配な場合は、データの書き込みに使用される仕様の数を指定する1つのキーと値のペアと、無視してデータを処理できる最低の仕様の数を指定する1つのキーと値のペアを追加することをお勧めしますそれが知らない情報。

5
gnasher729

特定のCAD=問題を無視しますが、このユースケースがかなり大きなファイルを生成する可能性があることを考慮して、私は調査することをお勧めしますprotobuf 。これは、将来のニーズに合わせてバージョンを簡単に設定できる、かなりコンパクトなバイナリ形式です。

...言語に依存せず、プラットフォームに依存せず、構造化されたデータをシリアル化するための拡張可能なメカニズム– XMLを考えてください。データを一度構造化する方法を定義したら、特別に生成されたソースコードを使用して、さまざまな言語を使用して、さまざまなデータストリームとの間で構造化データを簡単に読み書きできます。

免責事項：これは、ファイルのストレージではなく、メッセージのシリアル化に使用します。

警告：私がprotobufについて知っている1つの制限は、単一のメッセージが最大約サイズは64MBです。したがって、あなたのようなファイル形式は、通常、ファイルごとに1つの「巨大な」メッセージではなく、複数のprotobufメッセージのストリームとして設計する必要があります。

2
Martin Ba

人間が読める形式が必要な場合、XMLとそれほどではありませんがJSONがおそらく最良の選択肢です。

ただし、人間が読めるということは、人間が編集可能であることも意味します。つまり、人間が無効な変更を加えてから、その人間が間違いを理解できるようにサポートを提供する必要があります。

XMLとJSONはどちらも、時間の経過に伴って発生するフォーマット拡張を解決しないため、新しいプログラムが古いバージョンで動作することができ、その逆も可能です。

また、Googleのプロトコルバッファをバイナリフォーマットオプションの良い選択と見なします。 Cでのサポートが良好で、JSONよりも小さいデータファイルが生成され、さまざまなデータ形式のバージョンを読み取ることができます。

これにより、チームはデータ構造に集中でき、形式の変更を快適に管理できます。

1
Michael Shaw