Reprise du message précédent :

J'ai peut-être mal démarré cette conversation. Je ne comprends pas ce que tu suggères.

Je veux écrire un test unitaire, pour vérifier que quand mon service reçoit certaines données, il renvoit une certaine réponse. Les données d'entrée sont du json. Est-ce qu'il y a un moyen commode d'écrire ce JSON, si possible en ligne dans mon test (pas dans un fichier à part) ?

 
En python c'est json.dumps({
    "salut": "je suis un dict tranfsormable en json",
    "list":[1, 2, 3],
    "text": "Test"
})
 
Après ça dépend de ton langage. Tu peux mettre du plain text faut juste escaper les " ce qui peut être chiant selon le langage.

Enfin plus l'inverse IMO, tu veux désérialiser dans un truc style DOM/arbre avant de faire la comparaison.

Tester le document JSON littéral est une super mauvaise idée, l'ordre des clés est sans importance tant qu'il a pas été spécifié comme important, tu veux surtout pas prendre ça en compte que que ça a aucune raison d'être stable (encore une fois sauf si c'est spécifié).

Et vu que le quoting du JSON est très strict (double quotes uniquement) et conflicte avec les la chaîne littérale de la grande majorité des langages, mettre du JSON pas trivial dans une chaîne littérale c'est pas exactement fun.

attributs
namespaces
schemas  
cdata  
xslt, xsd, xquery, ...
commentaires  
semantique  
 
je crois que la liste est longue. XML est éprouvé, mature.
 
c'est pas moins écrivable avec un bon outil IDE, c'est plus lisible pour quelqu'un qui est pas dans l'IT qui comprends pas json, un peu plus lent et lourd certainement

Sauf si t'encodes que des tableaux  

une raison de plus, c'est un vrai merdier.
 
Franchement écrire des tests qui serializent / deserializent a tout va, c'est fastidieux, la bonne affaire, a la limite écrit des assert avec json path pour vérifier que tu as ce que tu attends ou tu l'attends vu que justement l'ordering sera au bon vouloir de l'unmarshaller

confusion, redondant
confusion, incompatibilités
welcome to the club
workaround (redondant, et confus)
horreurs 1, 2, et 3
évité à dessein
, absence de

asn.1 et json aussi.

D'entiers

 
mouais ok si tu veux pas discuter c'est d'accord

Tu cites des trucs, je te dis ce que j'en pense
 
Et t'as mieux sur tous les tableaux avec des sexps en plus, y compris sur l'absence de sémantique.

non, tu les fait passer pour fait et vérités, or ce n'est pas le cas.

je ne vois pas en quoi les attributes créent de la confusion
les namespaces permettent justement un vrai besoin
json schema c'est pas encore au niveau d'xml schema aux dernières nouvelles, si ? si c'est le cas, cool.
cdata wins, lol c'est mieux de tout encoder en base64 ? super
xslt c'est super super utile
et justement y'a de la sémantique dans XML, tu peux embed des tags sans aucun soucis pour l'indiquer

tu te trompes de guerre, j'ai pas dis que JSON est mauvais, mais qu'XML est supérieur par nature, qu'on choisisse JSON pour communiquer entre services simples, fine, qu'on prenne protobuf pour de la perf, fine, ça enlève rien à XML.

et puis on arrive à faire faire des requêtes web à des déssérialiseurs et ça n'a pas de prix !

qui peut le plus peut le moins c'est ce qu'on se tue a dire

c'est une blague sur log4J ?

C'est une belle faille faut dire aussi, pour une fois que tout le monde peut participer

Ah ouais ok carrément. C'est naze. En gros on dépend du tooling du langage. En C++ c'est moche je préfère encore me fader un JSON brut.

C'est redondant avec (mais moins capable que) des éléments, le guidage sur leur utilisation c'est à l'odeur du pet.

Oui, dans la théorie c'est un peu utile de temps en temps, dans les faits c'est foireux dans la mesure où c'est pas imposé (je vois régulièrement des trucs qui sont pas foutus d'ingérer des XML sortis d'ElementTree parce qu'ils partent du principe que les préfixes ont une sémantique), et c'est très confus pour les utilisateurs.

T'aurais dit relax à la limite mais xml schema ça ressemble à rien et la sémantique est horrible.

Tu peux pas remplacer du base64 par CDATA vu que tu peux y mettre que des Char, donc CDATA ça duplique un noeud texte classique, mais n'empêche pas d'avoir besoin de base64.  
 
CDATA c'est utile pour pas avoir à se fader les escapes à la main, et c'est à peu près tout, et ensuite ça fout la merde parce qu'il y a des implémentations qui surfacent ton CDATA (genre le DOM) donc les rares fois où tu te dis que tu vas utiliser un CDATA dans ton document que t'écris à la main le truc en face se prend les pieds dans le tapis et ça marche pas (vécu)

XSLT c'est super horrible, c'est un concept excellent mais ça aurait du être implémenté dans un vrai langage, tout le design du langage est mauvais à commencer par le fait que ce soit du XML (mais aussi avec le contexte implicite et la séparation partielle mais pas complète entre élément et attribut).

Non, c'est un meta-langage, XML n'a aucune sémantique intrinsèque, c'est à la fois l'avantage (t'en fais n'importe quelle boulle de boue) et l'inconvénient (tu dois définir ta boule de bout, t'as généralement autre chose à foutre).

Pareil

Toujours pas d'accord.

Avec tous les problèmes que ça implique.
 
Après tu peux utiliser un truc externe pour générer du JSON correct et coller ça dans un rawstring (nouveauté C++11!). Ou alors des fichiers json que t'inclues à grand coup de préprocesseur

De nouveau tu vas généralement pas trop pouvoir écrire des tests contre du JSON litéral.
 
Mais C++ a des strings brutes/multi-lignes depuis C++11 non?
Donc tu passes ton exemple au parseur (a minima) puis tu dois pouvoir faire tes comparaisons.
 
Edit:

J'ai refait mon AoC en repartant de 0, en essayant de tout comprendre et de faire simple, j'ai divisé le temps d'exécution par 3 : https://pastebin.com/d24bSn2j
 
Par contre le A* j'arrive vraiment pas ; suivant l'heuristique que j'utilise, soit c'est plus lent, soit c'est ultra rapide mais ça donne un résultat faux

Sinon ya des libs qui permettent d'écrire des trucs pas trop dégueulasses même si ça reste pas bien grandiose, genre json_spirit, faut voir si ça sait faire des comparaisons.

C'est marrant cette question sur le lapin en coding interview avec Dan Abramov : https://www.youtube.com/watch?v=XEt09iK8IXs&t=1261s

 
J'ai vu ça la semaine dernière.

J'ai vu l'énoncé mais pas encore ce qu'il propose, mais ça donne envie de choisir consécutivement 2 fois chaque trou en partant d'un des bouts et d'aller vers l'autre bout. Ça marcherait non ?
 
EDIT: non en fait
 
Édit 2 : tu pars de 1 en incrementant jusqu’à 100, tu choisis 100 à nouveau et tu décrémentes jusqu’à 1

XML c'est caca quand c'est utilisé dans un cas qui n'a pas besoin de ses features avancées (c'est à dire, à l'heure actuelle, 80% de vrais trucs en prod).
 
La conso CPU pour décoder cette chiasse Là dessus, JSON superior.
 
Après pour de la conf, TOML c'est bien

Vraiment sympa, en tout cas

Sinon rien à voir, je viens de me faire niquer avec RDS Postgres d'AWS
Ils ont pas la collation C.UTF-8, et je dois migrer une DB qui vient d'OVH qui utilise cette collation.  

Je me retrouve vraiment comme un con (ça va finir en conversion dégueulasse en en_US.UTF-8 )

 
Ouvre ton esprit, laisse ton corps découvrir les charmes d’un langage expressif, avec un bon tooling. Laisse toi pénétrer par Python
 
 

C'est pas si mal que ça, j'avais des a priori pas si justifié que ça  

J'attends de voir une fois passé en rust si c'est toujours valide  

Oui voilà, c'est ce que je fais. C'est pénible. protobuf est mieux

Je vais te rediriger vers le commentaire d’un contributeur plus haut dans le thread:

 
Et de ce que j’ai pu en voir ça semblait pas bien mieux que la lib json que j’ai posté au dessus, sauf à la limite si tu peux ne pas spécifier la majorité des champs.

Je suis perdu, c'est quoi ça ?

Un grand pouvoir implique de grande responsabilités
 

Pour avoir bossé sur des apps qui consomment du XML avancé, sans tout ça et ce tooling ça aurait été encore plus merdique je pense
 

Oui je parlais des escapes, des saut de lignes etc, j'ai jamais eu aucun soucis en Java pour récupérer des CDATA, j'en utilise toutes les semaines dans les scripts de migration liquibase, car SQL superior pour cela.
 

Accordons nous sur un désaccord    
 
Bon sinon Day 16, énoncé très très long, j'ai mis 1h pour les 2 parties, je déteste ce genre de parsing, je suis sûr que c'est un problème pour beel1 ça, 12 lignes de C avec du bit shifting dans tous les coins et c'est réglé.
 

 
J'ai mal au cerveau pour la journée, heureusement j'ai quasi que des réunions et des pokers    

Je viens de survoler l'énoncé, j'ai probablement pas le temps de faire ça aujourd'hui

J'ai lu l'énoncé mais du coup je suis trop fatigué pour me lancer. On verra ça après la sieste

Un peu relou pour être honnête, perso il me faut déjà 45 minutes pour comprendre l'énoncé...

https://pastebin.com/WE5Aw2A2

Moi j'aime bien JSON, mais oui l'absence de commentaires est incompréhensible.

edit masklinn: ah ok, bof bof comme raison. Il aurait pu suffire de spécifier que les commentaires ne soient jamais transmis dans les échanges, non ?

Perso, j'évite XML quand je peux. Si j'ai besoin d'échanger pas mal de requêtes avec relativement peu de données, ça sera JSON ou une version compressée de JSON, et si les données sont lourdes, je vais me tourner vers Protobuff ou équivalent. Au final ça couvre 99% des usages.

Je trouve que XML c'est le marteau qui essaye d'être aussi le tournevis et la scie, et donc on se retrouve avec un outil assez tordu qui fait tout, mais de façon compliquée.

Créer une valeur protobuf v json, pour pouvoir comparer ce que tu récupères à ta référence?

Elle est largement documentée, et motivée.
 
Tu peux ne pas être d’accord avec le raisonnement, mais appeler ça incompréhensible c’est soit que t’es jamais aller chercher l’information soit malhonnête, c’est une décision très aisément compréhensible.

ouai j'ai édité mon message.

hephaistos: JSON a été volontairement limité dans ses features pour ne garder qu'un minimum vital qui permet des échanges relativement légers (par rapport à XML) et immédiatements assimilables par Javascript.