Názory k článku Pohodlná práce s formátem JSON v C++ díky knihovně nlohmann/json
-
Díky za článek. Jen doplním, že používám také tuto knihovnu mimo jiné kvůli funkci "diff" (implementace RFC 6902 - JSON Patch). Potřeboval jsem vytvořit proxy server nad "Kafka Schema Registry" v C++, tak jsem hledal nějakou, co umí ten "patch". V projektu jsem nakonec použil dvě knihovny pro práci s JSON: (1) nlohmann-json a (2) jsoncons. Ta "jsoncons" je "header only library" a je s ní trochu příjemnější práce, alespoň pro mě.
-
Přesně tak, taky nerozumím tomu tahání závislostí do projektu: ..."Our whole code consists of a single header file json.hpp. That's it.". -- github (https://github.com/nlohmann/json?tab=readme-ov-file#design-goals)
22. 5. 2024, 15:45 editováno autorem komentáře
-
Neviem, či rozumiem pripomienke, ani či si rozumiete navzájom, nebudem to podrobnejšie skúmať, ale inak v C++ sa {} po novom (už nejaký čas) používajú aj na inicializáciu objektu C++. Dá sa to nastaviť tak, že si to podľa argumentov vydedukuje aký objekt sa má vytvoriť. Takže to je syntax na vytvorenie objektu. Samozrejme, že ten kód ako taký nie je validný JSON, ktorý by sa dal do súboru s koncovkou .json skopírovať, ale vzniká tak jeho dátová reprezentácia a tá sa potom dá serializovať do validného formátu.
-
Nevím jak to má napsaný nlohmann, ale já to mám napsaný takto:
- vstupující pole není prázdné
- všechny prvky v poli jsou zase pole
- všechna vnořená pole mají právě dva prvky
- všechna vnořená pole mají jako první prvek stringPokud je tohle splněno, pak se vytvoří objekt, který všechna vnořená pole změní na dvojice klíč-hodnota.
Má verze je zde
Ta moje verze umožňuje i samotný klíč bez hodnoty, protože to používám jako oddefinování hodnoty (když chci klíč smazat)
-
V zásadě takto nejde. Musel bys to vytvořit explicitně zavoláním json::array({..})
v mém podání můžeš použít json20::undefined na konci pole, který se do výsledného pole nedostane, ale rozbije tu podmínku.
{{"string","neco"},undefined} -> pole polí (undefined tam nebude).
Tenhle nástroj je nutné vidět jako zkratku, zejména pro psaní vnořených věcí, když vkládáš objekty do pole, které v sobě mají další objekty. Bez téhle zkratky bys musel každou úroveň anotovat
json::array{json::object{{"key, json::array{1,2,3} }} }
-
Chtěl bych vidět projekt bez nich.
Jsou evil, ale žádná náhrada není a bez maker neuděláš ani sdílenou knihovnu a ani bez nich nenapíšeš kód co používá nějaké platform dependent API... Pokud někdy napsals cokoliv netriviálního tak bez maker to asi nešlo...
Neobhajuju je, ale pokud někdo nevymyslí nějakou funkční náhradu, tak s náma makra zůstanou.
-
Divej, když chceš něco používat, je potřeba si přečíst dokumentaci. Simdjson nabízí opravdu bohaté možnosti v tomto směru. Konkrétně:
We expect users of an On Demand API to work in terms of a JSON dialect, which is a set of expectations and specifications that come in addition to the JSON specification.
Validate What You Use: On Demand deliberately validates the values you use and the structure leading to it, but nothing else. The goal is a guarantee that the value you asked for is the correct one and is not malformed: there must be no confusion over whether you got the right value.
Tvůj příklad dokazuje to, že buď nečteš dokumentaci, a nebo naschvál upravils zrovna tu část dokumentu, kde se ten parser nedostane. Když poškodíš něco předtím, dostaneš krásný error:
TAPE_ERROR: The JSON document has an improper structure: missing or superfluous commas, braces, missing keys, etc.
-
Jak smutné. Nepálí cykly na práci, kterou není potřeba udělat. Kus jsonu který nepotřebuju číst není potřeba ani validovat. Kdybych ho potřeboval zvalidovat, tak ho postě projdu celý.
Ty měřené GB/s jsou včetně validace (která samozřejmě proběhne, když je ta data třeba číst a zpracovat). nlohmann je pomalejší protože sestavuje DOM se vším co k tomu přísluší. Ano, kdyby simdjson dělal pomalé sestavování DOMu jako nlohmann, byl by srovnatelně pomalý.
-
Simdjson má i DOM:
https://github.com/simdjson/simdjson/blob/master/doc/dom.md
I ten DOM parsing bude mnohem rychlejší.
-
Tu je mimochodom ešte jeden zaujímavý parser JSON:
https://www.youtube.com/watch?v=_GrHKyUYyRc
A aj zdôvodnenie jeho vzniku určite stojí za to:
Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love. Pete Cordell
-
RaviseStříbrný podporovatel
> Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love. Pete Cordell
No, rád bych viděl skladatele, co píše tužkou vlastní výroby na papír vlastní výroby, a melodii zkouší na klavír nebo kytaru - ano, správně, vlastní výroby.
Mimochodem, zkusil jsem vydyndat z Llamy písničku o lásce (viz níže) a nepřijde mi, že by se tím svět nějak zlepšil :)
Verse 1: In the silence of a summer night I heard the whisper of your name A gentle breeze that stirred the light And I knew in that moment, I'd be yours to claim Verse 2: Your eyes, like sapphires shining bright Reflect the love that's burning deep inside Your touch, a flame that sets my soul alight And with you by my side, I feel like I can take flight Chorus: Oh, love, you're the melody that fills my heart A symphony of feelings that never depart You're the rhythm that makes me whole Forever with you, my love, is where I'll call home Verse 3: We danced under the stars up high Our laughter echoing, our love passing by The world around us melted away As we chased the sun, and the night, and the day Verse 4: In your arms, I find my peace A sense of belonging, a love that never ceases Through life's ups and downs, we'll weather the storm Together, our love will forever be the norm Chorus: Oh, love, you're the melody that fills my heart A symphony of feelings that never depart You're the rhythm that makes me whole Forever with you, my love, is where I'll call home
-
Ten text nie je zlý, teda nie nejako zjavne horší než to, čo sa dnes bežne produkuje, ale dôležitejšie by bolo, ako by sa to zhudobnilo...
Len ma zaujalo, že v prvej a druhej slohe je rým striedavý, v druhej akýsi hybridný a v tretej a štvrtej združený. To sa bežne nezvykne takto striedať, ale zase, dnes je progresívna doba, tak to nesmieme súdiť...
-
To už je moc vyhrocený, ale ten citát má v něčem pravdu. Opravdu, lidé tvoří nehledě na to, jestli už někdo něco podobného dělal. Někdo pro radost, někdo chce něco zkusit a často se to jemně odchýlí a vznikne nějaká novinka. Udivuje mne rigidita lidí a tunelové vidění -- programátoři na to jsou mistři, obzvláště ti korporátní.
23. 5. 2024, 22:07 editováno autorem komentáře
-
RaviseStříbrný podporovatel
V něčem pravdu má a v něčem zase ne. Skoro jako kdyby žádné přirovnání nebylo úplně přesné.
To, co ty máš za "tunelové vidění" je pro mě zásadní inženýrské rozhodnutí: čemu mám věnovat svůj čas? Koneckonců, můj čas je omezený - není snad divu, že s ním chci nakládat nějakým způsobem optimálně.
Když programuju, tak mým cílem není kód per se, ale radost můžu mít, až když mi ten kód vyřeší problém. Mám tu pěkný příklad z nedávné doby: napsal jsem si udělátor, který z webů kapel cucá termíny koncertů a hází mi je do rss čtečky. Mým cílem bylo zapnout Lifereu a nacházet nové koncerty tam.
Paradoxně mi nejvíc vyšly vstříc kapely, které mají web na wordpressu a koncerty sypou jako články. RSS je hotové, jen ho přidat do čtečky. Problém vyřešen.
U ostatních kapel jsem musel stáhnout a rozparsovat HTML a vysypat RSS někam do souboru, aby si na něj Liferea mohla sáhnout. Čas udělat rozhodnutí. Nejde mi o rychlost - den nebo dva po zveřejnění mi v zásadě nevadí... Ale budu tu logiku muset přepisovat pokaždé, když se změní formát webu. Potřebuju vysokoúrovňový, spíš skriptovací jazyk - python.
Potřebuju nějak schroupat to HTML... Můžu si to napsat sám, nebo můžu použít knihovnu a řešit problém, který ještě není vyřešený. Problém, který je mému cíli bližší. Problém, kde se můžu vyřádit. To je dost jednoduché rozhodování, ne? Zpracování HTML je problém vyřešený - nudný.
Vezmu knihovnu beautifulsoup, a soustředím se na činnost s vyšší přidanou hodnotou - činnost, která mě posune od problému k řešení. Činnost, která bude zajímavá - s největší pravděpodobností jsem první, kdo skládá RSS pro tyhle konkrétní weby. Spousta lidí leze po horách, ale tenhle konkrétní výhled ještě nikdo jiný neviděl. Tenhle je můj.
Zároveň nezastávám přístup "knihovny za každou cenu" - použít nebo nepoužít knihovnu je inženýrské rozhodnutí, postavené na optimalizaci kritéria. A když je mým kritériem mít produkční kód (a je téměř jedno, jestli poběží na Mezinárodní vesmírné stanici nebo u mě doma na RPi)...
Můžu vzít polotovar a soustruhem a frézkou z něj vyrobit šroub. Anebo můžu koupit válcovaný. Kdo si hraje sice nezlobí, ale vím, který z těch dvou bych radši používal jenom jako těžítko.
Je dobře, že lidi dělají, co je baví. Je dobře, že se lidi učí a že zkouší nové věci. "My" bychom bez "vás" neměli co používat. Ale každý vizionář mířící na Měsíc potřebuje kamaráda, co se za oba kouká pod nohy. Tím nechci říct, že myslím nějak líp nebo jediným správným způsobem. Ale takhle prostě myslím já.
Ach jo, to jsem se zase zakecal.
E: Měsíc v tomhle případě s velkým M.
23. 5. 2024, 23:47 editováno autorem komentáře
-
> To, co ty máš za "tunelové vidění" je pro mě zásadní inženýrské rozhodnutí.
To jsi mne nepochopil dobře. Tunelové vidění je, že se vždy musí použít existující a "ověřené" řešení, protože nejsem schopen a vlastně ani nemám chuť dělat něco vlastního a mám nepodloženou důvěru v řešení druhých stran.Vlastní řešení často mnohem více odpovídá té "inženýrině", než slepá důvěra, že když to někdo publikuje veřejně, je to o dost kvalitnější než in-house vývoj.
Chceš reálné příklady? Z pohledu např. bezpečnosti se fakt dnes i vyplatí si půlku věcí radši napsat a hostovat sám, než stahovat z veřejných zdrojů. Jasně hodně věcí si nenapíšu, ale spoustu věcí je na 500 řádků... a to pak má fakt smysl mít pod vlastními křídly, pokud nejsi startup, pro který včera bylo pozdě a myslíš víc do budoucnosti.
24. 5. 2024, 18:44 editováno autorem komentáře
