jsoncpp Formatierung Probleme

Ich bin mit jsoncpp und ich habe da ein problem mit, wie die json-Nachrichten formatiert sind, wenn Sie geschrieben werden mit einem der Autoren.

Beispiel:

root["name"] = "monkey";
std::cout << writer.write(root) << "\n";

Gibt mir etwas, formatiert wie dieses

{
    "name" : "monkey"
}

Während ich eigentlich will:

{"name":"monkey"}

Ist, habe ich mich auf die Dokumentation und es gibt Erwähnungen von setIndentLength() aber Sie erscheinen nicht in die Quelldateien, damit Sie vielleicht veraltet sind oder so etwas.

Trotzdem jemand weiß, wie dies zu tun?

  • Sollten Sie zeigten uns, was writer war. Der Hinweis ist in seiner Art.
InformationsquelleAutor KaiserJohaan | 2011-09-26
  1. 6

    Als eine Erweiterung der cdunn2001 Antwort, es gibt keine Notwendigkeit, re-write default-Einstellungen (.settings_). Sie können einfach überschreiben 'Einzug' Wert StreamWriterBuilder-generator:

    Json::Value json = ...
Json::StreamWriterBuilder builder;
builder["commentStyle"] = "None";
builder["indentation"] = ""; //The JSON document is written in a single line
std::unique_ptr<Json::StreamWriter> writer(builder.newStreamWriter());
writer->write(json, &std::cout);
    • bitte erläutern Sie diese Antwort ein wenig. code nur die Antworten sind meist nicht viel Wert. thank u! halten Sie die gute Arbeit!
    • vielen Dank im Voraus. Hinzugefügt einige Erklärungen.
    InformationsquelleAutor Ramiro
  2. 5

    Wenn Sie Jsoncpp version 1.1 verwenden, können Sie Json::FastWriter statt Json::StyledWriter oder Json::Writer :

    Das JSON Dokument geschrieben in einer einzigen Zeile. Es ist nicht gedacht für
    'menschlichen' Verzehr, kann aber sinnvoll sein, zur Unterstützung der Funktion, z.B. RPC
    wo die Bandbreite begrenzt ist.

    • Ich habe jsoncpp 1.8.3 wie könnte ich wieder auf verson 1.1? @deepmax
    InformationsquelleAutor masoud
  3. 4

    FastWriter, StyledWriter, StyledStreamWriter, und Writer sind veraltet. Verwenden StreamWriterBuilder, das schafft eine StreamWriter mit einem etwas anderen API. Diese Art der Nutzung:

    Json::StreamWriterBuilder builder;
builder.settings_["indentation"] = "";
std::unique_ptr<Json::StreamWriter> writer(builder.newStreamWriter());
writer->write(root, &std::cout);
    • Warum settings haben am Ende einen Unterstrich? 🙁
    • es ist die Klasse member-name (siehe open-source-Parser.github.io/jsoncpp-docs/doxygen/...)
    • Ja, das verstehe ich. Warum es am Ende einen Unterstrich? Das ist ziemlich seltsam für eine öffentliche Schnittstelle, IMO.
    • Es folgt Google C++ Style Guide für Daten-Mitglieder. Es ist öffentlich, da wir garantieren, dass die API von Json::Value bleibt abwärtskompatibel und Binär-kompatibel sind. Ja, es ist seltsam, aber es ist Unterstrichen die Tatsache, dass es eine Daten-Mitglied, nicht eine Funktion. Glaubst du, es war ein riesiger Fehler? Wir könnten hinzufügen Value& settings() und Value const& settings() const aufgelassen und direkten Zugriff. Aber für mich, der direkte Zugang ist viel einfacher. Die üblichen Gründe für das verstecken der Zugang gilt hier nicht, da haben wir sehr enge Grenzen für die Daten-member ändert sich sowieso.
    • Ich habe nicht ein problem mit der direct access-Prinzip, obwohl es nicht zu passen scheinen, Ihre API in den rest des Projekts. Und da es über diese "interne" Namensschema es sieht sehr komisch an der Stelle der Nutzung. Es fühlt sich falsch an, es zu benutzen. Wie bei Google C++ style guide, ich wäre eigentlich nicht zu viel Lager in diesem Unsinn ist (obwohl es zumindest besser als es verwendet zu sein); sicherlich, die Annahme von pseudo-Ungarische notation für Daten-Mitglieder scheint sich nicht viel verbessert über die Ungarische notation selbst, und wir alle wissen, wie gehasst das ist!
    • BTW glücklich JsonCpp Benutzer für viele Jahre. Danke!
    • Auf dem Google C++ Style Guide, ich bin ein großer fan von mindestens eine Spielregel, und ich empfehle Titus' CppCon talk. Aber ich denke, wir können hinzufügen, die settings() Methoden für diejenigen, die es vorziehen, dass. Kein problem. Froh, Sie genießen Sie die Bibliothek! Es ist Eigenschaft-Reich, aber ohne die Baumeister (kurzem) war es ein bisschen schwer zu pflegen, vor allem mit Binär-Kompatibilität.
    • Ich weiß nicht, wie diese Regel. Sie Wiegen Sie in einem falschen Gefühl der Sicherheit ziemlich schnell, und Sie verlieren alle Vorteile von Referenzen in den ersten Platz. Es gibt keinen Ersatz für das Lesen-Bibliothek-Dokumentation (vor allem wenn Sie die Bibliothek auf eine neue major-version! Lesen Sie die release notes) - und wenn Sie brauchen eine variable, um nicht mutiert ist, dann sollte es markiert const.
    • FWIW, ich mag FastWriter und StyledWriter; tut mir Leid zu hören, dass Sie veraltet sind (ich bin ein paar Versionen hinter). Sie sind sehr schnell und einfach zu bedienen, so lange, wie Sie nicht brauchen eine Menge von Konfigurationsmöglichkeiten .... das weiß ich nicht. 🙂 Zum einspannen JSON-out auf den Draht oder Strahlen Sie zu config-Dateien und/oder debug-Protokolle, die zwei sind perfekt.
    • auf das hilfreiche Regel, wir Stimmen zu, nicht einverstanden. Wenn Sie wollen Sicherheit, Sie verwenden die falsche Sprache. Ich bin auf der Suche nur für die Lesbarkeit. Auf die Autoren, die ich entdeckte, hatten wir Hinzugefügt-features, die brach Binär-Kompatibilität (für Debian-spezifisch). Aufknoten, dass war ein RPITA. Auch bug-fixes wurde nicht für alle Autoren. Irgendwann habe ich realisiert, dass die Erweiterung der Bibliothek, erforderlich für eine stetig wachsende Zahl von Autoren (z.B. Stream-Versionen), die ist unhaltbar. Glücklicherweise sind die meisten Benutzer nicht brauchen, ein Schriftsteller überhaupt. operator<<(ostream) oft genug.
    • Sicherheit in der Sprache und eingelullt in ein Falsches Gefühl der Sicherheit bekommen Sie in die Gewohnheit Annahmen zu machen über ein Programm basierend auf einem style guide, der Sie verwenden (das andere wahrscheinlich nicht) sind zwei völlig verschiedene Dinge. Sie können nicht hand-Welle Weg schlecht und gefährlich Gewohnheit, indem Sie sagen "oh Sie auch nicht in C++ dann".
    • Bei allem Respekt, ich glaube, dass Sie durch Ihre Argumentation, wir sollten löschen drop const und einfach Verweise, zu zwingen, die Leser zu überprüfen, die API. Casting existiert in C++, das ist, warum ich sagen, dass Sie die falsche Sprache. In der Tat, Sie scheinen zu behaupten, dass all Dokumentation ist irreführend. Die Gewohnheit, Hervorhebung Nebenwirkungen -- in der Dokumentation oder source-code-ist weder gefährlich noch schlecht. Im Gegenteil, es ist immer eine hilfreiche Erinnerung. Vielleicht sollten wir das weiter diskutieren dieser point anderswo?

    InformationsquelleAutor cdunn2001
Schreibe einen Kommentar