Qual è il modo migliore per salvare i dati di un programma C ++? Serializzazione binaria vs JSON

La prima cosa che controllerei è se l'utilizzo di un formato CAD esistente non sia sufficiente. Ciò non solo impedisce di reinventare la ruota, ma migliora anche l'interoperabilità con altri programmi CAD. Inoltre, adattando i termini di un tale formato come "Livelli" e "Entità", invece di usare termini come "layout" e "schemi" (che hanno significati tipicamente diversi in altri sistemi CAD), potresti essere in grado di ridurre i problemi di comunicazione .

Se ritieni davvero necessario creare il tuo formato di file, assicurati di poter mantenere il formato retrocompatibile con ogni nuova versione del tuo sistema CAD, altrimenti correrai prima o poi problemi. Questo è molto più semplice quando il tuo formato fornisce molti metadati. Nella mia esperienza, formati come XML o JSON rendono più facile soddisfare questo requisito rispetto ai formati binari proprietari. La decisione tra questi due è sicuramente molto opinata. XML è ancora più utilizzato e supportato da molti altri strumenti di terze parti. Vi consentirà una più facile integrazione di altri standard basati su XML esistenti. D'altra parte, ha lo svantaggio che i file tendono a diventare molto grandi, molto più grandi di un tipico file JSON che trasporta le stesse informazioni. Questo è un compromesso che devi considerare per il tuo caso d'uso.

Ho avuto un grande successo utilizzando i database SQLite come formato di file per le applicazioni grafiche. È molto affidabile e, essendo un formato standard, i suoi contenuti sono facilmente visualizzati / convertiti da programmi esterni.

JSON è semplice e portatile. Gli strumenti esterni non avranno problemi a leggerli o scriverli. Non avrai problemi a leggere e scrivere i dati su qualsiasi architettura, il che è molto bello. È anche molto facile essere compatibile con le versioni precedenti e più recenti, spesso semplicemente ignorando gli elementi che non capisci.

JSON è un po 'prolisso se si memorizzano molti dizionari con chiavi lunghe. Ad esempio, se si memorizzano 1000 coppie di longitudine / latitudine, è possibile memorizzarle come

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

Se hai così tanti dati che questo ti sta influenzando negativamente, puoi anche memorizzare i dati in modo più compatto come

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

Un'altra cosa bella è che puoi memorizzare i dati in un formato più compatto o più leggibile. (Compatta rimuovendo separatori di linea, spazi).

JSON può memorizzare array, dizionari (coppie chiave-valore), stringhe Unicode, numeri, valori booleani e valori nulli. Non è possibile memorizzare le date ma esiste uno standard per l'archiviazione delle date come stringhe in JSON.

Se sei preoccupato per la compatibilità delle versioni, ti consiglio di aggiungere una coppia chiave / valore che specifica il numero della specifica utilizzata per scrivere i dati e una coppia chiave / valore che specifica il numero della specifica più bassa che può elaborare dati ignorando le informazioni di cui non è a conoscenza.

Ignorando il problema CAD specifico, ma tenendo conto che questo caso d'uso potrebbe potenzialmente generare file piuttosto grandi, ti consiglio di esaminare protobuf . È un formato binario piuttosto compatto con una versione semplice per le tue esigenze future:

... language-neutral, platform-neutral, extensible mechanism for serializing structured data – think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, then you can use special generated source code to easily write and read your structured data to and from a variety of data streams and using a variety of languages.

Dichiarazione di non responsabilità: la usiamo per la serializzazione dei messaggi, non per la memorizzazione dei file.

Avvertenza: una limitazione che conosco per protobuf è che un singolo messaggio massimo di ca. la dimensione è 64 MB. Pertanto, un formato di file come il tuo dovrebbe essere progettato come un flusso di più messaggi protobuf invece di un messaggio "enorme" per file.

XML e, in misura minore, JSON è probabilmente la migliore opzione disponibile se si desidera un formato leggibile dall'uomo.

Tuttavia, leggibile anche umano significa modificabile da un punto di vista umano, il che significa a sua volta fare in modo che le persone apportino modifiche non valide e quindi fornire supporto per consentire a questi umani di capire i propri errori.

Sia XML che JSON non risolvono le estensioni di formato che si verificano nel tempo, consentendo ai nuovi programmi di funzionare su versioni precedenti e viceversa.

Considererei anche i buffer del protocollo di Google come una buona scelta per un'opzione di formato binario. Ha un buon supporto in C, genera file di dati più piccoli di JSON e consentirà la lettura di diverse versioni di formato dati.

Permetterà al tuo team di concentrarsi sulla struttura dei dati e di gestire comodamente le modifiche al formato.