10

I'm using jsoncpp and I'm having a problem with how the json messages are formatted when they are written using one of the Writers.

For example:

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

Gives me something formatted like this

{
    "name" : "monkey"
}

While I actually want:

{"name":"monkey"}

I've looked at the documentation and there are mentions of setIndentLength() but they don't appear in the source files, so maybe they are deprecated or something.

Anyway anyone knows how to do this?

Cœur
  • 37,241
  • 25
  • 195
  • 267
KaiserJohaan
  • 9,028
  • 20
  • 112
  • 199

3 Answers3

6

As an extension of cdunn2001's answer, there is no need to re-write default settings (.settings_). You can just override 'indentation' value of StreamWriterBuilder builder:

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);
Ramiro
  • 375
  • 5
  • 8
5

If you use Jsoncpp version 1.1, you can use Json::FastWriter instead of Json::StyledWriter or Json::Writer :

The JSON document is written in a single line. It is not intended for 'human' consumption, but may be usefull to support feature such as RPC where bandwith is limited.

masoud
  • 55,379
  • 16
  • 141
  • 208
4

FastWriter, StyledWriter, StyledStreamWriter, and Writer are deprecated. Use StreamWriterBuilder, which creates a StreamWriter with a slightly different API. Use it this way:

Json::StreamWriterBuilder builder;
builder.settings_["indentation"] = "";
std::unique_ptr<Json::StreamWriter> writer(builder.newStreamWriter());
writer->write(root, &std::cout);
cdunn2001
  • 17,657
  • 8
  • 55
  • 45
  • Why does `settings` have a trailing underscore? :( – Lightness Races in Orbit Feb 15 '15 at 00:50
  • @LightnessRacesinOrbit it is the class member name (see http://open-source-parsers.github.io/jsoncpp-docs/doxygen/class_json_1_1_stream_writer_builder.html) – mpromonet Feb 15 '15 at 00:55
  • @mpromonet: Yes, I understand that. Why does it have a trailing underscore? That's pretty weird for a public interface, IMO. – Lightness Races in Orbit Feb 15 '15 at 00:56
  • 1
    It follows Google C++ Style Guide for data-members. It's public because we guarantee that the API of `Json::Value` will remain backward-compatible and binary-compatible. Yes, it's odd, but it *underscores* the fact that it is a data-member, not a function. Do you think it was a huge mistake? We could add `Value& settings()` and `Value const& settings() const` and deprecate the direct access. But to me, the direct access is much simpler. The usual reasons for hiding access do not apply here, as we have very tight constraints on data-member changes anyway. – cdunn2001 Feb 15 '15 at 01:01
  • @cdunn2001: I don't have a problem with the direct access in principle, though it doesn't seem to fit your API in the rest of the project. And since it exposes this "internal" naming scheme it looks extremely weird at point of usage. It feels wrong to use it. As for Google's C++ style guide, I really wouldn't put too much stock in that nonsense (though it's at least better than it used to be); certainly, adopting pseudo-Hungarian notation for data members doesn't seem much improved over Hungarian notation itself, and we all know how hated _that_ is! – Lightness Races in Orbit Feb 15 '15 at 01:12
  • @LightnessRacesinOrbit, On the Google C++ Style Guide, I am a big fan of at least [one particular rule](http://stackoverflow.com/a/26441753/263998), and I recommend [Titus' CppCon talk](https://www.youtube.com/watch?v=NOCElcMcFik). But I think we can add the `settings()` methods for those who prefer that. No problem. Glad you enjoy the library! It is feature-rich, but without the *Builders* (added recently) it was a bit hard to maintain, especially with binary-compatibility. – cdunn2001 Feb 15 '15 at 01:20
  • @cdunn2001: I don't like that rule. It will lull you into a false sense of security pretty fast, and you lose all the benefits of having references in the first place. There is no substitute for reading library documentation (_especially_ if upgrading the library to a new major version! Read the release notes) and if you need a variable to not be mutated then it should be marked `const`. – Lightness Races in Orbit Feb 15 '15 at 01:23
  • FWIW I like `FastWriter` and `StyledWriter`; sorry to hear that they're deprecated (I'm a few versions behind). They're very quick and easy to use as long as you don't need a lot of configurability .... which I don't. :) For chucking JSON out on the wire or emitting it to config files and/or debug logs, those two are perfect. – Lightness Races in Orbit Feb 15 '15 at 01:25
  • @LightnessRacesinOrbit, on the helpful rule, we'll have to agree to disagree. If you want safety, you are using the wrong language. I am looking only for readability. On the Writers, I discovered that we had added features which broke binary-compatibility (for Debian specifically). Disentangling that was a RPITA. Also, bug-fixes had not been applied to all Writers. Eventually, I realized that extending the library required an ever increasing number of Writers (e.g. Stream versions) which is untenable. Fortunately, most users will not need a Writer at all. `operator<<(ostream)` is often enough. – cdunn2001 Feb 15 '15 at 07:39
  • Safety in the language and being lulled into a false sense of security by getting you into the habit of making assumptions about a program based on a style guide that _you_ use (that others likely _don't_ use) are two entirely different things. You can't hand-wave away a bad and inherently dangerous habit by saying "oh well don't use C++ then". – Lightness Races in Orbit Feb 15 '15 at 15:34
  • Respectfully, I believe that by your reasoning we should delete drop `const` and simply take references everywhere, to force the reader to check the API. Casting exists in C++, which is why I say that you are using the wrong language. In fact, you seem to argue that *all* documentation is misleading. The habit of highlighting side-effects -- in documentation or in source-code -- is neither dangerous nor bad. To the contrary, it is always a helpful reminder. Maybe we should further discuss this point [elsewhere](http://stackoverflow.com/a/26441753/263998)? – cdunn2001 Feb 15 '15 at 17:09