json et cie

Le
Dominique MICOLLET
Bonjour,


Devant stocker des informations (1) sous une forme structurée pour
réexploitation ultérieure dans un autre programme, j'envisage l'emploi d'une
norme telle que json.

Toutefois, je suis totalement béotien en la matière.

Aussi apprécierai-je tout retour d'expérience de ceux et celles qui ont mis
en œuvre ce genre de stockage.

Il importe que la norme que je retiendrai soit supportée en environnement
C++ Linux Debian Wheezy.

(1) : pour information, ces informations sont les exposants des variables
d'un polynome constitué de *beaucoup* de monomes dans lesquels il faudra
faire une sélection ultérieure.

Cordialement

Dominique
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Alain Ketterlin
Le #26304717
Dominique MICOLLET
Devant stocker des informations (1) sous une forme structurée pour
réexploitation ultérieure dans un autre programme, j'envisage l 'emploi d'une
norme telle que json.



Il y a beaucoup de bibliothèques pour lire/écrire du JSON en C/C+ + (voir
json.org). Vérifie quand même que tout se passe bien avec les his toires
de codage, la sensibilité à la locale, etc.

(Voir
http://stackoverflow.com/questions/245973/whats-the-best-c-json-parser
qui n'est pas récent, mais je ne sais pas si les choses ont changé
depuis.)

J'ai deux expériences dans lesquelles j'ai considéré json (a vant de
l'abandonner) :

1) Un programme C++ qui devait exporter des structures à destination
de quelques scripts "simples" de visualisation/analyse (en Python dans
mon cas). J'ai fini par exporter directement des litéraux python, ce q ui
avait l'avantage de ne nécessiter aucune interface "non-standard" à  
l'autre bout.

2) Un programme C++ qui devait sauvegarder et recharger ses structures.
J'ai fini par écrire mon propre parseur, JSON n'aurait fait qu'ajouter
une couche, inutile selon moi (et consommatrice de mémoire, ce qui ava it
une importance dans ce cas).

Dans les deux cas, j'étais totalement maître du format (de la syn taxe),
ce qui a été déterminant (et j'étais aussi un peu contr aint par la
mémoire). Dans le premier cas, il a fallu finalement interfacer avec un
gus qui ne jurait que par YAML ; j'ai écrit le bout de python qui
sortait du YAML (qu'il relisait en Java). J'ai trouvé cela plus simple.

S'il fallait choisir un critère, je dirais : es-tu seul à manipul er les
résultats, ou bien faut-il que tu maintiennes une interface ? Si tu es
seul, fais ce que tu veux. Sinon, JSON est une bonne solution, à
condition que les structures ne soient pas trop compliquées (ce qui
semble être le cas chez toi). Si les structures sont très compliq uées,
je pense qu'un vrai parseur est, à terme, la meilleure solution (à
condition que la syntaxe soit relativement stable).

-- Alain.
Dominique MICOLLET
Le #26304858
Bonjour,

Alain Ketterlin wrote:
Dans les deux cas, j'étais totalement maître du format (de la syntaxe),
ce qui a été déterminant (et j'étais aussi un peu contraint par la
mémoire). Dans le premier cas, il a fallu finalement interfacer avec un
gus qui ne jurait que par YAML ; j'ai écrit le bout de python qui
sortait du YAML (qu'il relisait en Java). J'ai trouvé cela plus simple.




Merci pour ce retour d'expérience: je vais regarder un peu plus YAML.

S'il fallait choisir un critère, je dirais : es-tu seul à manipuler les
résultats, ou bien faut-il que tu maintiennes une interface ? Si tu es
seul, fais ce que tu veux.
Sinon, JSON est une bonne solution, à
condition que les structures ne soient pas trop compliquées (ce qui
semble être le cas chez toi). Si les structures sont très compliquées,
je pense qu'un vrai parseur est, à terme, la meilleure solution (à
condition que la syntaxe soit relativement stable).




Pour le moment, je suis le seul.
Par contre, la syntaxe est susceptible d'être enrichie, et j'ai le sentiment
que xml et donc JSON permet de garder une compatibilité ascendante.


Cordialement

Dominique
Publicité
Poster une réponse
Anonyme