Optional comment stripping.

[BrunoFiligree]

I've added optional code to strip javascript '//' style comments from a json file. This is only enabled if the JSON_STRIP_COMMENTS C++ macro is defined. By default this does not break conformance with the JSON standard, but allows cases where comment stripping is needed to be enabled on an ad-hoc basis without having to introduce pre-parsing phases with any associated extra code.

[nlohmann]

I don’t think this is a good idea, but I would like to wait for a discussion.

[BrunoFiligree]

We have use cases where we have end-user editable JSON config files. Comments are required in the files for clarity, rather than have separate documentation that no-one will reference. The JSON standard may state 'no comments', but the current 'best practice' to deal with comments is to run it through a pre-parser. This basically acknowledges that comments will be embedded in some JSON files and those need to be dealt with it on an ad-hoc basis.

Rather than introduce yet another thing into our tool chain to do the ad-hoc pre-parsing comment stripping, it is more efficient all round to put the comment stripping directly into the JSON lexer and enable it as needed.

[nlohmann]

Regardless of the outcome of the discussion, please also add test cases.

[BrunoFiligree]

OK. That may take a day or three. Unit tests always take longer than coding :-)

[coveralls]

Coverage remained the same at 100.0% when pulling 72e556e on FiligreeTech:develop into d2dd27d on nlohmann:develop.

[dandee]

I also think that it is not a good idea to break clearly defined standards: there's nothing about C++ style comments in the reference for JSON.

[danielytics]

They're also javascript-style comments, so not really too far from json. Since its enabled/disabled through a macro, users can choose if they want it or not, so I don't see it as a big deal. Yes, its not "technically" json, but its pure-json by default and is a super useful feature given how often json is used as a configuration format. I don't mind either way though, I don't personally use json for config files.

[nlohmann]

I still do not like this library to accept input that does not conforms to RFC 7159. I agree with Douglas Crockford:

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

That parser should not be the one of this library.

[BrunoFiligree]

Fine. I'll keep my fork.